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

Избавившись от необ#

ходимости проводить праздничную церемонию каждый раз, когда оператор язы#

ка C делает то, что было задумано, вы сэкономите время

Типичная история такова: «Мы пи#

сали новую систему на C++, но большинство наших программистов не имели

особого опыта работы на C++. Раньше они использовали Fortran. Они писали код,

который компилировался на C++, но на самом деле это был замаскированный

Fortran. В итоге они заставили C++ эмулировать недостатки языка Fortran (такие

как операторы goto и глобальные данные) и проигнорировали богатый набор

объектно#ориентированных возможностей C++».

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

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

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

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

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

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

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

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