Наши программные проекты определяются теми стилями и процессами, которые мы применяем. Они неизбежно отражаются на форме и качестве кода.

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

Процессы разработки

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

Выбор вами процесса разработки определяет планирование проектов, переход работы из одной фазы в другую и взаимодействие между чле% нами команды, осуществляющей проект. Различие между процессами проявляется по разным направлениям:

Толстый/тонкий

Толстый процесс разработки тяжел и бюрократичен. Он создает массу бумажных документов, регламентирует поведение разработ% чиков и предполагает определенную структуру команды. Его ха% рактеризует организационная модель ISO 9000, в которой каждая производственная процедура раболепно расписана во всех деталях, несмотря на изъяны или неуместность процесса.

На другом полюсе располагаются тонкие процессы разработки, из% бегающие ненужной бюрократичности и благоприятствующие бо% лее скромным и ориентированным на людей принципам. Такую практику поддерживают процессы ускоренного программирования, описанные на стр. 547.

Последовательность событий

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

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

Направление проектирования

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

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

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

Теперь пристегните ремни безопасности, и мы начнем наше голово% кружительное путешествие по процессам разработки программного обеспечения.

Ad Hoc

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

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

Таким хаотическим способом создаются многие программы с откры% тым исходным кодом.1 Если есть бесконечное число обезьян и беско% нечное число компьютеров, то е]сть шанс, что получится программа, но ждать придется бесконечно долго. Даже эскиз, сделанный на салфет% ке, – это шаг в направлении более формального и предсказуемого про% цесса разработки.

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

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

Каскадная модель

Каскадная модель представляет классический цикл разработки про% граммных продуктов. Ее много критикуют за простоту (и даже за ста% ромодность). Однако на ней в какой%то мере базируются практически все процессы разработки. У нее много недостатков, но, несмотря на них, это полезная отправная точка в изучении процессов. Она сделана по подобию более традиционного жизненного цикла в инженерном де% ле и была описана Ройсом в 1970 году (Royce 70). Это самый предска% зуемый среди всех процессов разработки.

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

Традиционная каскадная модель показана на рис. 22.2.2 Вы видите пять обычный стадий, описанных во врезке «Стадии разработки». Ко% гда одна стадия успешно закончена, с помощью некой промежуточ# ной процедуры (обычно это обзорное совещание) осуществляется пере% ход к следующей стадии. На выходе большинства стадий появляется

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

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

нию; водопад был опорочен.