Почему 90% программистов неправильно понимают экстремальное программирование и как это мешает им в работе? Реальные примеры из практики и правило, которое изменит ваш подход к коду.
Введение: Книга, которую все цитируют, но никто не читает
Более 20 лет назад вышла книга Кента Бека «Экстремальное программирование». Её русский перевод стал культовым, но большинство разработчиков знакомы с ней лишь по статьям на Хабре или кратким пересказам в духе «пиши тесты первым». Это всё равно что судить о «Войне и мире» по цитате «все несчастливые семьи несчастливы по-разному» — да, верно, но это лишь 1% смысла.
На самом деле в книге есть всё: паттерны проектирования, правила написания тестов, практические примеры рефакторинга. Но главное — там описан цикл разработки, который занимает 90% времени программиста. И он начинается не с кода, а с тестов. Почему? Сейчас разберёмся.
Цикл TDD: Где прячется настоящая скорость
Автор книги описывает процесс так:
- Пишем тест — он сразу падает (красный).
- Пишем минимальный код чтобы тест прошёл (зелёный).
- Рефакторим код, улучшая его структуру.
- Повторяем.
Кажется, всё просто. Но главный секрет не в порядке действий, а в времени цикла. Одна итерация должна занимать не больше 15 минут! Зачем? Чтобы разработчик мог:
- Проходить цикл многократно за день.
- Корректировать работу после каждого шага.
- Держать в голове минимум контекста.
Это как готовить сложное блюдо: вы не варите суп 5 часов без проб, а постоянно пробуете, солите, добавляете специи. Иначе результат будет непредсказуем.
Почему тесты — это не главное?
Обычно TDF воспринимают как «принуждение к тестированию». Но это ошибка. Тесты здесь — лишь инструмент обратной связи. Они отвечают на вопрос: «Работает ли то, что я сделал?».
Настоящая цель — скорость разработки. Когда вы каждые 15 минут получаете сигнал «всё ок» или «ошибка», вы:
- Не накапливаете технический долг.
- Не тратите часы на отладку.
- Можете смело экспериментировать.
Пример из практики: в одном из проектов мы внедрили короткие циклы TDD. Через месяц скорость выпуска фич выросла на 40%, потому что разработчики перестали бояться ломать код.
Правило моего тимлида: Как организовать код без боли
Уже давно сформулировалось правило, которое часто применяется многими:
«Любой разработчик должен за 2 команды в консоли установить зависимости и запустить тесты. Локальные тесты должны совпадать с тестами в CI/CD».
Как это выглядит на практике:
- Скрипты для установки — make install или npm ci без ручных шагов.
- Единая среда — Docker или виртуалки для устранения расхождений между ОС.
- Тесты запускаются одной командой — make test или npm test.
- CI/CD копирует локальное поведение — никаких «у меня работало».
Да, это требует усилий: шаблоны репозиториев, вынесение общего кода в библиотеки, настройка пайплайнов. Но выхлоп — стократная экономия времени ежедневно.
Инструменты, которые снимут 80% рутины
Вот что ещё добавит скорости:
- Линтеры и форматтеры в pre-commit хуках — код сразу попадает в репозиторий чистым.
- Автоматические тесты на каждый коммит — вы знаете о поломке через минуту.
- Скрипты развёртывания — никакого ручного копирования файлов.
Это не «магия для гиков», а базовые практики. Их отсутствие — красный флаг для команды.
Как продать это бизнесу?
Бизнес не любит «технические хотелки». Но если объяснить на языке денег:
«Внедрим TDD и автоматизацию — и стоимость каждой следующей фичи будет снижаться на 20-30%».
Почему? Потому что:
- Меньше багов = меньше часов на исправления.
- Быстрее онбординг новых разработчиков.
- Меньше рутины = больше времени на фичи.
Вывод: TDD — это про скорость, а не про тесты
Если вы до сих пор думаете, что TDD — это «писать тесты первыми», перечитайте Кента Бека. Это метод контроля над разработкой, который экономит часы, нервы и деньги.
Начните с малого:
- Внедрите короткие циклы обратной связи.
- Автоматизируйте запуск тестов.
- Убедите команду попробовать это на одном модуле.
Результат удивит вас. А если нет — значит, вы всё сделали неправильно 😉
А вы используете TDD? Или считаете это пережитком? Делитесь в комментариях — поспорим!