Как пасти котов. Наставление для программистов, руководящих другими программистами
Шрифт:
Буква «X» в аббревиатуре ХР означает «экстремальный». Эту характеристику многие деятели нашей индустрии признали вполне удачной. Впрочем, есть и такие, которые, уважая суть концепции, с некоторым презрением относятся к ее названию [120] . По-моему, в публикациях, посвященных этой «новой» методологии, равно как и в практической деятельности по реализации ее принципов, очень много полезного. Полагаю также, что материалы сайтапомогут вам сориентироваться в том, какие методы этого заметного (пожалуй, даже крикливого) течения стоит принять на вооружение. Хотя, если уж следовать духу ХР, получается, что вычленять из этой методологии отдельные элементы или смешивать ее с другими стилями нельзя – либо вы «экстремал», либо нет. Меня на это не купишь, хотя мотивация мне вполне понятна. Поборники экстремального программирования пытаются сказать примерно следующее: «Либо дисциплинируйтесь, либо убирайтесь из профессии – вам в ней нечего делать!» Вот это мне по душе –
120
См. колонку «Feedback» в журнале Software Developments за ноябрь 2001 года.
Гибкая разработка
В поисках новых методов для себя и своей команды вам еще не раз предстоит столкнуться с термином «гибкий» (agile). Любой эффективный метод разработки программного обеспечения является таким по свой природе. Гибкость означает способность к адаптации, к изменяющимся требованиям и развивающейся технологии, в том числе на этапе конструирования проекта. Мнения большинства специалистов в области разработки программных средств сходятся в одном: гибкость – это священный Грааль всех методик разработки. Существует даже общественная организация, состоящая из ведущих специалистов по разработке программных продуктов и ставящая своей целью пропаганду концепции гибкости [121] . Эти деятели даже опубликовали манифест, в котором обозначены четыре основные проблемы, свидетельствующие, в зависимости от решения, о гибкости тех или иных методов [122] .
121
См. http://www.AgileAlliance.org.
122
См. Alistair Cockburn, Agile Software Development (New York: Addison-Wesley, 2002), Appendix A.
1. Отдельные лица и взаимодействие или процесс и инструментальные средства.
2. Функционирующее программное обеспечение или комплексная документация.
3. Сотрудничество заказчиков или переговоры по контракту.
4. Реакция на изменения или следование плану.
Признавая определенную ценность положений, расположенных в правой части списка, авторы придают большую значимость его левой части.
Между так называемой «гибкой» школой и экстремальным программированием много параллелей. Действительно, в совещании, на котором был принят манифест гибкости, участвовали, помимо прочих, основатели концепции ХР. На самом деле методология гибкости – это, скорее, совокупность принципов, применимая к любым процессам и мероприятиям в области планирования, направленным на конструирование программных средств. В главе 6, рассуждая о методах технического проектирования, я упомянул термин [123] «адаптивная разработка программных средств», имея в виду деятельность, обусловливающую ваш успех в роли технического лидера. Так вот, адаптивная разработка тоже происходит от гибкости.
123
Этот термин взят из одноименной книги Джима Хайсмита (Jim Highsmith). См. библиографию.
Мнения большинства специалистов в области разработки программных средств сходятся в одном: гибкость – это священный Грааль всех методик разработки.
В отличие от других методов, рассматривающих предвидение изменений как малозначащий фактор, на который не следует обращать внимания, или как тенденцию в процессе разработки, которой нужно сопротивляться, концепция гибкости призывает к конструктивному и адаптивному реагированию на изменения. В этом свете ХР трактуется как подготовительная стадия к внедрению философии гибкости. Любой метод, предусматривающий фиксацию требований и следование предопределенному процессу, приводит к созданию не вполне адекватного программного продукта. Приведу цитату из Кокберна (Cockburn):
«Некоторые считают, что необходимым условием успешности проекта является следование заданному процессу. Те, кто придерживается такого мнения, тратят уйму энергии на проверку его соблюдения. Человек, твердо убежденный в том, что именно в процессе вся суть, может очень долго не обращать внимания на несоответствие между практикой следования процессу и его исходом» [124] .
Иначе говоря, методология гибкости снимает с нас шоры и открывает глаза на те вещи, которые рабы процесса не замечают.
124
Cockburn, op. cit., p. 5.
Перечисление этапов процесса разработки, основывающегося на методологии гибкости, противоречит самому ее духу. Методология гибкости рассматривает процесс разработки как опыт
Я крайне рекомендую вам порыться в литературе, посвященной гибким методам. Ресурсов по этому вопросу великое множество [125] . Не менее важно оценивать по стандарту гибкости те методы, которыми вы пользуетесь в данный момент. Представьте себе ситуацию, в которой плохо сформулированное коммерческое требование уточняется ближе к сроку завершения кодирования. Сможет ли ваша группа отреагировать на такое изменение без недопустимых задержек? Когда требования меняются во время цикла разработки, большинство из нас проклинают все вокруг. Тем самым мы пытаемся дистанцироваться от реального положения вещей – ведь чем глубже мы разрабатываем проблему реализации требования, тем больше двусмысленности обнаруживаем, а значит, возвращаемся к этапу определения продукта. Гибкие методы культивируют определенное восприятие неопределенности.
125
Примеры приводятся в работе Cockburn, op. cit. Обзор имеющихся ресурсов имеется также на сайте http://www.adaptivesd.com.
Мастерство – ядро любого успеха
Приведенный обзор методологий разработки приводит, как мне кажется, к единственному выводу – разрабатывать программы должны не инженеры, а мастера. Понятие мастерства не всегда легко поддается осмыслению. Я пришел из академической науки и на раннем этапе своей деятельности занимался инженерией; по этой причине я сперва отказывался признавать приоритет искусства перед наукой в процессе создания программных средств. Впрочем, вскоре я понял, что «сопротивление бессмысленно» [126] . Посмотрим, под каким заголовком вышел один из ведущих технических журналов в 1990 году [127] :
126
Похоже на «Звездные войны» правда?
127
Как вы помните, тогда не было ни Windows, ни графических пользовательских интерфейсов.
«Производители программных средств страдают от недостаточного контроля за качеством. По мере того как программные продукты становятся все более сложными, компаниям становится все сложнее контролировать миллионы строк кода сложных пакетов» [128] .
В статье под этим заголовком речь идет о зрелости программных продуктов (см. главу 6, в которой упоминается модель оценки зрелости продуктов) и количестве ошибок в расчете на строку кода. Там обсуждаются методы измерения количества ошибок, но совершенно не уделяется внимание наиболее важной проблеме: программные продукты создают люди, а отнюдь не процессы, исполняемые автоматами.
128
Electronic Business, October 15,1990, p. 147.
Программные продукты создают люди, а отнюдь не процессы, исполняемые автоматами.
Кто создает программные продукты? Мастера. Осознав, что мастера совершенно не пренебрегают наукой и инженерией, вам будет легче признать, что искусство (мастерство) главенствует над научным подходом. Рекомендую поразмыслить над тем, как нам всем прийти к достойному балансу искусства и науки/инженерии в себе, чтобы обеспечить превращения кода в полезные и качественные программные продукты. Я абсолютно согласен с Питом Макбрином (Pete МсВгееп) в том, что он пишет в предисловии к своей книге по мастерству разработки программных продуктов:
«Мастерство знаменует собой возвращение к корням разработки программных средств. Хорошие разработчики понимают (и всегда понимали), что программирование – это деятельность из области искусства. Какими бы потаенными и подробными техническими знаниями ни обладал разработчик, в конечном итоге процесс разработки приложений сводится к ощущению и опыту. Можно знать самые изощренные детали языка программирования Java, но при этом, не чувствуя эстетической стороны программ, так и не стать достойным разработчиком. Если же человек чувствует процесс разработки программных средств, знание конкретных технических деталей уходит далеко на второй план. Лучшие разработчики постоянно учатся новым технологиям и методологиям; постижение очередной технологии для разработчика должно стать обыденным занятием» [129] .
129
МсВгeen, op. cit., p. xv