Экстремальное программирование как “иммунная система”: опыт внедрения XP в E-commerce

Когда меняются правила игры

Представьте: на проекте одновременно меняются команды, заходят новые вендоры, а платформа обслуживает несколько сторов в разных регионах. Каждый со своими налогами, валютами и платёжными провайдерами. Поверх этого десятки интеграций: PIM, ERP, WMS, CRM, инструменты маркетинга и SEO.

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

Нужен был не просто новый процесс, а что-то вроде иммунной системы: механизм, который не лечит болезни постфактум, а распознаёт угрозы заранее и вырабатывает к ним «антитела». Такой системой для нас стали практики Extreme Programming (XP).

XP строится вокруг четырёх групп практик: обратная связь (Feedback), непрерывный процесс (Continual Process), понимание кода (Code Understanding) и условия работы (Work Conditions). Ниже о том, как каждая из них работает на нашем проекте и какие конкретные результаты приносит.

1. Feedback: проектирование как контракт

В классическом XP первая линия защиты — это тесты. Разработка идёт от тестов (Test-Driven Development), и они моментально сигнализируют о проблемах. При отсутствии стопроцентного покрытия автотестами роль такого «раннего сигнала» у нас взял на себя технический бриф (Technical Brief).

Технический бриф вместо слепой разработки. До первой строчки кода команда готовит детальный документ: позитивные и негативные сценарии, архитектурные решения, точки интеграции. По сути, это контракт между бизнес-аналитиком и разработчиком. Контракт, который даёт уверенность ещё до старта и отсекает категорию багов «а я не знал, что так тоже бывает». Если TDD даёт раннюю обратную связь через тесты, то технический бриф даёт её на уровне проектирования изменения и бизнес-логики.

Парное программирование (Pair Programming) для сложных зон. Парные сессии применяются точечно: для задач с высокой сложностью или «исторически запутанных» модулей. При изменении логики расчёта налогов для разных регионов, например, новичок садится с опытным тимлидом и они вместе проходят через легаси-код. Новичок получает контекст, а тимлид получает свежий взгляд и мгновенное ревью. Такой подход сократил количество багов на этапе код-ревью в 1,5 раза.

On-site Customer и Planning Game. Работа с продуктовой компанией даёт прямой доступ к бизнесу. Задачи оцениваются исходя из реальной сложности и зависимостей, а не в абстрактных единицах. Стейкхолдеры видят полную картину: «Фича на фронте простая, но доработка интеграции с ERP делает её дорогой». Это устраняет конфликты на этапе приоритизации, а не в середине релиза.

2. Непрерывный процесс (Continual Process): рефакторинг на опережение

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

Кейс с платежными провайдерами. В начале квартала анализируется Roadmap. Допустим, через три месяца нужно подключить пять новых платёжных провайдеров, а текущая архитектура не рассчитана на такое масштабирование. Вместо того, чтобы героически впихивать новый код в старую структуру за неделю до дедлайна, задачи на подготовку инфраструктуры создаются заранее.

Подготовка инфраструктуры (Infrastructure Enablers). Интерфейсы меняются, общая логика выносится в отдельные модули, код вливается в основную ветку задолго до того, как начнётся работа над конкретным провайдером. К моменту старта бизнес-разработки платформа уже готова к расширению. Разработчик не воюет с архитектурой, а просто реализует бизнес-логику.

Насколько важна эта привязка к роадмапу, хорошо показывает наш кейс с декомпозицией монолитного Angular-компонента. Рефакторинг был выполнен технически чисто и в срок, но вскоре после завершения заказчик пересмотрел концепцию экрана, и ветку пришлось заархивировать. Инженерный опыт не пропал, подходы к разделению ответственности и построению API компонентов применяются на других задачах. Но сам кейс стал для команды наглядным аргументом: плановый рефакторинг нужно соотносить не только с техническим состоянием кода, но и с тем, куда движется продукт.

Контроль качества через людей (Human-driven CI). CI/CD-пайплайны ловят синтаксические ошибки и падающие тесты. Но в мультирегиональной платформе критичнее другое: не сломает ли изменение для одного региона что-то в другом? Эту проверку выполняют техлиды через ручное ревью каждого Merge Request.

Маленькие релизы (Small Releases). После каждого рефакторинга проводится развёрнутое тестирование: изменения для региона «А» не должны задеть бизнес-логику в регионе «Б». Только после такой проверки код уходит в прод маленькими, безопасными порциями. Частота релизов выросла, а количество «сюрпризов» на проде снизилось.

3. Понимание кода (Code Understanding): единый устав для всех команд

Иммунная система работает, потому что умеет отличать «своё» от «чужого». В коде та же логика: когда над проектом работают несколько команд и вендоров, без единых правил коллективное владение кодом (Collective Code Ownership) превращается в коллективную безответственность.

Стандарты кодирования (Coding Standards). Зафиксировано всё: от правил именования переменных до паттернов обработки ошибок в точках интеграции. Это не рекомендательный документ, а закон проекта. Каждый новый разработчик изучает его до первого коммита. Код, который не соответствует стандартам, не проходит ревью. Без исключений.

Коллективное владение кодом (Collective Code Ownership). Благодаря единым стандартам и техбрифам любой разработчик может спокойно зайти в «чужой» модуль и внести правки. Мы ушли от ситуации «незаменимых людей» и страха перед старым кодом. Это позволяет быстро перебрасывать ресурсы на «горящие» направления без долгого погружения.

Простота решений (Simple Design). Отдельная борьба ведётся с оверинжинирингом. Задача разработчика: реализовать сценарии из брифа максимально простым и поддерживаемым способом. Абстракции на три уровня вглубь «на будущее» не приветствуются. Будущие задачи закрывает рефакторинг на опережение, а не спекулятивная архитектура.

4. Условия работы (Work Conditions): устойчивый темп

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

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

40-часовая рабочая неделя в нашем случае не бонус и не идеализм, а инвестиция в качество. Цена ошибки в коде, от которого зависят e-commerce продукты в нескольких регионах, слишком высока, чтобы допускать её из-за усталости.

Что это дало проекту

До внедрения XP-практик проект работал, но каждый релиз и каждая ротация команды были стрессом. После внедрения процесс стал управляемым.

• Прогнозируемость и стратегическое планирование разработки. Код готовится к изменениям заранее, на основе квартального планирования и целей бизнеса.
• Безопасное масштабирование команды. Новые команды и вендоры быстро входят в проект благодаря единым стандартам. Новички начинают приносить пользу на второй неделе, а не через месяц.
• Коллективная ответственность и поддержка. Любой модуль доступен любому разработчику, потому что написан на «общем языке» проекта, а парное программирование стало лучшим способом для новичков перенять контекст у опытных коллег и мгновенно провести ревью кода.