XP
Из всех новых методологий eXtreme Programming находится в самом центре всеобщего внимания. Именно благодаря XP активные методологии вызвали такой ажиотаж и всевозможные слухи.
Поначалу XP относили в лучшем случае к хакерству в худшем смысле слова. Многие до сих пор считают эту методологию чем-то вроде культа Вуду, несмотря на то, что ее основателем и главным идеологом является Кент Бек (Kent Beck) - всемирно известный эксперт по языку Smalltalk и разработке объектно-ориентированных систем. Другим видным пропагандистом XP является Мартин Фаулер (Martin Fowler) - тоже всемирно признанный ученый-исследователь и автор многочисленных публикаций на темы ОО систем, паттернов, UML и реструктуризации программ.
На данный момент уже сложилась достаточно обширная практика применения XP, доказывающая высокую эффективность этого подхода.
Чтобы понять XP, нужно забыть о том, что разработка ПО - это инженерная дисциплина. Ведь ни один инженерный проект не сталкивается в процессе реализации с такими проблемами, как изменение характеристик изделия в ходе разработки. Разве возможно, чтобы, например, при строительстве дома, позвонил заказчик и сказал: "Сделайте мне пятый этаж чуть пониже, шестой немного расширьте влево, а вместо лестницы установите американскую горку"? В программных проектах требования очень часто изменяются в ходе работ, не зависимо от первоначальной модели и архитектуры системы. Так что же тогда за процесс - программирование? В свете XP разработка напоминает написание книги группой авторов.
Согласитесь, что нет другого способа создать литературное произведение, кроме как писать его. Ведь сколь ни хорош был бы сюжет, сколь ни точен сценарий, сколь ни загадочны поступки героев, все это читатель сможет узнать только из готового, законченного произведения, а не из проекта. Нет другого способа написать хорошую книгу, кроме как постоянно следить за качеством каждой ее части и исправить недоработки в процессе написания.
Согласитесь, чтобы написать хорошую книгу группой авторов, нужно очень эффективно организовать их взаимоотношения.
А если над одним и тем же материалом будут работать по два человека, то, скорее всего, он получится более содержательный и объективный.
Все эти принципы применимы и при создании программной системы. Хотя Кент Бек и говорит, что они давно известны в практике программирования, только с появлением XP они действительно образовали эффективную методологию.
Простейшее работоспособное решение (Simplest thing that could possibly work)
Смысл XP заключается в спартанском лозунге о стремлении к совершенству через естественность и простоту. Мы принимаем мир таким, какой он есть: заказчика со всеми его желаниями, программирование со всеми его трудностями, программу со всеми ее недостатками. Мы не требуем технически грамотных пользователей, выдающихся архитекторов и интеллектуальных инструментов. Мы требуем одного - возможности эффективно работать. Для этого мы избавляемся от всей ненужной и бесполезной рутины, какую только сможем найти в нашем процессе разработки. То, что после этого останется - необходимо для создания качественного продукта в рамках бюджета.
Проникновение задачей (Personal involvement)
Естественно, XP не ограничивается общими фразами, подобным приведенным выше. XP - это настоящая методология, и она имеет определенный набор действий, которые должны выполняться соответствующим образом. В отличие от других методологий XP требует дисциплину и самоотдачу, сравнимую со спартанской, потому что нет никаких формальных процедур, регламентирующих процесс. Соответственно и руководитель XP разработки должен обладать высоким авторитетом и умением чувствовать ситуацию.
Постоянное общение
По мнению самого Бека и других специалистов, команда XP разработчиков не должна превышать 10-15 человек и они обязательно должны находиться в одном помещении, чтобы сократить до минимума издержки взаимодействия. При большем количестве участников проекта или отсутствия подходящего помещения, по крайней мере, постоянно контактирующие разработчики должны иметь возможность общаться без необходимости договариваться об этом предварительно.
Известны успешные проекты и больших коллективов, вплоть до 40 человек.
Наместник заказчика (On site customer)
Все зависит от команды, а также от заказчика, обязанного предоставлять полную и своевременную информацию о требованиях и оценках функциональности продукта. Разумеется, XP методисты не так наивны, чтобы ожидать идеального клиента в каждом проекте, и потому включают в команду разработчиков специального человека, представляющего заказчика, взаимодействующего с ним и отвечающего на вопросы программистов как можно яснее.
Парное программирование (Pair programming)
Разработчики, как правило, работают парами за одним компьютером. В то время как один набирает код, другой имеет возможность думать о последствиях принятого решения. Когда первый устанет, роли меняются. Такая практика позволяет эффективно делится опытом и приобретать знания об отдельном участке программы сразу нескольким людям, так что в случае ухода одного из, второй сможет быстро объяснить новичку все нюансы. Это особенно важно при данном виде разработки, когда вся документация создается в исходных текстах. Парное программирование - это наиболее широко распространенная информация об XP.
Общий стандартизованный код
В столь динамично развивающемся проекте, какой получается при XP разработке, ничто не должно мешать разработчикам улучшать систему, в том числе и принадлежность исходного кода кому-нибудь лично. В любой момент любой человек при достаточных основаниях может изменить любую часть программы. Этот факт приводит к пониманию того, насколько важно соблюдать общий стиль программирования и включать в код как можно больше комментариев. По сути дела, программный код XP проекта и есть документация, которая всегда отражает последние изменения.
Тесты вперед (Test first)
Также хорошо известной и зарекомендовавшей себя методикой является написание тестов до начала кодирования функций программы. Программист должен решить, каким образом можно проверить работоспособность будущего кода, и создать соответствующий тест, который может быть автоматически запущен в любое время и выдать результат: работает функция или нет.
Все тесты объединяются и, прежде чем вновь написанный или измененный код будет присоединен к проекту, производится тестирование на уровне модулей (unit testing).
Кроме этого, отдельная группа создает второй вид существующих в XP тестов - функциональные тесты (functional tests), которые проверяют работоспособность системы в целом перед поставкой заказчику и делают это в автоматизированном режиме.
Таким образом, "тесты вперед" подход, хотя и не гарантирует 100% работоспособности, все-таки предоставляет очень высокие гарантии качества и позволяет и программистам и заказчику чувствовать себя более уверенно на пути к окончательному выпуску продукта.
Ежедневная сборка (Daily builds)
Чтобы еще сильнее повысить качество, XP предписывает делать промежуточные выпуски системы как можно чаще, даже до одного раза в неделю. Сборку системы или отдельных подсистем рекомендуется производить как минимум ежедневно, чтобы можно было после рабочего дня в автоматическом режиме проверять с помощью функциональных тестов ее работоспособность, а в случае неполадок быстро исправить ошибки, которые при таком подходе могли быть сделаны только накануне. При регулярных выпусках системы пользователи имеют возможность своевременно сообщать о недоработках, что улучшает продукт по ходу разработки. Как говорит Кент Бек: "Оптимизм - болезнь разработчиков, мнение заказчика - лекарство".
Рассказы пользователей (User stories)
Как же можно разрабатывать систему, если нет ни утвержденных спецификаций, ни плана разработки, ни архитектуры, да еще постоянно вносятся изменения? Вот это - то самое чудо, которое стало возможным благодаря XP. Ответ прост как все гениальное: мы начинаем разработку как только понимаем, чего хочет заказчик В ДАННЫЙ МОМЕНТ. В последующем, мы перестраиваем программы так, чтобы отражать вносимые изменения. При этом мы планируем только то, что можем предвидеть, а разрабатываем только то, что востребовано.
Для проведения этого простого принципа в жизнь, в XP предназначена специальная процедура, называемая "Рассказы пользователей", которая означает то же, что и прецеденты использования (use cases) в UML, но не имеют никакого формального выражения.
Просто потребности пользователей должны быть осознаны всеми участниками проекта. Основную роль в этом играют неформальные встречи и дискуссии, а также "наместник" заказчика в группе разработки. Каждая "история" описывает какую-либо функциональную сторону системы и должна быть оценена по двум шкалам: "бизнес-ценность" и "величина риска". Затем эти "User Stories", ставшие уже полноценными требованиями, сортируются и на самом верху оказываются те, чьи бизнес или риск значение максимальны. Вот ими то и следует заняться в первую очередь. Риск не может быть устранен полностью, но заказчик должен о нем знать, а разработчики должны провести исследования и/или разработать прототипы, позволяющие обнаружить способы решения ожидаемых проблем.
Рефакторинг (Refactoring)
Как же писать программы в такой динамичной и постоянно меняющейся обстановке? Это объясняет другая, также нашумевшая техника XP, подразумевающая реструктуризацию и заключающаяся в осознанном подходе к вопросам модификации кода без потери его функциональности. Книга М. Фаулера подробно описывает этот процесс и включает большое количество примеров. На сайте www.retactoring.com поддерживается on-line версия каталога приемов реструктуризации и полезные ссылки. Конечно, программы модифицировали всегда, но только с появлением XP это стало не второстепенным занятием исправления просчетов, а полноценной техникой разработки, позволяющей вносить изменения таким образом, чтобы улучшать внутреннее устройство системы, а не приводить к ее деградации.
Разумное проектирование
Очень многие считают, что XP - это новый вид RAD (Rapid Application Development - Быстрая Разработка Приложений) технологии, которая зарекомендовала себя как недальновидная. На самом деле, XP не только поощряет проектирование, но и включает его в методологию. Как обычно, система требует тщательного планирования, но только уже без излишнего "пророчества" и требований к инструментарию. Для разработки общей архитектуры достаточно настенной доски для рисования.
Если потребуется, дизайн можно сфотографировать и включить в документацию проекта. Как всегда, следует выделить те компоненты, которые, скорее всего, потребуют модернизации и постараться создать для этого соответствующие условия. Большим уважением пользуются паттерны проектирования и различного рода эвристики. Как и любая деятельность в XP, планирование компонента должно начинаться только тогда, когда оно безусловно необходимо. Особенно рекомендуется откладывать на возможно более долгий срок определение пользовательского интерфейса, как наиболее часто изменяющуюся часть системы и наиболее сильно отражающуюся на пользователях.
"Экстремальная" символизация
XP является флагманом новых методологий и в наибольшей мере символизирует их ценности:
Как и все остальные прогрессивные методологии, XP не является жестко детерминированным процессом и предполагает настройку на конкретную ситуацию и людей в контексте существующего проекта.
Продолжение может последовать. Если эта тема Вас заинтересовала - пишите мне!
Александр Родыгин,
