Сообщить об ошибкеКороткий ответ
Нужно спокойно объяснить свою точку зрения с аргументами или примером в коде, а не молча соглашаться или игнорировать комментарий — цель ревью — найти лучшее решение, а не «победить» в споре.
Как это работает подробнее
Комментарий ревьюера — это гипотеза о возможной проблеме, а не окончательный вердикт. Автор PR может либо согласиться и исправить код, либо объяснить, почему текущий подход оправдан (например, привести ограничение производительности или ссылку на соглашение команды), после чего ревьюер либо соглашается, либо приводит контраргумент. Такой обмен аргументами и есть основная ценность ревью, а не сам факт наличия комментариев.
Пример кода
example.txt
Комментарий ревьюера: "Зачем здесь try/except Exception — так можно скрыть баг."
Ответ автора: "Согласен, что Exception слишком широкий. Сузил до
requests.Timeout и ConnectionError, остальные исключения теперь падают явно —
так в логах будет видно реальную причину сбоя."
Ревьюер одобряет PR после правки.Что использовать на практике
- Практика. Полезно отвечать прямо в ветке комментария к конкретной строке кода, а не в общем чате — так сохраняется контекст обсуждения для будущих читателей истории PR. Если обсуждение затягивается или становится эмоциональным, разумно перенести его в короткий звонок, а решение и его причину потом зафиксировать письменно в PR, чтобы следующий человек, читающий код, понимал, почему выбран именно такой вариант.
Подводные камни
- Риски. Ошибка — воспринимать замечание как атаку на себя и защищаться вместо обсуждения сути. Другая крайность — соглашаться со всем без разбора, лишь бы быстрее смержить PR: так в кодовую базу попадают случайные компромиссы, которые потом сложно объяснить. Также стоит избегать затяжных споров прямо в комментариях без привлечения третьей стороны (тимлида), если за несколько раундов согласие не достигнуто.