Как ответить
Идеальный код-ревью — это не формальность и не соревнование, а инструмент для повышения качества кода и обмена знаниями. В хорошем процессе ревью фокусируется на логике, архитектуре и читаемости, а не на стиле или субъективных предпочтениях. Я бы выделил несколько обязательных элементов и того, чего точно стоит избегать.
Что должно быть обязательно:
- Четкий контекст в описании PR: автор пишет, что делает PR, почему выбран такой подход, и какие риски или компромиссы есть. Например: «Добавляет фильтрацию по дате через оконную функцию, потому что JOIN с подзапросом давал 3-секундный latency на 100к строк».
- Фокус на логику и архитектуру: ревьюер проверяет, не ломает ли код существующее поведение, нет ли race condition, утечек памяти или неоптимальных алгоритмов. Пример: «В этом цикле заменил filter + map на reduce — будет быстрее на 20% по данным профилирования».
- Конструктивные комментарии с примерами: вместо «этот код плохой» — «здесь лучше использовать early return, чтобы уменьшить вложенность: if (user.isBlocked) return error;».
- Автоматическая проверка стиля и форматирования: линтеры и форматтеры (ESLint, Prettier, Black) должны отсекать тривиальные замечания. Это экономит время и убирает субъективщину.
- Время на ревью: в идеале — в течение 4-8 часов для небольших PR (до 200 строк) и не более 24 часов для крупных. Если нужно больше — договариваться с автором о разбивке.
Чего быть не должно:
- Субъективных замечаний без обоснования: «я бы написал иначе» или «мне не нравится этот паттерн» — бесполезно. Если есть альтернатива, нужно показать, чем она лучше: производительность, читаемость, тестируемость.
- Микроменеджмента: правки имен переменных или переносов строк, если это не нарушает конвенции команды. Для этого есть форматтеры.
- «Блокирующих» комментариев на пустом месте: если замечание не влияет на корректность или безопасность, его можно пометить как non-blocking или оставить на усмотрение автора.
- Долгих обсуждений в комментариях: если спор затянулся на 5+ сообщений, лучше позвать третьего или перенести в синк-колл. Код-ревью — не форум.
В итоге, идеальный процесс — это когда после ревью и автор, и ревьюер узнали что-то новое, а код стал надежнее и понятнее. И чтобы на это ушло не больше получаса.