Что такое экстремальное программирование

Что такое экстремальное программирование

Практика для сильных

Разработчики любят рефлексировать о своих рабочих методах. У них постоянно появляются новые концепции и подходы к тому, как делать софт. И вот ещё один. 

Что такое экстремальное программирование

Экстремальное программирование (XP, eXtreme Programming) — это когда обычные приёмы разработки доводят до предела. Название пошло из математики от слова «экстремум» — так обозначается максимальное или минимальное значение на графике функции:

Что такое экстремальное программирование

Экстремальное программирование работает по тому же принципу: мы берём лучшие практики гибкого программирования и выкручиваем их на максимум. 

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

Все остальные части экстремального программирования получаются точно так же: берём идею и доводим до крайности. Чтобы было понятно, что откуда берётся в экстремальном программировании, мы покажем аналоги в обычном.

Коллективное владение кодом

Обычный подход: у кода есть автор, который отвечает за его правильную работу.

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

❌ По факту это часто приводит к спорам, чей код лучше и зачем кто-то полез улучшать то, что и так работало.

Стандарт оформления

Обычный подход: команда выбирает единый стиль оформления и написания кода.

Экстремальный подход: за оформлением смотрят супердотошно, пытаясь регламентировать и стандартизировать каждый чих, даже если он не влияет на работоспособность кода в целом. Идеально, когда при взгляде на код становится непонятно, кто его написал, — настолько он соответствует единым стандартам.

✅ Хорошая практика, которой часто не хватает многим разработчикам.

❌ Но не подходит, когда нужно получить рабочий код быстро. Причёсывание мелочей занимает много времени, но не влияет на работоспособность — только на удобство поддержки. 

Простота проектирования

Обычный подход: команда с самого начала выбирает примерную архитектуру проекта и придерживается её.

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

❌ Иногда это может навредить проекту, особенно когда вместо микросервисов получается монолит, к которому совсем другие требования.

✅ Зато текущая версия бодра, весела и сделана на актуальных технологиях.

Восьмичасовой рабочий день

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

В экстремальном программировании принудительно ограничивают рабочее время — 40 часов в неделю или по 8 часов с понедельника по пятницу. Не успел — твои проблемы, надо учиться успевать. 

✅ Идея в том, чтобы не перерабатывать и было время на отдых.

Непрерывная интеграция и частые релизы

Обычный подход: выпуск новых версий чаще всего привязан к спринтам — новая версия выходит раз в 1−2 недели.

В экстремальном подходе нужно выпускать код в продакшен каждый день, а лучше даже несколько раз в день. Как только код проходит все тесты, он идёт на выпуск.

🤔 С одной стороны, тесты пройдены, а значит, всё работает. С другой — меньше шансов переделать что-то, если придёт в голову более удачная мысль.

Рефакторинг

Обычный подход: программисты занимаются рефакторингом при закрытии технического долга.

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

🤔 Иногда рефакторинг ради самого процесса не лучшее занятие в программировании. Но когда программу рефакторят много раз, обычно она начинает работать быстрее, чего не скажешь о новых версиях современного софта. 

Сначала тесты, потом код

Обычный подход: сначала код, а потом к нему пишут тесты.

В экстремальном программировании используют test-driven development, то есть «тестами вперёд». Смысл в том, чтобы сначала написать автоматический тест, который пройдёт только код с нужной нам логикой, а после этого написать сам код. Если код не будет решать нашу задачу, значит, он не пройдёт тест. А если пройдёт, значит, он делает то, что нужно.

✅ Тесты — это в любом случае хорошо.

Заказчик участвует в разработке

Обычный подход: заказчик ставит задачу, периодически смотрит на результат и отвечает на вопросы команды, когда они возникнут.

В экстремальном программировании заказчик всегда доступен для вопросов, с ним обсуждают код, возможности алгоритмов и функции программы. Любой разработчик может позвонить заказчику в любой момент, чтобы что-нибудь уточнить. 

❌ Сложно найти заказчика, который будет доступен для вопросов 24/7 и ещё разбирается в алгоритмах.

Игра в планирование

Обычный подход: у команды есть примерный график выхода релизов и понимание, что должно получиться на выходе.

В экстремальном программировании команда встречается с заказчиком каждые несколько недель и планирует следующий этап: что делаем, что не делаем, что важнее всего сделать для проекта. Иногда это действительно напоминает игру, когда у команды есть записанные на карточках пожелания заказчика и их нужно выстроить в оптимальном для реализации порядке.

✅ Планирование не повредило ещё ни одному проекту.

❌ Заказчику нужно быть очень вовлечённым. 

Это хорошо или плохо?

Экстремальное программирование в первую очередь нужно для интереса команды: когда годами сидишь за компьютером и пишешь код по техзаданию, может быть очень тяжело. И такие практики очень бодрят как разработчика, так и клиента. А когда команда бодра, она лучше работает. 

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

Текст:

Михаил Полянин

Редактор:

Максим Ильяхов

Художник:

Алексей Сухов

Корректор:

Ирина Михеева

Вёрстка:

Кирилл Климентьев

Соцсети:

Виталий Вебер

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

Если вы это читаете, у вас больше шансов, чем у остальных.

easy
Как устроены беспилотные автомобили
Как устроены беспилотные автомобили

В них много алгоритмов и датчиков, но водитель всё равно нужен

easy
Что такое Lisp
Что такое Lisp

Старый, но до сих пор нужный язык программирования

easy
Сила машин. Объясняем на пузырях
Сила машин. Объясняем на пузырях

Сила — в повторениях и абстракции.

hard
Facebook хранил наши пароли в виде текста. Что это значит?
Facebook хранил наши пароли в виде текста. Что это значит?

Тут такое!

easy
Как на самом деле производят процессоры

Чтобы создать сверхмощный процессор, достаточно простого...

easy
Что такое Linux (и другие вопросы)
Что такое Linux (и другие вопросы)

Быстрое знакомство с самой многогранной операционной системой

medium
Убери руку с мышки!
Убери руку с мышки!

Как работать в три — пять раз быстрее с помощью горячих клавиш.

easy
Как работает брелок от домофона

И можно ли использовать его как флешку.

medium
«Поле чудес» в мультивселенной безумия
«Поле чудес» в мультивселенной безумия

Задача, немного сгибающая мозг (но решаемая)

easy
easy