Привет! Меня зовут Илья, последние 7 лет я занимаюсь фронтендом и наконец решил отметиться на Хабре. Стартую с темы, которая, как кажется, уже успела приесться, но всё ещё вызывает жаркие споры — код ревью (CR). Не смотря на сотни статей и мануалов, каждая команда подходит к этому процессу по-своему. Хочется зафиксировать и осмыслить собственный опыт, показать, как мы подходили к настройке процесса в реальном проекте, и почему, на мой взгляд, код-ревью не может быть универсальным, а должен опираться на контекст команды.

В этой статье не будет технических деталей вроде рекомендаций по максимальному количеству строчек в diff-е или формату названий коммитов. Я хочу подняться на уровень выше и поговорить о целях, ключевых факторах и реальных компромиссах которые встречаются в CR.

Цели код-ревью

Для чего мы вообще делаем код-ревью? Давайте представим, команда собрана и горит желанием включиться в работу над новым долгосрочным проектом или на поддержку уже существующего. Вопрос об организации CR встанет довольно быстро и звучать он будет примерно так: зачем код-ревью нужен конкретно вашей команде? Ответ далеко не всегда очевиден. У каждой команды имеются свои цели, и они зависят от множества факторов. Уже здесь могут начаться разногласия, связанные с опытом отдельных разработчиков на прошлых проектах. 

Цели, которые вы преследуете, могут отличаться в зависимости от следующих составляющих:

  • иерархия команды (есть ли у вас "вождь" или коллективное сознание?)

  • размер команды (два разработчика могут просто покивать друг другу)

  • структура подразделения (в команде 3 человека или 3 отдела?)

  • Общие практики в компании (есть ли культура ревью в целом?)

  • Сроки проекта (релиз назначен на завтра?)

Информация по этим вводным может формировать и изменять (временно или постоянно) ваши цели.

Пример №1

Допустим, у вас есть тимлид, который внедряет процесс "сверху". Такое часто встречается, особенно когда в команде есть выраженная разница в опыте - присутствуют как джуниор-разработчики, так и синьоры.

В таких случаях целями код ревью могут быть:

  • контроль качества (соответствие гайдам и архитектурным принципам)

  • обучение младших разработчиков через ревью

  • оценка компетенций и производительности, например как часть performance review 

Пример №2. (как в моем случае)

Более демократичная и "плоская" структура команды. Нет явно выделенной роли тим лида или PM-а. Разработчики примерно равны по уровню, имеют одинаковый вес и изначально владеют довольно высоким уровнем компетенций. Вопросы решаются через обсуждение и рефлексию, упор делается на софт-скиллы.

Что важно для нас:

  • обмен знаниями и подходами

  • распространение экспертизы по кодовой базе 

  • поддержка доверительной продуктивной атмосферы

Конечно хочется затрачивать на CR минимальное необходимое количество времени и с наибольшим профитом для команды.

Влияющие факторы

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

Размер команды сильно влияет на необходимость формализации код-ревью. Здесь тоже все выглядит очевидным. Когда разработчиков двое, всё решается быстро - можно обсудить правки устно, договориться на ходу, и притирка происходит почти автоматически.  Но если в команде 7–10 человек, без чётких правил CR не обойтись. Иначе кодовая база быстро превратиться в нечто неудобоваримое, время доставки фичей по продукту со временем начнет расти, а количество багов увеличиваться. Может быть необходимым явно следить за тем, чтобы разработчики не теряли контекст по различным модулям системы, не происходили bus-факторы на время отпусков/больничных, не разрабатывались дубликаты существующих подсистем, и наконец, чтобы не происходило "каши" из различных подходов к оформлению кода.

Структура подразделения. В добавок к размеру команды, ситуацию с работой над одним и тем же проектом может усугублять существующая структура подразделения в компании. Если проект большой и перспективный, на его развитие может быть брошено сразу несколько команд, время от времени работающих над одними и теми же участками кода. Здесь уже не получится сформулировать цели в рамках только своей небольшой и уютной команды. Кто-то хорошо ориентируется в одном модуле, но почти не знаком с другим. Встает вопрос о том, чтобы делиться этими знаниями (контекстом).

Можно организовать процесс кросс-командного код-ревью с условно случайной ротацией участников. Или же можно разбить разработчиков на сегменты. Например, на ревью приглашается один разработчик "с контекстом" по текущему модулю (для более углубленного CR) и один "без контекста" (для получения экспертизы и взгляда со стороны). 

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

Общие практики в компании

В средних и больших по размеру компаниях нередко существуют единые правила для всех команд: как проводить код‑ревью, на что обращать внимание, какие форматы использовать. Эти регламенты могут быть удобными для масштабирования процессов. Но на практике они не всегда подходят под конкретный проект или команду. Слепое копирование «идеальных» практик, например, заимствованных из FAANG, может обернуться серьезными проблемами, особенно в небольших коллективах. Тюнинг под реалии текущего проекта необходим, иначе могут возникнуть проблемы с мотиваций на фоне внезапно образовавшегося в команде «карго культа» со всеми вытекающими — нежелание тратить много времени на CR со стороны одних разработчиков и слишком дотошный подход со стороны других, затягивание CR или, наоборот, LGTM‑отписки и прочие конфликтные ситуации.

Сроки проекта

Как бы мы не хотели поставлять в продакшен хорошо отдебаженный и качественный код, мы должны делать это в разумные сроки, часто не удовлетворяющие нашим идиллическим потребностям. Приходится идти на компромиссы и срезать косты в том числе и на процессах код‑ревью, которые порой могут серьезно затягивать поставку кода. Типичная ситуация: стартап пилит MVP, нужно как можно быстрее проверить гипотезу на рынке. Команда из 6–7 разработчиков хочет делать всё «по красоте» — обсуждать код, улучшать архитектуру, устраивать многораундовые ревью. Но время поджимает. Один из вариантов — договориться временно снизить требования к процессу код‑ревью, а после релиза заложить время на рефакторинг. Вполне рабочий вариант. В краткосрочный период можно добиться ускорения поставки кода в продакшен, но важно помнить, что на длинной дистанции такой подход может снизить общую производительность по разработке продукта.

История про потерю мотивации

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

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

Сначала нас было двое и никаких строгих формальностей мы не вводили. Комментарии могли касаться любых аспектов практики разработки, обсуждались быстро и без разногласий. Но по мере того как команда расширялась - сначала до трёх, потом до шести человек - стало очевидно: прежний подход уже не работает. Новые разработчики подключались постепенно, и также постепенно усложнялись наши взаимосвязи. 

С приходом третьего коллеги, мы завели code style с набором правил и договорённостей, адаптированных под специфику проекта, что-то вроде такого документа. С приходом 4-го и 5-го коллеги, этот документ начал подвергаться критике, а вносимые в него правки могли прямо противоречить предыдущим редакциям, некоторые правила просто саботировались. Стало понятно, что поддержка такого мануала для нас превращается в боль с увеличением конфликтных ситуаций и c затягиванием CR-ов. 

В итоге мы сделали шаг назад: отказались от обязательного соблюдения code style документа и сделали ставку на доверие. По ощущениям, кодовая база несколько потеряла в качестве, но конфликтных ситуаций стало значительно меньше, а атмосфера в коллективе улучшилась. Т.е. одной из ключевых целей в нашей команде является поддержка мотивации среди коллег и мы выбрали такой компромисс.

Вместо завершения

Код-ревью — это не просто процесс проверки кода, а форма взаимодействия между людьми. В его основе — диалог, в котором важно не только давать фидбек, но и уметь поддерживать, направлять и слушать. Токсичность, чувство превосходства и нетерпимость могут превратить код-ревью в поле боя, что, в итоге, непременно скажется на продуктивности всей команды, даже если каждый участник сам по себе силён.