Стив Макконнелл

В один ветреный день 1940 г. колебания неконтролируемо усилились, и
часть моста обрушилась (рис. 5#1).
Это наглядный пример грязной проблемы: до разрушения моста инженеры не
знали, что аэродинамика играет такую большую роль. Только построив мост (ре-
шив проблему), они смогли обнаружить дополнительный аспект проблемы, что
позволило им возвести новый мост, действующий и поныне.

Преподавателя, который дает
студентам задания и свободно изменяет их по завершении проектирования и
даже перед сдачей готовых программ, вероятно, облили бы дегтем и вываляли в
перьях. Однако в мире профессионального программирования такие изменения
происходят ежедневно.

Проектирование — эвристический процесс
Так как проектирование не детерминировано, методы проектирования
чаще всего являются эвристическими методами, т. е. «практическими пра#
вилами» или «способами, которые могут сработать», а не воспроизводи-
мыми процессами, которые всегда приводят к предсказуемым результатам.

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

По#моему,
управление сложностью настолько важно, что оно долж#
но быть Главным Техническим Императивом Разработки ПО.

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

Стремление к краткости методов программы помогает снизить нагрузку на ин-
теллект. Этому же способствует написание программы в терминах проблемной
области, а не низкоуровневых деталей реализации, а также работа на самом вы-
соком уровне абстракции.

Избегайте создания «хитроумных»
проектов: как правило, их трудно понять. Вместо этого соз-
давайте «простые» и «понятные» проекты. Если при работе над отдельным фраг-
ментом программы проект не позволяет безопасно игнорировать большинство
остальных фрагментов, он неудачен.

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

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