Инженерные практики XP и связи между ними

Быстрая сборка и непрерывная интеграция

Фундамент всего набора. Каждое изменение автоматически собирается и прогоняется через тесты; результат приходит за минуты.

Скорость здесь техническое требование, а не удобство. Сборка длиной в полчаса обходится локальными приёмами: изменения копят, объединяют реже, проверяют выборочно. Через месяц непрерывная интеграция существует только на схеме.

Второе правило — сломанная сборка чинится немедленно и имеет приоритет над новой работой. Команда, живущая с красной сборкой сутками, перестаёт ей верить, и сигнал теряет смысл.

Тесты вперёд

Цикл короткий: написать падающий тест на нужное поведение, написать минимальный код, чтобы он прошёл, привести код в порядок. Повторить.

Порядок здесь не формальность. Тест, написанный до кода, описывает требуемое поведение; тест, написанный после, обычно описывает то, что получилось, включая случайные особенности реализации.

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

Практическое правило для старых систем: новый код приходит с тестом, старый покрывается там, где идёт работа. Проект «покрыть всё» отменяют при первом срочном требовании.

Парная работа

Двое за одной задачей: один пишет, второй думает на шаг вперёд и замечает то, что первый пропускает. Роли меняются каждые несколько десятков минут.

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

Постоянная парная работа подходит не всем: она утомительна и требует совместимости людей. Выборочная — на сложных задачах, на незнакомом коде, при обучении новичка — даёт большую часть эффекта и почти не встречает сопротивления.

Рефакторинг

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

Опирается на тесты полностью: без них вы меняете код вслепую и узнаёте о поломке от пользователей. Именно поэтому рефакторинг ставят после тестов.

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

Простой дизайн

Решение делают самым простым из тех, что решают текущую задачу. Обобщение «на будущее» откладывают до момента, когда будущее наступит.

Логика прямая: предсказать будущие требования трудно, а поддерживать обобщение приходится всё время. Функция, добавленная на всякий случай, стоит не только разработки — её тестируют, объясняют и обходят годами.

Практика работает только вместе с рефакторингом. Простое решение без права его переделать превращается в короткое одеяло.

Запас в плане

Часть недельной ёмкости остаётся незанятой. Практика выглядит поблажкой и на деле защищает всё остальное.

Неделя, заполненная под завязку, ломается от первой срочной задачи, и жертвуют в такой момент тестами и рефакторингом — тем, что не видно снаружи. Через квартал от практик остаются одни названия.

На что опирается каждая практика

Фундамент на месте

Практики бесполезно оценивать по отдельности: важно, стоит ли под каждой опора. Проверьте снизу вверх.

Что из этого видно в трекере

Сами практики живут в системе сборки и в репозитории. В Shtab остаётся то, что связано с планированием: истории, критерии приёмки, запас ёмкости и видимый технический долг.

Частые вопросы