15Экстремальное программирование Основные приёмы xp

венадцать основных приёмов экстремального программирования (по первому изданию книги Extreme programming explained) могут быть объединены в четыре группы:

1 Короткий цикл обратной связи (Fine scale feedback)

• Разработка через тестирование (Test driven development) А точнее – написание тестов ПЕРЕД написанием кода. В каждый момент времени, выполнив все тесты, мы можем сказать, что система работает так, как от нее ожидают. Очень часто это помогает при каких-то внутренних изменениях, которые не должны затрагивать функциональность, например, при рефакторингах. Да, команда тестировщиков в конечном итоге скорее всего выловит ошибку. Но сколько пройдет времени? Собрать версию, выложить ее на тестовый сервер, запуск нагрузочных тестов, запуск приемочных тестов. День. Если не больше. А могут вообще и не найти ошибку. И вылезет она только уже в рабочей системе, найдут ее пользователи. При том, что для выявления ошибки с помощью тестов нужно 20-30 минут. Столько, как правило, выполняются тесты в системах среднего размера.

• Игра в планирование (Planning game) Это та стадия, на которой вы обсуждаете с заказчиком, чего он хочет

• Заказчик всегда рядом (Whole team, Onsite customer) Идея проста. Чем длиннее цепочка, тем больше она напоминает испорченный телефон. Каким бы тщательным ни было планирование – некоторые вопросы все равно всплывут непосредственно в процессе реализации. И от того, насколько быстро и полно разработчик пообщается с заказчиком, зависит скорость реализации им задачи.

• Парное программирование (Pair programming) Итак, написание кода вдвоем. Что это дает? Прежде всего – мышление у людей не совпадает. В результате в каждой точке ветвления есть большая вероятность, что я и кто-то другой изберем разные направления движения. Т.е. родятся две идеи вместо одной. Соответственно, появляется возможность выбрать более оптимальную из них. оптимальность и ясность кода резко возрастает. Соответственно, падает количество ошибок,

2 Непрерывный, а не пакетный процесс

• Непрерывная интеграция (Continuous Integration) Зачем это надо. Чтобы быть уверенным, что продукт не сломан последними изменениями. Это дает возможность быстро отреагировать на возможные проблемы. Кроме того, "интеграция" вовсе не означает "компиляция". Это еще и всевозможные проверки целостности кода, включая запуск тестов.

• Рефакторинг (Design Improvement, Refactor) рефакторинг – это переработка системы для приведения в соответствие с текущими требованиями. При этом внешне система остается той же.

Частые небольшие релизы (Small Releases) Первое. Чем меньше функциональности в очередном релизе – тем легче его протестировать. Если вы поменяли половину системы, и тестирование выявило плавающую ошибку – вы поседеете раньше, чем ее найдете. Если в системе было одно единственное изменение – поиск практически тривиален. А потому – в этом отношении частые выпуски версий весьма выгодны.Второе. Чем чаще выпускается версия – тем быстрее заказчик получает требуемую функциональность. Как вы помните, на каждую версию в результате планирования составляется список историй с приоритетами. После выпуска заказчик получает всю эту функциональность.

3. Понимание, разделяемое всеми

Простота (Simple design) Если писать просто, но не корректировать систему под текущие требования – хорошо не будет. Если корректировать, но писать при этом очень сложно – тоже ничего хорошего. Ибо коррекция как раз будет направлена на то, чтобы разгрести изобретенную кучу незнам-чего. Если же писать просто, и постоянно при этом корректировать код – результат будет гораздо лучше.

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

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

Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership) Автор кода – вся команда. И всегда есть тот, кто за код отвечает. Это тот, кто менял его последним.

Стандарт кодирования (Coding standard or Coding conventions) Все члены команды в ходе работы должны соблюдать требования общих стандартов кодирования. Благодаря этому:члены команды не тратят время на глупые споры о вещах, которые фактически никак не влияют на скорость работы над проектом;обеспечивается эффективное выполнение остальных практик.

4Социальная защищенность программиста (Programmer welfare):

40-часовая рабочая неделя (Sustainable pace, Forty hour week) Производительность разработчиков сильно падает, если они вынуждены работать подолгу. 

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