Программное обеспечение – эволюция или революция?

Как развивается код?

Еще несколько метафор для построения программ

Мы уже рассматривали метафору здания и обсуждали, как она применима к процессу построения программного обеспечения (см. раздел «Действительно ли мы собираем программы?» на стр. 240). В этой главе я приведу еще несколько метафор. Они бросают новый взгляд на наши методы программирования:

Выращивание программного продукта

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

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

Эволюция программного продукта

Другая распространенная метафора строительства – это эво# люция программного обеспечения. Мы начинаем с простей% шего одноклеточного организма кода и наблюдаем, как он по% степенно превращается в крупный и более сложный. Это про% цесс наращивания; программное обеспечение проходит через ряд стадий эволюции. Однако, в сравнении с биологической эволюцией, есть ряд важных различий:

•Мы намеренно совершаем изменения; программное обес% печение не может развиваться самостоятельно.

•Мы не пользуемся естественным отбором при выборе лучшей конструкции. У нас нет ни времени, ни желания разрабатывать многочисленные варианты одной и той же программы.

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

и может заслужить уважение и восхищение. Оно может расти дальше, возможно, достигнув среднего возраста и утратив юношескую привле% кательность. Со временем оно изнашивается и стареет и в конечном счете уходит на покой, попадая в цифровой отстойник, где может спо% койно умереть.

В этой главе мы посмотрим, как культивируют программы, особенно после начального цикла разработки. Программы нуждаются в проду% манном уходе и редко получают те заботу и внимание, которых заслу% живают. Что можно сделать, чтобы предотвратить медленное распол% зание рака по коду, ведущее к его преждевременной смерти?

Чтобы ответить на этот вопрос, вернемся назад. Мы рассмотрим при% знаки неправильного развития кода, изучим, как мы выращиваем свой код, и определим некоторые стратегии разработки более здорово% го программного обеспечения.

Гниение программного обеспечения

Если ты молод, то растешь. Если ты созрел, то гниешь.

Рэй Крок

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

Существует заблуждение, будто бы программное обеспечение развивает% ся только на начальных стадиях своего существования. Самой длитель% ной всегда оказывается стадия сопровождения1 программного продукта. На нее уходит самая значительная часть всего труда – даже если этот труд не сконцентрирован так компактно, как на этапах начального про% ектирования и разработки. Б. У. Боэм (B.W. Boehm), уважаемый в об% ласти вычислительных наук ученый, подсчитал, что от 40 до 80% сум% марного времени разработки приходится на сопровождение (Boehm 76).

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

1Имеется в виду работа, выполняемая после начальной поставки продукта,

которая не считается основной новой версией.

1Многими старыми программами не предполагалось пользоваться после 2000 года, поэтому программисты не боялись указывать год двумя цифра% ми – 76 вместо 1976. Как только цифры перевалили за 00, все вычисления

с датами пошли наперекосяк.