Доброго времени суток. Прошу помощи не в написании кода, а в подготовке к данному процессу. 

Ситуация у меня следующая (хотя, думаю, что многим это знакомо).
На работе частенько дают некую задачу. На эту задачу есть приблизительное ТЗ, где написано, что система (модуль) должна делать в общем, без указаний чего хотелось бы в будущем.
Иногда к данному ТЗ прилагается примерный интерфейс, но зачастую все обговаривается устно. Я примерно обмозговываю как я это буду делать и почти сразу ваяю.
Что получается в результате: по ходу разработки уточняются требования, появляются новые функции, которые чем позже появляются, тем сложнее вписываются в первоначальную архитектуру.
В конце концов я получаю так код, что самому стыдно, что это писал я (плюс сроки постоянно сдвигаются в геометрической прогрессии от каждого нововведения).

Думается мне, что нужно больше уделять времени предпрограммированию (ну то есть проектированию). Можно конечно использовать UML, MS project и прочих монстров, но
на это мне времени просто никто не даст. Мне хочется услышать от опытных программистов как они приступают к работе, что обмозговывают, что рисуют на бумажке, как
выделяют места, которые должны быть легко расширяемые. Конечно дело это сугубо личное и субъективное, но хотелось бы услышать мнения и вынести что то для себя полезное. 

Заранее благодарен.

xTr1m, проблема в том, что этап проектирования должен быть до передачи ТЗ тебе. Так как разработчик узкоспециализированного модуля не в силах предугадать все возможные будущие требования к нему. Другими словами, если меняется интерфейс (не расширяется, а изменяется), то проблема с проектированием у твоего начальника.

Дело в том, что полностью интерфейс, конечно не изменяется. Но бывают случаи, ну вот к примеру. Есть окно, разделенное сплиттером на две части. Я формирую некую логику общения этих двух частей между собой. Через пару недель выясняется, что частей в окне должно быть 3 и логика общения у же другая. Тут конечно, скорее всего, я неправильно задал логику общения (нужно было как-нибудь более абстрактно, что ли), но таких примеров бывает много, как быть?

Я пока вижу, как вариант, для любой вещи сразу закладываться, что она может измениться и нужно программировать максимально абстрактно, чтобы можно было легко изменять все. На как такого достичь?

не думаю, что можно все делать абстрактно. если так все делать, то у тебя уйдут месяцы на абстракции, и тебя уволят не взирая на твои уверения, что конкретизация будет готова через 2 недели. Максимум, что можно сделать, это разбить логику на минимальные функциональные блоки и, в случае изменения ТЗ, просто перекомбинировать их.

xTr1m, тут могут помочь паттерны проектирования.

Есть такая наука - Дезайн Пользовательского Взаимодействия/Интерфейса. (Почитай книжки Алана Купера: 'Психбольница в руках пациентов' и 'About Face'/'Алан Купер об Интерфейсе')
Главная мысль - дезайн взаимодействия с пользователем (это кстати, не только внешний вид окон и количество кнопок), должен быть ПОЛНОСТЬЮ сделан ДО начала программирования. И заниматься этим должны НЕ программисты. 
Можно сделать абсолютно настраиваемый GUI, но пользоваться им будет невозможно   

Из законов Мерфи: 'Сделайте программу, которой сможет пользоваться даже самый законченный кретин, и только самый законченный кретин и сможет с ней работать'.

Леопольд штука в том, что я не всегда вижу (да и опыта не так уж много) когда можно применить какой-нибудь паттерн, чтобы в будущем облегчить себе жизнь.
xvr, за книжку спасибо почитаю (хотя интерфейс все же придется делать мне =))

Делать и проектировать - не всегда одно и тоже   

Делать то всегда мне, но иногда общий принцип мне подкидывают. Доделывать детально все равно моя задача.

Это все, конечно, здорово, но не жизненно. Возможно, за исключением ситуаций, когда требуется делать что-то совершенно понятное, типа заполнения анкеты, да и то не факт.
У меня при разработке новой утилиты (какая-то обработка графических данных) все начинается с примерной идеи, что должна делать утилита. Непонятно даже, какие в конце концов будут управляющие параметры, а не то что интерфейс. Потому что часто даже алгоритм обработки до конца не ясен (только принцип).  Поэтому начальный интерфейс абсолютно до лампочки, лишь бы что-то двигалось. Потом делается начальное приближение (самим программистом), осознаются возможности алгоритма и общая логика управления процессом. И первое приближение интерфейса. Потом все это отдается "начальнику", он же заказчик\идеолог утилиты. Он смотрит, пробует, насколько пользователю, не знающему кишок, понятно, и т.д. Далее итерации.
Поэтому я делаю так: всегда есть "процесс" + "управляющие параметры" + "интерфейс". Процесс (это не обязательно один класс, это подсистема) имеет дело только с управляющими параметрами, интерфейс тоже. Чем четче поделишь, тем легче вносить изменения. Самое сложное - выжать все возможности из процесса. После этого итерации по доводке интерфейса проходят легко (от минут до часов, если серьезно интерфейс перекраивается).
Таких этапов может быть несколько - по мере осознания. Ни одна утилита никогда не пишется с первого раза. Я думаю, это единственный способ создать что-то удобное\полезное. Умозрительно все не пощупаешь.

нет такой науки. Есть дизайн 

а по сути:


полностью, на 100% согласен, но практически всегда ( на все эти 100% ) получается, что этим занимаются сами программисты, а интерфейс перерабатывается по 100 раз. Во всяком случае у нас в конторе.

Спасибо, Earnest, за развернутый ответ. Что то подобное я и хотел услышать. Сейчас буду укладывать это все у себя в голове =)

И слава богу. Вы что, не видели программ с чудовищным интерфейсом, которые не иначе как индусы по аутсорсингу делали? Это когда простейшее действие требует 105 походов в меню или нажатий кнопок. И сразу понятно: интерфейс спроектировал кто-то очень умный, но этот кто-то никогда не пробовал реально с этой фигней поработать, а не просто кнопки потыкать. Реально удобный интерфейс невозможно придумать умозрительно, его нужно обкатать, а это требует итераций.

Можно написать консольный интерфейс (на все случаи жизни) и  скриптовый фронтенд (GUI).

Это сообщение отредактировал(а) Леопольд - 23.11.2010, 17:28