Читать «Рефакторинг с использованием шаблонов» онлайн - страница 14

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

Недостаточное проектирование

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

• У нас нет времени, мы не пытаемся наверстать упущенное или не имеем времени на реорганизацию кода.

• У нас недостаточно знаний о том, что такое хороший программный дизайн.

• От нас требуется быстро добавить новую функциональность к существующим системам.

• Мы работаем одновременно над слишком многими проектами.

По прошествии времени недостаточно спроектированное программное обеспечение становится дорогим, сложным в сопровождении или просто полностью несопровождаемой неразберихой. Брайан Фут (Brian Foote) и Джозеф Йодер (Joseph Yoder), создавшие язык шаблонов Big Ball of Mud, описывают такое программное обеспечение следующим образом:

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

Имена переменных и функций могут быть неинформативными и даже вводить в заблуждение. Функции могут широко использовать глобальные переменные, а также длинные списки неудачно определенных параметров. Сами функции длинны, запутанны и выполняют несколько несвязанных задач. Код дублируется. Поток управления труден для понимания и сложен для следования. Намерения программиста почти невозможно разглядеть. Код попросту не читается и граничит с неподдающимся расшифровке. В нем проявляются несомненные признаки заплат на заплатах от рук многочисленных сопровождающих, каждый из которых едва ли понимал последовательность своих действий [14, с. 661].

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

Постоянное недостаточное проектирование приводит к резкому снижению темпов разработки программного обеспечения, проходящему примерно так, как описано ниже.