ship-show-ask

Ship/Show/Ask - модель Роуэна Уилсенаха (Rouan Wilsenach, опубликована на martinfowler.com) для разделения изменений кода на три категории с разным подходом к ревью. Это промежуточный шаг между блокирующими асинхронными PR и полноценной trunk-based-development с парным программированием.

Три категории

Ship. Сливать напрямую в mainline без ревью. Подходит для рутинных изменений, в которых разработчик уверен: исправления опечаток, мелкий рефакторинг, обновление зависимостей, документированные паттерны.
Show. Открыть PR, влить сразу без ожидания, а ревью провести уже постфактум. Подходит для изменений, которые автор хочет обсудить, но которые не должны блокировать работу: новый код по существующим шаблонам, низкорисковые дополнения, задачи, о которых команде стоит знать, но которые не требуют предварительного одобрения.
Ask. Открыть PR и дождаться ревью перед слиянием. Для сложных или неочевидных изменений: архитектурных сдвигов, рискованного поведения, кода, в котором автор не уверен, или правок в областях, за которые автор не отвечает.

Категорию для каждого изменения выбирает сам разработчик. Команда договаривается о том, какие категории применимы к конкретным частям кодовой базы или типам изменений.

Почему это работает

Модель ставит под сомнение предпосылку о том, что все изменения требуют блокирующего ревью. На практике большинству изменений оно не нужно: у клиента Фаулера, упомянутого в stop-using-pull-requests, 91% PR получали аппрув вообще без комментариев. Это значит, что 91% изменений можно было провести через Ship или Show, ничего не потеряв в качестве ревью.

Выводя рутинную работу из цепочки блокирующего ревью, Ship/Show/Ask:

Снижает налог на ожидание, налагаемый PR (86-99% времени выполнения по данным Лафорджиа).
Развивает в команде навык доверия: явное принятие решения "я достаточно уверен, чтобы катить сразу" - это навык, который атрофируется при обязательных PR.
Сохраняет ревью формата Ask для изменений, где проверка действительно несёт нагрузку.

Место в процессе перехода

Лафорджиа помещает Ship/Show/Ask на второй этап пятиступенчатого пути отказа от PR:

Оптимизация PR (небольшие объёмы, быстрый SLA, один аппрувер).
Ship/Show/Ask.
Парное программирование + trunk-based development.
Ансамблевое программирование + TBD.
Полный T*D.

Второй этап - это первый момент, когда команда перестаёт воспринимать PR как универсальный инструмент. Модель работает без изменений в IDE, CI-пайплайне или инструментах развёртывания - меняются только договорённости о том, что требуется каждому конкретному изменению.

Ограничения

Требует от команды откалиброванного доверия: и в том, что автор Ship не зальёт лишнего, и в том, что автор Ask не просит разрешения там, где оно не нужно.
Требует хорошей дисциплины постмердж-ревью: Show работает только тогда, когда кто-то действительно читает влитые изменения и оставляет комментарии. Иначе Show превращается в "слил и забыл".
Не заменяет pair-programming: парное программирование проводит ревью в процессе написания кода, а Ship/Show/Ask - после. В статье они рассматриваются как дополняющие друг друга этапы.

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

stop-using-pull-requests - более широкий контекст, в котором Ship/Show/Ask выступает переходным этапом
trunk-based-development - целевое состояние, к которому Ship/Show/Ask ведёт команду
code-review-knowledge-transfer - истинная цель ревью, определяющая распределение между Ship, Show и Ask
stacked-prs / billjings-git-not-fine - проблемы в git workflow, которые Ship/Show/Ask обходит для рутинных изменений
laycock-review-by-exception - конкретный список того, что относится к Ask: фундаментальные архитектурные изменения, чувствительный периметр безопасности, огромный радиус поражения, незнакомая часть критической системы или ситуация, когда команда прямо заявляет о неуверенности