Экстремальное программирование (XP)

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

Методология разработки програмного обеспечения eXtreme Programming (изобретатель - Kent Beck) получает все боль�?ее признание благодаря максимальному упрощению процессов проектирования и непосредственной разработки програмных продуктов в среде с быстро изменяющимися требованиями.

Существует всего ли�?ь 5 ценностей экстремального программирования: простота, общение, обратная связь, смелость и уважение (”уважение” добавилось в последней редакции XP). На реализию этих основных ценностей и направлены 12 практических методик XP. Рассмотрим их в неболь�?ом приближении. Кроме изветных многим истин, добавлю свои комментарии по поводу практик, основываясь на своем практическом опыте.

Процесс планирования (planning game). В XP планирование - это основная часть разработки. То, что планы могут внезапно поменяться, учитывается еще в самом начале. Аппетит заказчика приходит во время еды и нужно всегда держать ситуацию под контролем. Общение с заказчиком должно происходить как можно чаще. Это позволит точнее оценить сроки выполнения задач и внести необходимые коррективы в случае необходимости.

Быстрый выпуск версий (small releases). Как бы красиво не был описан продукт, все прелести его использования можно понять только работая с ним. Методика быстрого выпуска версий позволяет понять, чего же хочет заказчик, обеспечивая ранний выпуск рабочих версий продукта.

Комментарий: Как показывает практика, первую раннюю версию можно сделать за 2-8 недель, не зависимо от ожидаемой сложности продукта. Желательно, чтобы первую версию продукта (хотя бы первые несколько итераций) делало 2 человека за одним компьютером. В этом случае очень быстро вырисовывается дизайн системы. Далее можно привлекать еще людей, перераспределив пары.

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

Комментарий: Достаточно сложная практика, хотя на первый вгляд и кажется простой. Придумать метафоры для основных модулей системы - это не просто, но очень полезно. Многие программисты относят “метафору системы” к управленческим практикам, но мне кажется, что боль�?е нужна она все-таки разработчикам. Правильный выбор метафор в конечном итоге поможет программистам придумать удачные названия классам и методам, что всегда положительно влияет на дизайн системы в целом.

Простота реализации (simple design). XP предлагает делать код программы простым. Зачем усложнять себе жизнь, если простую программу легче понимать и поддерживать и она менее подвержена о�?ибкам.

Опережающее тестирование (test-driven development). Экстремальное программирование рекомендует проверять существующий код как можно чаще. �?менно поэтому и практикуется данная методика. Тесты пи�?утся еще до того, как будет написан кусок кода. Это позволяет луч�?е понимать поставленные задачи и предоставляет возможность проверить код сразу, как только он будет написан.

Комментарий: У такого подхода есть масса плюсов.
Во-первых, писать тесты перед написанием кода - один из луч�?их способов гарантировать наличие этих самых тестов.
Во-вторых, исключается нежелание тестировать некоторые “очевидные” ветки выполнения программы, хотя бы потому, что кода еще нет :). Ну и потом, при парном программировании тесты дейтвительно будут лаконичными и качественными.
В третьих, тесты усиливают уверенность программистов в себе, когда у них возникает желание произвести рефакторинг.

Рефакторинг (design improvement). Добавление новой функциональности и увеличение объема кода усложняет разработку и поиск о�?ибок. Ре�?ением этой проблемы является постоянная переработка (refactoring) кода. Рефакторинг - очень мощная и полезная вещь и заслуживает не то что отдельной статьи, а целых книг.

Комментарий: Не забывайте о ценности “смелость” и не бойтесь поламать систему во время рефакторинга. Тесты покажут, что сломалось и вы быстро исправите о�?ибки. Даже если тесты не покрывали некоторые аспекты, и вы не заметите какие-то потенциальные проблемы - ничего стра�?ного, все всегда можно исправить. Главное, что дизайн системы стал проще и понятнее, а сложная система - это источник куда более ужасных о�?ибок, чем о�?ибки возник�?ие в результате рефакторинга.

Парное программирование (pair programming). Периодический просмотр чужого кода положительно влияет на его качество. Этот принцип лежит в основе парного программирования. Заключается оно в том, что два программиста одновременно работают за одним компьютером. Как ни странно, затраты на разработку не увеличиваются в два раза, а остаются приблизительно на том же уровне. С другой стороны при парном программировании повы�?ается качество кода, осуществляется неявная и явная передача знаний, а также проиходит постоянное общение между разработчиками.

Совместное владение кодом (collective code ownership). Чаще всего при разработке програмных продуктов за определенную часть кода отвечает один человек. Отпуск, увольнение или же болезнь (прости, Господи) одного из программистов может сильно затормозить разработку продукта. �?менно поэтому в XP за один кусок кода отвечает не менее двух человек и любой программист может внести изменения в любую часть програмного кода.

Продолжающаяся интеграция (continuous integration). Команды XP-программистов создают новые билды продукта несколько раз в день. Это позволяет всем программистам быть в курсе происходящего и предотвратить проблемы интеграции с другими продуктами и частями кода.

Комментарий: В на�?е время эта практика у молодых специалистов вызывает улыбку или даже непонимание, ведь есть svn, perforce, cvs и еще много чего. Это рань�?е двое дядек садилось возле главного компьютера и вручную мержились с основной веткой проекта.
Тем не менее эта практика актуальна до сих пор. Совместное владение кодом никто не отменял: не хоче�?ь тратить время на огромный и сложный merge - потратить время на несколько маленьких мержиков :).

40-часовая неделя (forty hour week). Ради дела люди спопобны на многое, но экстремальное программирование категорически против самопожертвования разработчиков. Человек должен отдыхать, именно тогда он достигнет максимальной производительности в рабочее время.

Комментарий: Тут даже и говорить нечего. То, что XP настоятельно рекомендует вводить сразу все практики (в том числе и forty hour week), многих программистов может убедить в необходимости введения XP в их проектах.

Контакт с заказчиком (on-site customer). Проблема, с которой часто сталкиваются разработчики, - это незнание предметной области, особенно, если она узкоспециализированная. Данная методика учит привлекать заказчика к процессу разработки для помощи в ре�?ении специализированных задач. Если возможности привлечь заказчика нет, иногда бывает полезным найм специалиста со стороны, работающего в необходимой отрасли.

Комментарий: Лично мне приятно работать с людьми, которые заинтересованы в продукте, который они заказали. Обычно очень трудно заставить заказчиков выделить человека, разбирающегося в предметной области. Поэтому не вижу ничего плохого, если он будет доступен хотя бы удаленно и хотя бы несколько часов в день.

Стандарты кодирования (coding standard). Для успе�?ной работы над проектом XP выдвигает требование применения стандартов при кодировании. Это в свою очередь обеспечивает успе�?ность таких методик как совместное владение кодом и парное программирование. Да и вообще, стандарты не для того, чтобы просто существовать, а для того, чтобы их придерживались.

Непротиворечивость всех этих методик позволяет заметно повысить качество продукта и выпустить его точно в срок. Еще одна прелесть XP - общение и повы�?ение квалификации программистов без отрыва от производства. Ну что ж, экстремальное программирование - в массы.

Updated 29.08.2009. Последнее время иногда слы�?у от project менеджеров такие слова: “XP - это фигня. Пытался внедрить на своем проекте - не работает это - система кривая получается из-за “простого дизайна”, по срокам не успеваем, так что на рефакторинг времени не даю. Парное программирование - это вообще утопия какая-то, реально один работает, другой по сторонам головой мотает.”

Дорогие менеджеры, хочу обратить ва�?е внимание на что, в XP вообще нет такого понятия как менеджер, да и быть не может. “Внедрить” у вас ничего не получится. XP работает только тогда, когда его необходимость понимает каждый член команды и когда каждый программист заинтересован в успе�?ном завер�?ении проекта. Кроме этого, заинтересован должен быть еще и заказчик, что тоже встречается не так уж и часто.

Скорее всего XP вам и не нужно. Просто попробуйте отнестись к своей работе серьезно, читайте литературу, можно того же Кента Бека. Уверен, что из книг по управлению проектами и по методологиям разработки ПО вы почерпнете множество интересных идей и практик, которые действительно можно обосновать и внедрить у себя в команде. Всего хоро�?его.