Представьте себе: вы закончили большую задачу, написали много строк кода, всё проверили, даже подумали над названием каждой переменной! Но откладываете создание PR на день, два, три…из-за того, что не хочется идти в ревью и получать критику?

А мне такое и представлять не надо. Я испытываю подобное почти перед каждый своим ревью, даже спустя 6 лет в разработке.

Вообще, code review — это, конечно, чисто технический процесс: команда проверяет код, ищет ошибки, и вы вместе обсуждаете решения. Но это только половина правды. Наша работа давно перестала быть просто технической: там, где есть люди, всегда кроется ещё один слой - психологический. 

С самого начала своей карьеры в IT я замечала, что для меня ТОН комментария порой важнее самого комментария. И тут ни в коем случае не веду речь про вежливость и лишние дифирамбы. Речь, как всегда, про эффективность.

Как выглядит стандартное ревью

Все мы знаем, как выглядит типичное ревью. Это комментарии типа: 

  • Исправь это

  • Переименуй переменную

  • Добавь проверку

Это самый быстрый тип комментария: они короткие и по делу. Но почему-то редко говорят об эффекте, который такие комментарии производят на автора кода. Когда мне приходится получать такое на ревью, моя первая реакция — это защитить своё решение и доказать, что «я не дурак». 

Почти всегда обсуждение после таких комментариев идет по одному сценарию:  

Человек объясняет, почему он сделал именно так —> ревьюер отвечает, что подход всё равно неправильный —> начинается длинный тред с аргументами.

Я начинаю чувствовать, что мою работу оценивают и я нахожусь на мини-экзамене, поэтому вполне естественно переключаюсь с самой задачи на необходимость объяснить и защитить свой выбор решения. Правда, мне по началу казалось, что это лишь чувства «маленькой девочки в мире серьезных инженеров».

Долгое время я держала эти мысли в себе, но, обсудив однажды эту тему со своим мужем, закоренелым mobile-developer, оказалось, что он разделяет мой взгляд (и не потому, что он мой муж и ему приходится со мной во всём соглашаться).

На мой взгляд, выбор тона для комментария может определить, в каком направлении пойдёт диалог:

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

Или же когда разговор крутится вокруг позиции автора:

  • почему я сделал именно так,

  • почему это решение тоже нормальное,

  • почему комментарий не совсем справедлив.

И я думаю, не нужно объяснять, что во втором случае очень легко может возникнуть спор, который займет много времени, но по итогу ни к чему не приведёт.

Чтобы не быть голословной и дать какую-то опору своим словам, я попросила ChatGPT поискать в архивах психологии исследования на эту тему. И, как ни странно, он нашёл вполне интересные штуки.

Почему так происходит?

Защитная реакция

В психологии есть понятие defensive response — защитная реакция на оценку. Когда мы чувствуем, что наши действия оценивают, мозг переключается из режима решения задачи в режим защиты своей компетентности. Исследования показывают, что форма обратной связи сильно влияет на то, как люди её воспринимают. Например, в работе Harvard Business Review указано, что жесткая формулировка критики повышает вероятность защитной реакции и снижает готовность людей принимать новые идеи. 

А если перенести это в наш мир разработки, то это выглядит примерно так:

комментарий → объяснение → спор → длинный тред.

Code review как источник микростресса

Code review происходит постоянно, это ежедневная часть работы большинства разработчиков. И если каждое ревью сопровождается небольшим напряжением, то оно постепенно накапливается. В психологии это называют micro-stressors: небольшие, но регулярные стрессовые события. Со временем именно они сильнее всего влияют не только на выгорание, но и на здоровье, потому что суммарное действие микрострессов ничем не уступает «большому стрессу».

Исследования показывают, что токсичные комментарии в code review могут демотивировать разработчиков и ухудшать сотрудничество в проектах. Например, в исследовании Automated Identification of Toxic Code Reviews Using ToxiCR отмечается, что такие комментарии могут восприниматься как личная атака и мешать дальнейшей совместной работе.

Психологическая безопасность

А еще одно из самых известных исследований на эту тему провели ребята из Google. В исследовании Project Aristotle компания пыталась понять, почему одни команды работают лучше других. Главный фактор эффективности оказался не связан напрямую со стеком технологий или опытом разработчиков. Им оказалась психологическая безопасность. Когда люди чувствуют, что могут спокойно обсуждать идеи и ошибки, команда работает заметно эффективнее. 

А code review это как раз то место, где чаще всего происходит публичная оценка решений разработчиков. И именно там формируется ощущение безопасности или его отсутствие.

Маленькая разница в формулировке

И если информация выше вызвала в вас отклик, то давайте на маленьком примере разберем, что было бы приятнее прочитать к своей работе:

Исправь это

или

Давай исправим это, так будет проще читать

Согласна, что смысл одинаковый, но, как ни крути, второй комментарий звучит, как совместное действие, от него меньше стресса и защитная реакция может быть даже и не возникнет. Как считаете?

Вообще, мы с ChatGPT нашли ещё одно исследование, в котором говорится, что нейтральный и объясняющий тон уменьшает вероятность эскалации дискуссии. Да, может быть выборка не такая большая (22 разработчика), но достаточная, чтобы убедиться, что даже небольшое изменение (вроде добавления слова «Давай») может заметно снизить вероятность конфликта в обсуждениях.

Окей, я рассмотрела некоторые исследования, у меня есть теория, но что же делать на практике, чтобы ревью были не таким болезненными? А может быть, чтобы даже стать крутым ревьюером?

Инструменты для улучшения ревью

Мы давно используем инструменты, которые упрощают процесс ревью и делают его удобнее:

  • использование различных маркировок комментариев, например, nit,

  • suggestion,

  • линтеры,

  • форматтеры

Они помогают структурировать комментарии и автоматизировать часть проверок. Но, хорошее ревью — это больше, чем просто анализ кода и выявление ошибок. Это ещё и способ донести свою мысль так, чтобы её захотели услышать.

Техническая правота сама по себе не всегда приводит к согласию. Люди легче принимают идею, когда понимают её контекст и не чувствуют давления. И вот здесь я хочу вернуться к той вещи, которая почти не обсуждается как часть процесса — тон общения. 

Хотя он напрямую влияет на комфорт разработчиков, скорость принятия решений, количество споров, иногда одно слово в комментарии может изменить всю динамику обсуждения. 

Расскажу о своих подходах, к написанию комментариев, которые мы внедрили, когда нам захотелось повысить культуру общения в команде и повысить ее эффективность.

№1. Предлагать альтернативу

Здесь всё просто: критикуешь — предлагай. 

Вместо:

Мне не нравится этот нейминг

Я пишу:

Может назвать переменную userProfile?

Пример, как я это делаю:

Этим ты, во первых, я снижаю когнитивную нагрузку для автора PR. Ему не нужно догадываться, о чём именно я думала в этот момент. 

А во вторых, так я сразу превращаю ревью в обсуждение. Вполне естественно, что ревьюер может не знать всей глубины задачи, но предложенный вариант поможет начать разговор.

№2. Не использовать приказной тон

Мы не на заводе, где приказы отдает высшее начальство. У нас командная работа и во всем требуется совместное действие.

Зачем писать:

  • Исправь это

  • Переименуй это  

  • Перепиши это

Если можно добавить буквально пару слов и написать это:

  • Давай исправим Х

  • Лучше переименуй Y

  • Попробуй переписать Z

Пример, как я это делаю:

Я формулирую комментарии, как призыв к совместной работе.

№3. Искать спасения в вопросах

Часто можно увидеть категоричные комментарии, по типу:

Такой подход неверный, переделать

Но что, если попробовать понять логику автора и задать вопрос иначе?

Почему ты выбрал именно такой вариант?  

Что сейчас решает твой подход к задаче?

Пример, как я это делаю:

Такая формулировка помогает сначала понять мысли автора, а потом обсудить решение. И если есть возможность, предложить свой вариант.

Это всё довольно мелкие изменения, которые не требуют лишнего времени, но они значительно повысят качество ревью, а также улучшат взаимодействие в команде.

№4. Главное — не бояться давать обратную связь на ревью

Есть ещё один момент, который редко обсуждается, но о котором я хочу сказать отдельно.  В командах принято давать обратную связь на код, на задачи, на работу разработчиков.

Но почти никогда не дают обратную связь на само ревью.

Хотя это такой же рабочий инструмент. Если комментарий звучит резко или не помогает понять мысль, нормально сказать об этом.

Иногда человек просто не замечает, как звучит его стиль ревью. В большинстве случаев это не намеренная грубость, а всего лишь привычка. Но обсуждение таких вещей внутри команды может заметно улучшить атмосферу работы.

В конце концов

Разработка уже давно стала коллективной деятельностью. Мы постоянно обсуждаем архитектуру, решения, pull request и баги. Коммуникация такой же инструмент инженера, как тесты, архитектура или хороший нейминг. 

И иногда для улучшения процесса достаточно изменить одну маленькую привычку. Иногда достаточно добавить в комментарий только одно слово «Давай».

А как вы проводите код ревью? Какие комментарии пишите?