Проектирование

В общих вопросах вполне можно обсуждать и это.

Вот читая книгу Джона Роббинса Отладка приложений для Microsoft.NET и Microsoft Windows прочел следующее
[QUOTE='Джон Роббинс;212403'] Выражение «Сначала кодируй, потом думай» придумал мой друг Питер Иерарди.
Каждого из нас в той или иной степени можно упрекнуть в таком подходе. Игры
с компиляторами, кодирование и отладка — забавное времяпрепровождение. Это
то, что нам интересно в нашем деле в первую очередь. Очень немногим из нас
нравится сидеть и ваять документы, описывающие, что мы собираемся делать.
Однако, если вы не пишете эти документы, вы столкнетесь с ошибками. Вмес-
то того чтобы в первую очередь подумать, как избежать ошибок, вы начинаете
доводить код и разбираться с ошибками. Понятно, что такая тактика усложнит
задачу, потому что вы будете добавлять все новые ошибки в уже нестабилыгый
базовый исходный код, Компания, в которой я работаю, помогает в отладке са-
мых трудных задач. Увы, зачастую, будучи приглашенными для оказания помoщи
в разрешении проблем, мы ничего не могли поделать, потому что проблемы были
обусловлены архитектурой программ. Когда мы доводим эти проблемы до руко-
водства заказчика и говорим, что для их решения надо переписать часть кода мы
порой слышим: «Мы вложили в этот код слишком много денег, чтобы его менять*.
Явный признак того, что у компании проблема «Сначала кодируй, потом думай*!
Отчитываясь о работе с клиентом, в качестве причины, по которой мы не смогли
помочь, мы просто пишем «СКПД*.
К счастью, решить эту проблему просто: планируйте свои проекты.
...
Разработка ПО очень зависит от мелочей. Чем больше деталей вы проясните
до начала кодирования, тем меньше риск. Есть только один способ достичь долж-
ного внимания к мелочам — планировать ключевые события и реализацию своих
проектов, Конечно, это не означает, что вам нужно отойти от дел и сочинить тыся-
чи страниц документации, описывающей, что вы собираетесь делать.
Лучший документ такого рода, созданный мной, был просто серией рисунков
на бумаге (бумажные прототипы) UI. Основываясь на исследованиях и результа-
тах обучения у Джэйреда Спула и его компании User Interface Engineering, моя
команда рисовала UI и прорабатывала сценарии поведения пользователей. Делая
это, мы должны были сосредоточиться на требованиях к разработке и точно по-
нять, как пользователи собирались исполнять свои задачи. Если вставал вопрос,
какое поведение предполагалось по данному сценарию, мы доставали свои бумаж-
ные прототипы и вновь работали над сценарием...[/QUOTE]

Об этом и речь.
А ведь составление документации - это более высокий уровень.
Сейчас объясню.
Когда-то программеры набивали машинные коды, затем м. коды заменили мнемоники, еще дальше ... операторы и конструкции языков высокого уровня. Может дальше в будущем можно будет составить несколько диаграмм и на выходе получить готовое ПО. Ведь с базами данных это уже реальность).

[QUOTE='

Frosty;212538']Об этом и речь.
А ведь составление документации - это более высокий уровень.[/QUOTE]
Ой ли? Следуя такой логике, получается, что отладка - это тоже другой уровень, только я затрудняюсь сказать, выше он или ниже?
[QUOTE='

Frosty;212538']Может дальше в будущем можно будет составить несколько диаграмм и на выходе получить готовое ПО. Ведь с базами данных это уже реальность).[/QUOTE]Ага. А что тогда делать с дырявыми абстракциями?

2Sanila_san
1) Если «Сначала кодируй, потом думай», то да отладка - это высший пилотаж, которого могло бы и не быть, если анализ и проектирование проведены верно. чит. предыдущий пост m_Valery.
2)И причем тут эта статья? Это ж бредни хардкорного программиста, который вечно всем не даволен. Надо предложить вспомнить ему о ... Билле).

вообще то думать рекомендуется всегда :)