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

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

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

Экстремальное программирование основано на том, что процесс разработки программного обеспечения — это процесс тесного и интенсивного взаимодействия между людьми. Хорошая методика разработки программ должна с максимальной эффективностью использовать сильные человеческие качества и сглаживать человеческие недостатки. На наш взгляд, ХР лучше других методик учитывает весь комплекс факторов, оказывающих влияние на людей, занятых разработкой программ. За истекшее десятилетие ХР является наиболее радикальной инновацией в индустрии производства программного обеспечения. В рамках ХР каждому участнику проекта назначается определенная роль с соответствующим набором полномочий. ХР способствует тому, что все участники проекта исполняют назначенные им роли, а следовательно, каждый из них действует в границах своей компетенции. Благодаря этому люди, принимающие участие в проекте, эффективно работают, как единая команда. Разработка программного продукта, решающего поставленную бизнес-задачу, выглядит как диалог, в котором принимает участие каждая из заинтересованных сторон. Заказчики формулируют пожелания (stories), назначают им приоритеты (priorities), создают приемочные тесты (acceptance tests), а также снабжают программистов и менеджеров всей необходимой информацией тогда, когда это необходимо. Программисты сообщают заказчикам предварительные оценки трудозатрат (estimates), а позже передают им работающий код в совокупности с тестами модулей (unit test). Менеджеры выступают посредниками — они уравновешивают требования заказчиков и затраты, необходимые для реализации этих требований программистами, кроме того, менеджеры разрешают споры и определяют, какие ресурсы требуются для работы над проектом с учетом постоянно меняющихся бизнес-условий.

XP определяет базовый набор ценностей и практик, позволяющих программистам эффективно заниматься там, что у них получается лучше всего: разрабатывать- программы. ХР позволяет отказаться от ненужных артефактов, характерных для большинства тяжеловесных методик разработки, так как подобные артефакты затрудняют движение к цели и изматывают разработчиков. Сложно вызвать интерес менеджмента к методике, которая обладает столь экстравагантным названием: "экстремальное программирование», и мы отлично понимаем это. Однако, если ваша компания действительно желает повысить эффективность процесса разработки программ, руководство компании должно невзирая па имя со всей серьезностью рассмотреть все те преимущества, которыми обладает ХР.

Кент Бек (Kent Beck) сформулировал ключевые ценности ХР в своей книге Extreme Programming Explained. Здесь мы опишем их очень коротко:

1.         Коммуникация (Communication). Если при работе над проектом возникает проблема, зачастую ее причиной является то, что в какой-то момент времени кто-то не сказал кому-то что-то очень важное. В ХР возникновение подобной проблемы маловероятно. Если вы работаете над проектом в стиле ХР, вы фактически не можете избежать общения.

2.         Простота (Simplicity). ХР всегда предлагает решать задачу самым простым способом из всех возможных (simplest thing that could possibly work). Кент выражает эту мысль следующим образом: «ХР формулирует предположение. ХР предполагает, что лучше сегодня написать самый простой код... чем сегодня потратить время на разработку более сложного кода, а завтра узнать, что этот код вам не нужен».

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

4.         Храбрость (Courage). Если вы двигаетесь не с самой высокой скоростью, вас постигнет неудача. Вы должны обладать храбростью для того, чтобы в нужные моменты времени совершать правильные поступки. Например, вы должны обладать достаточной храбростью для того, чтобы отказаться от кода, на разработку которого вы потратили значительное время. Вы должны обладать храбростью для того, чтобы преодолев половину пути и обнаружив серьезную ошибку, вернуться обратно и начать все с начала.

Каким образом поставить свою работу па фундамент этих ценностей? Для этого служат двенадцать практик, которых разработчики должны строго придерживаться в своей повседневной работе. Двенадцать практик ХР это:

1.         Игра в планирование (Planning Game) - диалог между заказчиками и разработчиками с целью определить текущие задачи, приоритеты и сроки реалии

2.         Тестирование (Testing) — как программисты, так и заказчики пишут тесты, позволяющие в любой момент времени убедиться в корректности работы системы.

3.         .Парное программирование (Pair Programming) — любой код разрабатывается одновременно двумя программистами, работающими на одном компьютере.

4.         Рефакторинг (Refactoring) — улучшение кода путем его переработки

5.         Простой дизайн (Simple Design) — постоянное видоизменение дизайна системы с целью его улучшения.

6.         Коллективное владение кодом (Collective Code Ownership) — правом вносить изменения в любой код системы обладает любой член команды.

7.         Постоянная интеграция (Continuous Integration) — интеграция продукта выполняется постоянно, по несколько раз в день.

8.         Заказчик на месте разработки (On-Site Customer) — рядом с разработчиками постоянно находится представитель заказчика, который работает вместе с ними.

9.         Частые выпуски версий (Small Releases) — каждая следующая версия продукта выходит вскоре после выхода предыдущей версии. Новые версии продукта внедряются в эксплуатацию как можно чаще.

10.      40-часоваярабочая неделя (40-hour Week) — разработчики не должны работать сверхурочно, так как от этого снижается производительность и качество их работы.

11.      Стандарты кодирования (Coding Standards) — все участники команды должны придерживаться общих стандартов кодирования.

12.      Метафора системы (System Metaphor) — простая аналогия, интуитивно понятная всем участникам проекта, описывающая собой внутреннее строение и функционирование системы.

13.      Открытая рабочая среда – разработчики находятся близко друг от друга и имеют возможность свободно общаться

Для многих все это покажется знакомым. Здесь нет ничего нового. Эти практики используются в индустрии разработки программного обеспечения на протяжении многих лет. Почему же в ХР эти практики приводят к значительно более впечатляющим результатам? Дело в том, что слово «экстремальное» в названии методики ХР означает в основном две вещи:

1.         ХР использует каждую из этих практик в «экстремальной» форме, то есть с максимально возможной интенсивностью.

2.         ХР комбинирует эти практики таким образом, что величина результата превышает величину суммы составляющих.

Что это означает? Если перепроверка (review) кода — это хорошо, значит, мы будем делать это постоянно, для этого мы будем программировать в парах. Если тестирование — это хорошо, значит, мы будем заниматься этим постоянно, для этого мы будем вначале писать тесты, а потом — тестируемый код. Если документация зачастую не соответствует реальному состоянию кода, значит, мы будем писать лишь необходимый минимум документации, а всю необходимую информацию о строении и функционировании программы будем извлекать из кода и прилагаемых к нему тестов. ХР не гарантирует того, что люди все время будут совершать только правильные действия, однако ХР облегчает им эту задачу и смягчает серьезность проблем, возникающих в результате ошибок. Практики в ХР комбинируются таким образом, что каждая из них способствует реализации других практик благодаря этому значительно увеличивается скорость и эффективность работы над проектом.

Давайте подробнее рассмотрим каждую из 12 практик и роль, которую они играют в ХР.