Всем привет! Давайте поговарим начистоту. Code Review — это один из тех процессов, который в теории звучит как благо, а на практике часто превращается в адский баттл-арена. Где вместо помощи друг другу мы начинаем соревноваться, у кого глаз острее и кто найдет больше поводов сказать «ну ты и лох».
Знакомо? Если да, то эта статья для вас. Мы не будем тут говорить о формальных правилах и сухих гайдлайнах. Мы поговорим о том, как превратить код ревью из поля брани в инструмент реальной помощи и роста для всей команды.
Суть проблемы: Критика кода vs Критика человека Представьте ситуацию. Вы потратили два дня на фичу. Вложили душу, мозг и десять чашек кофе. Отправляете пул-реквест, а в ответ прилетает: «И кто так пишет?», «Тут же все сломается», «Мне твой код не нравится».
Что вы чувствуете? Желание исправить код? Или желание найти этого человека и показать ему, куда можно засушить его замечания? Чаще всего — второе.
Проблема в том, что мы путаем критику кода с критикой автора. Код — это не его создатель. Это артефакт, результат работы в определенных условиях (дедлайны, усталость, сложные требования). И когда мы говорим «твой код — говно», автор подсознательно слышит «ты — говно».
Наша главная задача — разорвать эту связь.
Меняем парадигму: Мы — одна команда Первое и самое важное — сменить установку. Code Review — это не экзамен, где ревьюер — злой преподаватель, а автор — несчастный студент. Это совместная сессия по улучшению кода.
Вы оба хотите одного и того же: чтобы продукт стал лучше, код стал чище, а багов — меньше. Вы в одной лодке. Ревьюер — не надзиратель, а первая линия защиты. Он помогает автору не отстрелить себе ногу (и не подставить всю команду) до того, как код уйдет в продакшен.
Магия формулировок: Как говорить, чтобы помогали 90% успеха код ревью — это не что ты говоришь, а как. Одна и та же мысль, высказанная по-разному, может прозвучать как укол или как дружеский совет.
Вместо: «Зачем ты использовал тут цикл? Это неоптимально». Попробуй: «Привет! Я посмотрел на этот цикл. Есть мысль: а если использовать метод map? Кажется, так код станет короче и читаемее. Как думаешь?»
Чувствуете разницу? В первом случае — обвинение. Во втором — предложение, приглашение к диалогу. Используйте вопросы: «Как думаешь?», «А что если?», «Может, рассмотрим такой вариант?». Это снимает защитную реакцию.
Вместо: «Этот код полный отстой, переделывай». Попробуй: «Этот участок кода я сходу не понял. Может, мы можем его упростить? Давай подумаем вместе».
Вы не нападаете, вы просите помощи в понимании. Это мощнейший психологический ход.
Искусство задавать вопросы Иногда автор действительно не прав. Но вместо того, чтобы тыкать его носом в ошибку, попробуйте задать наводящий вопрос.
Ситуация: Вы видите костыль. Обычный подход: «Здесь костыль, убери». Правильный подход: «Я вижу, тут довольно сложная логика для обхода проблемы с Х. А как ты смотришь на то, чтобы решить саму проблему Х? Может, есть способ избежать этого условия?»
Такими вопросами вы:
Не даете готовый ответ, а заставляете автора самого додуматься до решения. Это лучший способ обучения.
Показываете, что вы не просто критикуете, а думаете над проблемой вместе с ним.
Хвалите! Это не менее важно Code Review — это не только про поиск косяков. Это еще и про поддержку. Увидели элегантное решение? Красивый рефакторинг? Уместное использование новой фичи языка?
Обязательно напишите об этом!
«Привет! Мне оч понравилось, как ты разнес логику по этим двум классам. Стало гораздо чище!» «Вау, я не знал про такую возможность языка. Спасибо, что показал на практике, теперь и сам буду использовать!»
Положительный фидбек: 1. Повышает настроение и мотивацию автора. 2. Создает здоровую атмосферу в команде. 3. Позволяет закрепить удачные практики. Все видят, «что такое хорошо», и начинают подсознательно стремиться к этому.
Фокус на важном....
Продолжение в VK сообществе ВАЙЛТ
