Разработчики любят рефлексировать о своих рабочих методах. У них постоянно появляются новые концепции и подходы к тому, как делать софт. И вот ещё один.
Что такое экстремальное программирование
Экстремальное программирование (XP, eXtreme Programming) — это когда обычные приёмы разработки доводят до предела. Название пошло из математики от слова «экстремум» — так обозначается максимальное или минимальное значение на графике функции:
Экстремальное программирование работает по тому же принципу: мы берём лучшие практики гибкого программирования и выкручиваем их на максимум.
Например, в обычном программировании есть код-ревью, когда одни программисты проверяют код других перед тем, как код попадёт в проект. Если эту идею довести до максимума, то получится парное программирование: один разработчик пишет код, а второй тут же проводит код-ревью и следит за ошибками.
Все остальные части экстремального программирования получаются точно так же: берём идею и доводим до крайности. Чтобы было понятно, что откуда берётся в экстремальном программировании, мы покажем аналоги в обычном.
Коллективное владение кодом
Обычный подход: у кода есть автор, который отвечает за его правильную работу.
Экстремальный подход: каждый может зайти в любой фрагмент кода и поправить там что угодно, если считает нужным. В итоге каждый может исправить чужую ошибку в любом месте.
❌ По факту это часто приводит к спорам, чей код лучше и зачем кто-то полез улучшать то, что и так работало.
Стандарт оформления
Обычный подход: команда выбирает единый стиль оформления и написания кода.
Экстремальный подход: за оформлением смотрят супердотошно, пытаясь регламентировать и стандартизировать каждый чих, даже если он не влияет на работоспособность кода в целом. Идеально, когда при взгляде на код становится непонятно, кто его написал, — настолько он соответствует единым стандартам.
✅ Хорошая практика, которой часто не хватает многим разработчикам.
❌ Но не подходит, когда нужно получить рабочий код быстро. Причёсывание мелочей занимает много времени, но не влияет на работоспособность — только на удобство поддержки.
Простота проектирования
Обычный подход: команда с самого начала выбирает примерную архитектуру проекта и придерживается её.
Экстремальный подход: команда выбирает архитектуру и идею реализации только текущей версии, не планируя наперёд. Вот будут новые задачи и шаги — тогда и будем проектировать дальше.
❌ Иногда это может навредить проекту, особенно когда вместо микросервисов получается монолит, к которому совсем другие требования.
✅ Зато текущая версия бодра, весела и сделана на актуальных технологиях.
Восьмичасовой рабочий день
Обычный подход: в команде есть какая-то договорённость о рабочем времени либо о количестве реализованных идей в неделю. При этом, если надо, можно немного переработать или остаться на выходные.
В экстремальном программировании принудительно ограничивают рабочее время — 40 часов в неделю или по 8 часов с понедельника по пятницу. Не успел — твои проблемы, надо учиться успевать.
✅ Идея в том, чтобы не перерабатывать и было время на отдых.
Непрерывная интеграция и частые релизы
Обычный подход: выпуск новых версий чаще всего привязан к спринтам — новая версия выходит раз в 1−2 недели.
В экстремальном подходе нужно выпускать код в продакшен каждый день, а лучше даже несколько раз в день. Как только код проходит все тесты, он идёт на выпуск.
🤔 С одной стороны, тесты пройдены, а значит, всё работает. С другой — меньше шансов переделать что-то, если придёт в голову более удачная мысль.
Рефакторинг
Обычный подход: программисты занимаются рефакторингом при закрытии технического долга.
В экстремальном программировании рефакторингом занимаются постоянно: в каждом фрагменте кода наверняка можно что-то улучшить, а значит, можно брать любой старый код и переписывать его в любой момент. Благодаря этому все стараются писать простой код, чтобы при рефакторинге было меньше шансов сломать логику.
🤔 Иногда рефакторинг ради самого процесса не лучшее занятие в программировании. Но когда программу рефакторят много раз, обычно она начинает работать быстрее, чего не скажешь о новых версиях современного софта.
Сначала тесты, потом код
Обычный подход: сначала код, а потом к нему пишут тесты.
В экстремальном программировании используют test-driven development, то есть «тестами вперёд». Смысл в том, чтобы сначала написать автоматический тест, который пройдёт только код с нужной нам логикой, а после этого написать сам код. Если код не будет решать нашу задачу, значит, он не пройдёт тест. А если пройдёт, значит, он делает то, что нужно.
✅ Тесты — это в любом случае хорошо.
Заказчик участвует в разработке
Обычный подход: заказчик ставит задачу, периодически смотрит на результат и отвечает на вопросы команды, когда они возникнут.
В экстремальном программировании заказчик всегда доступен для вопросов, с ним обсуждают код, возможности алгоритмов и функции программы. Любой разработчик может позвонить заказчику в любой момент, чтобы что-нибудь уточнить.
❌ Сложно найти заказчика, который будет доступен для вопросов 24/7 и ещё разбирается в алгоритмах.
Игра в планирование
Обычный подход: у команды есть примерный график выхода релизов и понимание, что должно получиться на выходе.
В экстремальном программировании команда встречается с заказчиком каждые несколько недель и планирует следующий этап: что делаем, что не делаем, что важнее всего сделать для проекта. Иногда это действительно напоминает игру, когда у команды есть записанные на карточках пожелания заказчика и их нужно выстроить в оптимальном для реализации порядке.
✅ Планирование не повредило ещё ни одному проекту.
❌ Заказчику нужно быть очень вовлечённым.
Это хорошо или плохо?
Экстремальное программирование в первую очередь нужно для интереса команды: когда годами сидишь за компьютером и пишешь код по техзаданию, может быть очень тяжело. И такие практики очень бодрят как разработчика, так и клиента. А когда команда бодра, она лучше работает.
С другой стороны, если перегнуть палку и возвести принцип в абсолют, можно получить много ненужных телодвижений и потраченного зря времени. Таков риск.
