На Вики нашел такой метод:


Что скажете насчет этого? Кто какими методами программы разрабатывает?

Ну я так не пишу - хотя надо попробовать ради эксперимента и потом усовершенствовать собственный метод.
Я обычно  начинаю писать сначала, т.е. вход в систему или что-то подобное, а потом разрабатываю все формы(детальный дизайн каждой, обычно как я их разработал так они и остаются, за исключением случаев когда выясняется что что-то впоследствии оказалось дублем или вообще бессмысленным), потом каждый модуль по очереди в порядке нужности, а если есть 2 и более взаимосвязанных модуля, т.е. одни дёргают данные от других и возможность частичной проверки в принципе бессмысленна, то пишу всё скопом, потом трасиировка и получаю рабочий полностью код, а потом ещё сколько-то дней на доработку сообщений типа "эй, пользователь так нельзя, сюда не лезь и т.п.". А потом прогу можно дать какому-нить user'u тупо сказав "потыкай и попробуй разобраться" с небольшим пояснением что прога должна делать, потом опять отладка и всё  - обычно после этого прогу можно считать готовой.

Плохо. Потому что крайность.



Пишу ядро. Пишу юнит-тесты для него. Затем развиваю то, что есть.

Почему крайность? 

Потому что очень-очень редко бывает так, что структура программы изначально досконально известна. Я, например, за свою жизнь такого ни разу не встречал.

просто ты нихрена не понял из приведенной цитаты.
повтор важной части:



по сабжу: весьма удобный и правильный подход, в общем-то ничего нового, просто декомпозиция

Я думаю на это нужно потратить два месяца, чтобы всё досконально расписать, а потом садится писать.
Согласен то, что привёл ТС весьма идеализированная картина.

На самом деле это очень хорошая методика.

Но я обычно делаю все наоборот.
Мне кажется так удобнее.

Сперва разрабатываю дизайн, при этом становится полностью ясно,
какой функционал нужно будет на все это нацепить.

Потом, делаю из всего этого шаблоны, пишу функции/классы, 
которые помогают отображать отдельные элементы этого дизайна.

Потом пишу классы/подпрограммы, которые отвечают за бизнес логику.

И только потом собираю из этого готовую программу/скрипт.
 

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

Просто ты нихрена никогда не писал. Потому веришь в розовых слоников.




Ты неправильно думаешь.

Где ты там крайность увидел?

"Top-down" design (проектирование "сверху-вниз") - характерная черта структурного программирования. Когда Дейкстра (+Вирт, ...) предложили эту методологию, ООП не существовало. И речь, конечно же, шла о процедурном программировании. Тем не менее, методы - это теже процедуры. Так что их следует писать "сверху-вниз".

Это раз. Два - деление программы на модули. Это тоже проектирование "сверху-вниз".

Вот то-то и оно. Ядро ты как-то выделяешь. Опять-таки "сверху-вниз".  

Если включить в рассмотрение "мейнстримное" ООП, картина несколько меняется. Появляется место для "bottom-up" design (проектирование "снизу-вверх").

Обычно поступаем так:

• Определяемся с требуемой функциональностью. Это по-определению top level.
• "Top-down" design -> делим на объекты.
• Определяемся с классами. Вот тут да, "bottom-up" design.
• Но когда пишем каждый отдельный метод - "top-down" design.
• Юнит-тестирование - "bottom-up" design. Тестируется минимально возможный для тестирования компонент.

Ещё структурная обработка исключений упрощает "bottom-up" design. "Кидаем" "внизу" исключение, а там потом его отловим где-то повыше.

Короче, смешано оно обычно получается.  

Это сообщение отредактировал(а) kemiisto - 5.4.2010, 23:55

Я вот пишу справа на лево.
У меня "Right Left" дизайн.
Разработка всего сразу идёт паралельно и первым делом пишется то, что собственно пишется. Где оно находится по вертикали меня абсолютно не заботит, так как каждый раз стараюсь держать в голове не столь хитрую схему что где куда. Есть TODO лист, он делится на мажорный и минорный на которые каждый раз смотрю и черкаю. Если какая-то штука на экваторе требует переписания северного и южных полюсов переписываю всё. Переписываю всё постоянно. У меня ещё ни разу не было идеальных структур, поэтому я каждый раз всё меняю. Перехожу на другие системы шаблоны, бывает даже языки. Оптимизация идёт в процессе разработки. Тесты я не люблю, поэтому их вообще не делаю. Разве что когда мне кажется что оно более менее работает TODO лист бесконечно заполняется снова и снова...

Ну я какбэ об этом и говорил.




Я, конечно, их всех уважаю, но подходы теоретиков и практиков далеко не всегда совпадают. И, если в теории можно писать софт строго по определённой методологии, то на практике это оказывается геморроем.

Во-во, у меня то же самое. Только в итоге почему-то получается как у той секретарши, которая печатала со скоростью 1200 знаков в минуту   

Согласен. Я просто развил мысль.


Тут у меня только один вопрос: "классиков" читали? Или как обычно, "Пастернака не читал, но презираю"?