Как вы меняли культуру code review в команде? Приведите пример.

Исходное состояние

Когда я пришёл в команду, code review превратился в формальность: PR'ы висели по 3–5 дней, комментарии либо были пустыми («lgtm»), либо превращались в философские споры о стиле без итога. Merge делал тот, кто устал ждать. Новые инженеры не понимали, что именно ожидается от ревью.

Шаг 1: Диагностика через данные

Я выгрузил метрики из GitHub за два месяца: среднее время от открытия PR до merge, количество комментариев на PR, процент PR'ов с нулевым ревью. Это позволило говорить о проблемах конкретно, а не на уровне ощущений.

Шаг 2: Ревью-гайдлайн

Вместе с командой (не в одиночку) написали документ «Как мы делаем code review». Ключевые договорённости:

• SLA: первый ревьювер назначается в течение 4 часов после открытия PR, финальный ответ — в течение 24 часов в рабочий день.
• Уровни комментариев: nit: (необязательно), suggestion: (желательно), без префикса — блокирующий.
• Размер PR: не более 400 строк diff для обычных задач; крупные изменения разбиваются или предваряются design doc.
• Цель ревью: безопасность, корректность, читаемость — в этом порядке приоритетов.

Шаг 3: Личный пример

Я начал делать ревью публично — объяснял вслух (или в комментариях), почему задаю тот или иной вопрос. Первые два месяца специально указывал уровень каждого комментария, чтобы показать команде, как это работает на практике.

Шаг 4: Ретроспектива через месяц

На ретро спросил команду: «Что улучшилось? Что всё ещё раздражает?» Выяснилось, что SLA работает, но споры о стиле продолжаются. Решение: добавили .editorconfig, ruff для Python и eslint для TypeScript — автоматика убрала 80% стилевых дискуссий.

Результат через квартал

Среднее время PR-цикла снизилось с 4.2 до 1.8 дней. Новые инженеры начали давать качественные ревью уже на второй неделе — гайдлайн работал как onboarding-артефакт.

Подводные камни

• Вводить правила без участия команды — они воспринимаются как навязанные и саботируются.
• Не разделять блокирующие и необязательные комментарии — автор PR не знает, что именно нужно исправить перед merge.
• Решать стилевые вопросы в ревью вместо линтеров — это трата времени обоих участников.
• Устанавливать SLA, не проверив реальную загрузку команды — нереалистичный SLA хуже его отсутствия.
• Ревьювить в последний момент перед релизом — комментарии либо игнорируются под давлением, либо задерживают выпуск.
• Не давать позитивный фидбэк в ревью — «только критика» формирует страх открывать PR.
• Думать, что гайдлайн работает сам по себе — нужно периодически ревьювить его актуальность.

• Свести культуру review к вкусовщине по стилю кода.
• Ввести checklist, который никто не использует.
• Не измерить, стало ли лучше.

• Видит code review как систему качества.
• Умеет менять командные привычки.
• Снижает конфликтность технической обратной связи.