Как код-ревью улучшает командную работу

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

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

Как отвечать

Назовите три-четыре эффекта и к каждому приложите свой случай:

• распределение знаний: код модуля видели минимум двое, поэтому отпуск или уход одного человека не останавливает работу. Хорошо, если можете рассказать, как через ревью вошли в чужой сервис;
• общие правила: ревью закрепляет договорённости по стилю, обработке исключений, работе с транзакциями. Для Java это вопросы вроде «почему @Transactional на приватном методе не сработает» или «зачем Optional в поле»;
• онбординг: новичок быстрее понимает, как принято в проекте, когда получает конкретные комментарии, а не только читает вики;
• ранний поиск ошибок: дешевле найти N+1 в JPA-запросе или гонку в HashMap на ревью, чем в инциденте.

Затем покажите, что знаете, как сделать ревью полезным, а не тормозящим. Всё механическое уходит в CI: форматирование через Spotless или google-java-format, статический анализ через SpotBugs, Error Prone или SonarQube. Тогда люди обсуждают дизайн, а не пробелы. Небольшие пул-реквесты читают внимательно, огромные пролистывают. Договорённость о сроке ответа снимает ожидание на сутки. Пометки вроде nit: отделяют мелочи от блокирующих замечаний.

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

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

Отвечают набором общих слов про «культуру и качество». Без одного живого примера это звучит как пересказ статьи.

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

Описывают ревью как поиск виноватого. Фраза «я всегда нахожу у джунов кучу ошибок» настораживает интервьюера сильнее, чем отсутствие опыта.