Парное программирование

Парное программирование (pair programming) - практика, при которой два (или более) разработчика работают над одним и тем же кодом одновременно, обеспечивая непрерывное ревью в реальном времени. Ансамблевое (mob) программирование расширяет этот подход: вся команда работает над одной задачей перед одним экраном. Оба метода переносят работу над качеством с этапа после разработки непосредственно в процесс написания кода.

Эмпирическая база рецензируемых исследований по парному программированию - одна из самых проработанных в программной инженерии, а сопоставление со схемой "соло + ревью" служит эмпирической опорой для аргументов вроде stop-using-pull-requests.

Исследования

Williams et al., 2000 - "Strengthening the Case for Pair Programming" (IEEE Software). Пары допускали на 15% меньше дефектов, чем разработчики-одиночки.
Hannay et al., 2009 - "The Effectiveness of Pair Programming: A Meta-Analysis" (Information and Software Technology). Самый полный метаанализ на сегодняшний день: небольшой, но статистически значимый положительный эффект на качество, наиболее выраженный на сложных задачах.
Arisholm et al., 2007 - "Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise" (IEEE TSE). 295 профессиональных разработчиков. Увеличение доли корректных решений на сложных системах на 48%. Наибольший выигрыш показали менее опытные разработчики: улучшение на 149% на сложных задачах.
Muller & Tichy, 2005 - "Two Controlled Experiments Concerning the Comparison of Pair Programming to Peer Review." Главный результат: пары и соло-программисты с peer review достигают эквивалентных затрат при одинаковом уровне качества. Фаза ревью при соло-разработке добавляет достаточно накладных расходов, чтобы сравнять итоговую стоимость с парной работой.
Madeyski, 2006 - эмпирическое исследование улучшения качества проектирования при классических инспекциях кода в сравнении с парным программированием.
di Bella et al., 2013 - "Pair Programming and Software Defects - A Large, Industrial Case Study."

Разбор тезиса Muller & Tichy

Именно на этот результат больше всего опирается stop-using-pull-requests: при сопоставимом качестве парное программирование обходится не дороже, чем соло + peer review. Интуитивное возражение ("вы удваиваете человеко-часы") упускает из виду, что соло+ревью тоже их удваивает, только растягивая по времени и распределяя между разными людьми.

Следствие, если принять этот вывод: парная работа не медленнее стандартного процесса; это тот же объём трудозатрат в другой форме. Мнимая эффективность схемы "разработчик пишет код один, а второй проверяет позже" не выдерживает прямого сравнения.

Честный пробел в доказательствах

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

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

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

Метаанализ Hannay и работа Muller & Tichy дают нам "сопоставимые затраты при равном качестве". Дальнейший шаг - это экспертное суждение, а не доказанный научный факт.

Ensemble (mob) programming

Ансамблевое программирование Вуди Зуилла (Woody Zuill) расширяет парное программирование на всю команду: один экран, передача клавиатуры по кругу, участие принимает вся команда. Ревью происходит после каждой написанной строки. Академические свидетельства пока носят предварительный характер, но среди практиков консенсус однозначен: когда вся команда создаёт код вместе, последующая инспекция почти ничего не добавляет.

Компромиссы:

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

Место в триаде T*D

Laforgia (stop-using-pull-requests) объединяет парное/ансамблевое программирование с TDD и trunk-based-development в триаду T*D:

TDD закладывает качество построчно ещё до появления самого кода.
TBD обеспечивает непрерывную интеграцию.
Парное/ансамблевое программирование (Team-focused Development) переносит ревью непосредственно в процесс создания.

Каждая составляющая компенсирует то, что упускают остальные. Парное программирование обеспечивает непрерывное ревью; TDD автоматически страхует от регрессий; TBD держит объём изменений достаточно малым, чтобы любые просочившиеся дефекты можно было легко исправить.

Ограничения и нюансы

Расход энергии. Качественная парная работа требует больших усилий: постоянная концентрация, коммуникация, согласование решений. По большинству отзывов, предельный порог составляет около 5-6 часов в день, после чего качество резко падает.
Совместимость характеров и навыков. Некоторые пары не срабатываются. Ротация помогает, но требует дополнительных затрат на координацию.
Распределённые команды. Парная работа при несовпадении часовых поясов заметно усложняется; работа в окнах пересечения рабочего времени проходит нормально. Для команд с минимальным пересечением асинхронные PR могут оказаться наименее плохим вариантом.
Пары джуниор+джуниор. Результат Arisholm в 149% был получен на парах из сеньора и джуниора, а не двух джуниоров. Два новичка в паре не обязательно продуктивнее одного.

Связанные страницы

stop-using-pull-requests - более широкий тезис, где парное программирование выступает командным элементом
code-review-knowledge-transfer - истинная цель ревью, которую парное программирование выполняет намного лучше асинхронных PR
trunk-based-development - практика интеграции, которую парное программирование делает жизнеспособной без последующих проверок и задержек
ship-show-ask - переходная модель для команд, пока не готовых работать в парах постоянно
programming-as-theory-building - концепция Наура: общая ментальная теория программы в голове команды является главным продуктом, а парная работа формирует её напрямую