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

Спасибо, хватит!

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

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

Трудно сравнивать или оценивать разные процессы и стили програм% мирования. Какой из них лучший? Какой гарантирует своевременную поставку продукта в рамках бюджета? Нельзя дать ответ, поскольку это неверные вопросы. Уместность того или иного процесса зависит от характера проекта и культуры вашей компании. Если у вас есть 20 программистов, которые понятия не имеют об объектно%ориентиро% ванном программировании и всегда пользуются только C, глупо будет пытаться строить ОО%продукт на Java.

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

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

1Мартин Фаулер «UML. Основы, 3%е издание. – Пер. с англ. – СПб: Символ%

Плюс, 2004.

Если следовать принципу Златовласки, то наиболее гибкий подход должен располагаться где%то посередине. Вы обязаны знать, по како% му процессу работаете и где его описание. Эффективная разработка требует дисциплины: чтобы вовремя выпустить что%то на свет, нужна согласованная стратегия (наличие реалистичного графика работы – это отдельная история; см. «Игры с планами» на стр. 517). Опытные программисты знают, в чем ценность их процесса разработки, а также его недостатки. Они знают, как работать с ним и когда нужно выйти из него. Хорошие программисты не только программируют. У них есть свои рецепты, и они знают, как адаптировать их к обстановке. Вот по% чему наша наука все еще является ремеслом.

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

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

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

Выбор процесса

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

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

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

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

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

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

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

Резюме

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

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