Инженерная практика
Code review: перепроектируй процесс ревью
Читать про ревью — не то же, что чинить процесс ревью, который течёт дефектами и стопорит PR. Возьми реальный репозиторий — своей команды, open-source проект или намеренно запущенный, который сам соберёшь — диагностируй, где его пайплайн ревью ставит человеческое внимание не туда, и переинженерь его по полной модели юнита, доказывая, что каждое изменение двигает метрику.
Преврати ментальную модель юнита в работающий пайплайн ревью: автоматизируй разрешимое в блокирующий гейт до ревью, сделай PR маленькими, фидбэк — сортируемым, маршрутизируй и ограничивай очередь и проверь редизайн числами latency и качества до/после — не мнениями.
Возьми репозиторий с реальным или симулированным процессом ревью и перепроектируй его так, чтобы человеческое внимание попадало только на неразрешимый слой — измерив, что задержка подхвата падает, а доля механических комментариев снижается, без потери обнаружения дефектов.
- Таблица до/после: медианное время до первого ревью, медианное время до merge и процент комментариев ревью, которые механические против содержательных — измеренные из данных PR на обоих прогонах, не оценённые.
- Доказательство, что гейт работает: скриншот или лог PR, заблокированного гейтом до того, как его посмотрел человек, и снижение доли механических комментариев (люди больше не пишут комментарии, которые могла бы написать машина).
- Хотя бы одно по-настоящему крупное изменение, отгруженное как читаемая цепочка stacked diffs, где каждый PR в полосе 200–400 LOC, с заметкой о выбранных швах.
- Однастраничный разбор, называющий для каждого изменения (гейт, норма размера, конвенция комментариев, маршрутизация/SLA, форма ревью), какой принцип урока он применяет и какую метрику сдвинул — и честная заметка о любой метрике, которая НЕ улучшилась, и почему.
- Добавь метрику исхода против гейминга: отслеживай утёкшие дефекты (post-merge баги или реверты на PR) на обоих прогонах, чтобы подтвердить, что выигрыш latency не пришёл от скольжения — меряя исходы, а не активность, как требует урок об анти-паттернах.
- Собери дашборд нагрузки ревью: ожидающие ревью на человека и возраст каждого PR, чтобы организация перебалансировалась до того, как кто-то станет бутылочным горлом из урока о масштабировании.
- Запилоть post-commit (ship-then-review) на одном явно низкорисковом, хорошо протестированном пути среди доверенных коммиттеров, с feature-флагами и быстрым откатом, и задокументируй предусловия доверия/автоматизации, сделавшие его безопасным там, но неверным для денежного или auth-пути.
- Проведи калибровочное упражнение: пусть два ревьюера независимо отревьюят один средний PR и сдиффят свои комментарии, затем сверь лейблы важности — выявив, где модель команды «blocking против nit» расходится, и ужесточив конвенцию.
Это цикл, который ты запускаешь, когда реальный процесс ревью сбоит: сними baseline числами, толкни разрешимый класс в блокирующий гейт до ревью, чтобы ни один человек не писал комментарий, который могла бы написать машина, держи PR маленькими и стекай по-настоящему крупные, делай фидбэк сортируемым с важностью и фиксом, маршрутизируй на команду и ограничивай подхват, не завершение, и выбирай форму ревью по ставкам и доверию. Затем докажи числами latency и разбивки комментариев до/после — под охраной метрики утёкших дефектов, чтобы скорость не пришла от скольжения. Сделав это раз на реальном репо, ты превращаешь модель юнита в то, что можно установить на любой команде.