Код-ревью: как давать обратную связь без обид

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

Код-ревью — проверка изменений другим разработчиком перед слиянием. Его цель — улучшить код и распространить знание, а не доказать, кто умнее.

Критикуйте код, а не человека

Ключевой сдвиг: замечание адресовано коду, а не автору. «Ты опять забыл обработать ошибку» — про человека, вызывает защиту. «Здесь не обработан случай пустого ответа — упадёт на null» — про код, обсуждаемо.

Задевает	Работает
«Зачем ты так сделал?»	«Что если сюда придёт пустой список — не упадёт ли len()?»
«Это неправильно»	«Кажется, тут гонка: два запроса могут перезаписать друг друга. Проверим?»
«Перепиши»	«Можно вынести в отдельную функцию — будет проще тестировать. Как считаешь?»

Помечайте важность замечания

Не всё в ревью одинаково критично. Префиксы экономят нервы: автор понимает, что блокирует слияние, а что — пожелание.

[blocker]  баг/уязвимость — без этого не мержим
[important] стоит исправить, но обсуждаемо
[nit]      придирка по стилю, на ваше усмотрение
[question] не замечание, а вопрос на понимание
[praise]   отметить хорошее решение

Пример: [nit] тут можно map вместо цикла, но не критично. Автор сразу видит вес замечания.

Цикл обратной связи на ревью

   автор открыл PR
        |
        v
  ревьюер читает -> пишет комментарии (с префиксами)
        |                       |
        |                       v
        |              автор отвечает / правит
        |                       |
        v                       v
  одобряет (approve)  <-- договорились по спорному
        |
        v
      merge

Как работает под капотом

Любое замечание читается через эмоцию. Человек, чей код критикуют, инстинктивно защищается — это нормальная реакция. Снизить защиту помогают: вопросительная форма («а не упадёт ли тут?»), «мы» вместо «ты» («давай добавим тест»), отделение факта от мнения и обязательная похвала за удачные места. Цель — чтобы автор захотел поправить, а не «отбиться».

Частые ошибки

Только негатив. 20 замечаний и ни одного «хорошо сделано» демотивируют. Отмечайте удачное.
Спор по мелочам. Если расходитесь по [nit], уступите — не стоит блокировать PR из-за пробелов.
Переписывать за автора в комментариях. Подскажите направление, не отбирайте авторство.
Ревью «для галочки». «LGTM» без чтения — это не ревью, а риск.

Итог

Адресуйте замечание коду, а не автору.
Помечайте важность: blocker / important / nit / question / praise.
Вопросительная форма и «мы» снижают защитную реакцию.
Обязательно отмечайте хорошее, не только проблемы.