На слайде представлены так называемые
12 практик экстремального программирования,
рекомендованные автором Кентом Беком.
И здесь важно отметить, что
все эти практики должны быть реализованы в совокупности.
Если мы выбрасываем хоть одну,
то как правило весь процесс распадается,
становится действительно анархичным
и разработка уже не приносит тех плодов,
как если бы мы использовали все эти подходы,
все эти принципы вместе.
Среди этих принципов есть довольно экзотичные,
как скажем, парное программирование,
которые подходят, может быть не всем,
может быть не всем нравятся,
но которые, к сожалению, так или иначе надо использовать.
Я остановлюсь на самых основных из этих практик.
Прежде всего, это быстрый выпуск версий,
релизов и быстрые итерации.
Т. е. на самом деле каждая итерация длится,
наверное, не более недели,
каждый релиз выпускается не более, чем за месяц.
Т. е. мы действительно можем достаточно быстро
показывать заказчику, каким образом мы прогрессируем,
каким образом мы движемся вперед,
как мы дополняем ту функциональность,
которая ему крайне необходима,
и как мы меняемся в зависимости от тех требований,
которые возникают со стороны заказчика —
это могут быть новые требования,
это может быть коррекция существующих и т. д.
Метафора — очень важная вещь,
достаточно интересный принцип ХР,
который состоит в том, что для правильного
и единообразного понимания того,
как система будет работать,
мы должны выбрать одно слово
или несколько слов,
которые концентрированно описываю что же именно
мы собираемся делать, что должен делать наш продукт.
Для того чтобы корректно оттранслировать это
в терминологию заказчика, которая, на самом деле,
зачастую включает совершенно другие понятия,
мы используем метафору.
Простота реализации.
Я уже говорил о том, каждый фрагмент кода
должен быть реализован как можно более кратко,
как можно более лаконично,
как можно более просто, для того чтобы
не возникало последующих проблем
с его прочтением и, возможно, многозначной интерпретацией.
Опережающее тестирование — тесты до кода,
рефакторинг при этом, т. е. если это необходимо,
код рекомендуется упростить, упорядочить,
улучшить, но это уже после того,
как изменения приняты и включены в релиз,
и заказчик понял, что на самом деле,
вот таким образом, программное обеспечение
или его прототип вполне может работать.
Парное программирование — достаточно экзотичная методика
для некоторых разработчиков, которые, являются, может быть,
индивидуалистами, которые считают, что их код
является наиболее грамотным, наиболее надежным,
наиболее безопасным, наиболее хорошо документированным
или вообще он документирует сам себя
и никакая документация ему не нужна,
наиболее коротким, наиболее красивым и т. д.
Т. е. не хотят терпеть рядом с собой ментора,
наставника или какого-то подсказчика,
который рассказывает, как лучше писать код.
На самом деле, зачем нужно парное программирование?
Для того чтобы в случае, если мы теряем
одного разработчика по какой-то причине
на время или навсегда — он может перейти в другой проект,
он может, наконец, просто заболеть.
Совместное владение кодом обеспечивается в этом случае.
Непрерывная интеграция, 40-ка часовая неделя —
как мы говорили, никаких переработок,
хорошо оборудованное рабочее место,
постоянный контакт с заказчиком
и соблюдение основных метрик
и стандартов кодирования — вот то, что предписывает ХР.