Как давать и принимать фидбек на код-ревью
Практика3 минРедакция Innovialabs
Коротко
Комментируйте код, а не человека, объясняйте причину и помечайте важность замечания; принимая фидбек, отделяйте себя от кода, уточняйте непонятное и выносите затяжные споры в созвон или к общим правилам команды.
Суть в двух абзацах
Код-ревью — это не экзамен, а способ команды вместе держать качество кода и делиться знаниями. Технически грамотный комментарий, написанный резким тоном, работает хуже, чем мягкий: автор защищается, а не думает о решении.
Хороший фидбек конкретный, объясняет причину и показывает, насколько замечание важно. Хорошее принятие фидбека — это любопытство вместо обороны.
Как давать фидбек
Комментируйте код, а не автора. «Ты опять забыл обработать ошибку» звучит как обвинение. «Здесь не обрабатывается ошибка запроса — если API упадет, пользователь увидит пустой экран» описывает проблему и последствие.
Объясняйте «почему». Без причины замечание выглядит как вкусовщина. С причиной — это знание, которое автор применит в следующий раз.
Помечайте важность. Многие команды используют префиксы:
| Префикс | Значение |
|---|---|
| blocker | Нужно исправить до слияния: баг, уязвимость, потеря данных |
| suggestion | Предложение улучшить, на усмотрение автора |
| nit | Мелочь: нейминг, форматирование |
| question | Хочу понять решение, это не требование |
Формулируйте вопросом, когда не уверены. «Что будет, если список пустой?» приглашает к диалогу и часто оказывается полезнее утверждения.
Предлагайте вариант. Вместо «так плохо» — короткий пример, как можно сделать:
// suggestion: можно вынести в константу, чтобы не дублировать значение
const MAX_RETRIES = 3;
Замечайте хорошее. Короткое «отличное решение с кэшем» — это тоже фидбек: он показывает, какие практики стоит повторять.
Не превращайте ревью в навязывание стиля. Все, что может проверить линтер или форматтер, должно проверять оно, а не человек.
Как принимать фидбек
- Отделяйте себя от кода. Замечание к функции — не оценка вас как специалиста.
- Исходите из добрых намерений. Текст теряет интонацию: короткий комментарий чаще говорит о спешке, чем о раздражении.
- Уточняйте, а не защищайтесь. «Можешь пояснить, какой сценарий тебя беспокоит?» продвигает дискуссию, «у меня все работает» — нет.
- Отвечайте на каждый комментарий: исправлено, обсудим, или почему вы оставили как есть.
- Благодарите за найденные проблемы — это поощряет внимательное ревью.
Как разрешать разногласия
- Разделите факты и вкус. Баг, производительность, безопасность — это факты, их можно проверить. Стиль и структура часто вопрос предпочтений.
- Приводите аргументы, а не авторитет: тест, пример, ссылку на документацию.
- Не спорьте бесконечно в комментариях. Если обмен репликами затянулся, перейдите в короткий созвон и потом запишите итог в PR.
- Опирайтесь на договоренности команды: style guide, архитектурные решения, принятые подходы.
- Если договориться не удалось, привлеките третьего человека — тимлида или владельца модуля — и примите его решение.
- Фиксируйте повторяющиеся споры в виде правила, чтобы не обсуждать одно и то же в каждом PR.
Типичные ошибки
- Сарказм и оценочные слова: «очевидно», «просто», «зачем ты так сделал».
- Сотня мелких замечаний без пометки важности — автор не понимает, что критично.
- Ревью, которое блокирует PR на дни без ответа.
- Принятие любых замечаний молча, даже если вы с ними не согласны.