Автор: Listen IT · YouTube
Listen IT — образовательный канал об IT-методологиях, объясняет практики разработки коротко и без академической перегруженности. Этот выпуск — девятиминутный обзор Extreme Programming (XP).
Большинство разработчиков знают отдельные XP-практики: TDD, парное программирование, непрерывная интеграция. Многие применяют их в изоляции. Суть XP в том, что эти практики спроектированы как система: TDD даёт быструю обратную связь, парное программирование распределяет знание о коде, CI гарантирует, что интеграция не накапливает долг. Убери одно — другие становятся менее ценными. XP существовал до Agile Manifesto (Кент Бек опубликовал книгу в 1999-м), и многие принципы манифеста 2001 года прямо из него вышли. При этом XP как целостная система встречается в командах гораздо реже, чем Scrum, — хотя технические практики у него сильнее.
Кому смотреть: разработчикам, которые применяют TDD или CI по отдельности и хотят понять, зачем Кент Бек сложил всё это в одну методологию.
Из этого можно взять в работу: выбери две XP-практики, которые ты уже используешь (например, TDD и ревью кода), и попробуй применить их в связке — напиши тест вместе с коллегой до написания кода. Системный эффект виден только в паре.
XP строится на нескольких ценностях: коммуникация, простота, обратная связь, смелость и уважение. Это не декоративный список — каждая практика XP реализует одну или несколько из них. TDD реализует обратную связь и смелость: тест говорит тебе, сломал ли ты что-то, и даёт уверенность вносить изменения. Парное программирование реализует коммуникацию и обратную связь: второй человек видит ошибку до того, как она ушла в код. Это не совпадение.
Ключевые практики XP: TDD (тесты до кода), парное программирование (два человека за одной машиной), непрерывная интеграция (код интегрируется несколько раз в день), частые малые релизы, простой дизайн (не добавляй то, что не нужно сейчас), рефакторинг (постоянно, не «потом»), коллективное владение кодом (любой может изменить любой модуль).
Интересный угол: XP предполагает 40-часовую рабочую неделю как инженерную практику, а не декларацию ценностей. Переработки накапливают усталость, усталость ведёт к ошибкам, ошибки увеличивают технический долг, долг требует больше времени. Это инженерный аргумент, а не забота о работниках — хотя и она тоже.
Почему XP менее популярен, чем Scrum? Видео на это прямо не отвечает, но ответ лежит на поверхности: XP требователен к техническим навыкам команды. TDD и рефакторинг — не то, что можно «просто начать делать». Scrum легче внедрить процессуально, не меняя инженерную культуру. Поэтому XP часто живёт в командах по частям, а не целиком.