Как работает код ревью в команде

Что проверяют

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

Как отвечать

• Опишите процесс по шагам: небольшой PR (ориентир до 400 строк), описание с контекстом и способом проверки, зелёный CI до запроса ревью, самопросмотр диффа автором, один или два ревьюера, из которых хотя бы один знает эту часть кода.
• Договоритесь про скорость: первая реакция в течение рабочего дня. Висящий PR тормозит всю очередь и провоцирует ветки-переростки.
• Разделяйте типы комментариев явно: блокирующее замечание, вопрос, nit как необязательное. Без этого автор считает блокирующим всё подряд, а ревьюер удивляется, почему правка не сделана.
• Стиль и форматирование отдайте линтеру и форматтеру в CI, чтобы обсуждать логику: корректность и граничные случаи, наличие тестов на новое поведение, обратную совместимость API и миграций, безопасность, читаемость имён и границы модуля.
• Комментарий адресуется коду и содержит причину и вариант: не «плохо», а «после сетевой ошибки здесь возможен null, стоит вернуть Result и обработать выше».
• Разногласие, не решённое за два раунда, выносится в разговор голосом или к третьему человеку, а решение фиксируется в PR, чтобы через полгода его не переоткрывали.
• Про личный опыт говорите фактами: размер команды, кто ревьюер, сколько PR в неделю, что автоматизировано, обязателен ли approve перед merge. Один случай, где ревью поймал ошибку, и что после него изменили в процессе, убеждает сильнее общих слов.

Где спотыкаются

Сводят ревью к поиску ошибок и забывают вторую цель: распространение знания о коде, чтобы модуль не остался на одном человеке.

Приносят гигантские PR и удивляются формальным апрувам. На тысяче строк внимательность ревьюера падает до нуля.

Не могут описать себя в роли автора: как принимают замечания, что делают с теми, которые решили не исправлять. Такие замечания надо проговорить явно, а не закрыть молча.