Привет! Меня зовут Илья, последние 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 документа и сделали ставку на доверие. По ощущениям, кодовая база несколько потеряла в качестве, но конфликтных ситуаций стало значительно меньше, а атмосфера в коллективе улучшилась. Т.е. одной из ключевых целей в нашей команде является поддержка мотивации среди коллег и мы выбрали такой компромисс.
Вместо завершения
Код-ревью — это не просто процесс проверки кода, а форма взаимодействия между людьми. В его основе — диалог, в котором важно не только давать фидбек, но и уметь поддерживать, направлять и слушать. Токсичность, чувство превосходства и нетерпимость могут превратить код-ревью в поле боя, что, в итоге, непременно скажется на продуктивности всей команды, даже если каждый участник сам по себе силён.
Комментарии (16)
NN1
01.06.2025 08:48Если есть чёткие сформулированные правила то просто нужно автоматизировать благо решений предостаточно.
Iluha05 Автор
01.06.2025 08:48Да, мы активно пользуемся кастомными плагинами к eslint+prettier и часть правил автоматизировали. Но далеко не все легко ложится на автоматизацию, порой правило может быть слишком сложным и организация его в плагин становится отдельной нетривиальной задачей (с необходимостью последующей поддержки).
На самом деле, когда мы обсуждали отказ от нашего code style документа, то одна из идей звучала так: "то что не получается легко завернуть в eslint, не должно обсуждаться на код-ревью". Я не совсем согласен с таким подходом, но фактически, отчасти эта идея победила в нашей команде.NN1
01.06.2025 08:48Сегодня можно с помощью моделей улучшить код ревью. Это покрывает дополнительный спектр правил.
Metotron0
01.06.2025 08:48Я тоже 7 лет занят одним только фронтендом, но ни разу не проходил код-ревью. Понятия не имею, хороший у меня код или нет. На одной работе никому не было большого дела и лишнего времени, а на нынешней работе лишь я один делаю свой фронтенд, а времени у людей сверху ещё меньше.
У нас есть другой фронтендер, но у него совершенно не пересекающиеся со мной задачи, я даже не представляю, что он умеет и как. Бывает, что делает вёрстку фрилансер, и мне не нравится его тяга к оборачиванию всего в несколько обёрток, даже картинок, которые нужно просто вывести и всё.
Хотелось бы поработать где-то, где можно посмотреть на это самое код-ревью, узнать, какое оно, чтобы кто-то посмотрел в мой код. А то, я у кого спрашиваю, все говорят, что у меня всё хорошо, один человек даже сказал, что у меня лучшая вёрстка, которую он встречал, но я же не знаю, как много он видел, и кто это был. Может, из вежливости так говорят. Может, я безнадёжно отстал от реалий. Как-то в ~2009-2010 году был маленький конкурс вёрстки, я поучаствовал и сверстал предложенный элемент таблицами. Судьи похвалили за олдскульность и поддержку старых браузеров. Тогда я понял, что пора уже изучить блочную вёрстку и флоаты.
Есть какие-то сервисы, где могут по фану провести ревью чего-нибудь небольшого ради идеи, чтобы сообщество росло профессионально? Примерно как я отсылаю сообщения об ошибках авторам статей, которые читаю.
Bratken
01.06.2025 08:48Я QA, но накину пару мыслей.
Можно пробовать опенсорсные решения, которых немало на гитхабе.
Что до "ни разу не проходил код-ревью", то это как минимум надо попасть в команду. Желательно в команду с тим-лидом. И там с какой-то вероятностью будут код-ревью. Особенно, если в компании несколько продуктов и есть устовяшиеся шаблоны/подходы и лучше всего их знает какой-нибудь тим-лид, через которого требования и прочее проходят. Без ревью код просто не вольют в общую ветку. Ни руками, ни тем более автоматизированно.
Ну и код-ревью могут быть полезными там, где нет выделенного разработчика под ту или иную часть и происходит "ротация", когда есть команда из 8 фронтендеров на 5 проектов. И эти 8 фронтендеров по очереди в каждом проекте что-то пилят по мере свободного времени и приоритетов задач. Тут просто люди не успевают запомнить особенности проекта и кодят по факту, не всегда зная контекст.
Для большего хардкора и с целью оставаться востребованным человеком советую начать копать в девопсы и бэкенд, потому что за бугром "чисто фронт" уже мало кто делает и с людей просят смежные штуки. В РФ подобные истории тянутся дольше и с запозданием, поэтому время еще есть. Собственно, именно это момент у многих стреляет: и у меня, как тестировщика, и у бэкенд-разработчиков (включая "системных", кто пишет на каком-нибудь С++) - там люди и в SQL долбятся включая знания именно подкапотной части движка, и интеграционные тесты на другом языке пишут. Либо за тебя это будет делать тимлид, но этот лид не всегда будет с тобой, поэтому есть смысл вкладывать в свою автономность.
Metotron0
01.06.2025 08:48Когда-то я чуть-чуть сисадминил, потом лет 5 писал сайтики на PHP без фреймворков, сейчас понемногу читаю учебники по Go, но когда вижу статьи на хабре, то понимаю, что мне нужно прочитать ещё штук 10 книг, да ещё отличающихся, а они во многом повторяют друг друга, поэтому сперва ещё нужно найти толковые. Сложно это всё.
К тому же, у меня неприязнь к пробелам в качестве отступов, Go я выбирал во многом потому, что там в стандарте идут табы.
Не знаю, попаду ли я на работу в команду. Может, мои знания годятся только для таких работ, какие уже есть сейчас. Посмотрим, как сложится.
VitalyZaborov
01.06.2025 08:48Последние лет 7 моя работа состоит в основном из одних код-ревью, правда, не во фронтенде. Постараюсь обнадёжить: если Вы работаете самостоятельно, не копипастите, можете понять свой код спустя год, у Вас нет желаения переписать всё с нуля, ваш код не нуждается в рефакторинге спустя месяц после написания, а каждая новая фича не ломает архитектуру - скорее всего, Вы пишете хороший код и даже можете менторить других на тему как писать так, чтобы потом не переписывать.
В командной работе действительно есть особенности, касающиеся явности взаимосвязей и даже когнитивной нагрузки, но ознакомиться с ними гораздо проще, чем научиться писать надёжные и в то же время гибкие решения.
Metotron0
01.06.2025 08:48Я постепенно придумываю новые подходы, поэтому всегда хочется переписать то, что раньше делал :) Например, придумал, как обернуть запросы к API, чтобы сообщения о возможных ошибках в ответах выводились бы без необходимости писать для них if (answer.error) в каждом запросе. Теперь переписываю на этот подход ранние компоненты.
Iluha05 Автор
01.06.2025 08:48Код-ревью обычно организовываются в проектах побольше, где в 1-2 человека не справиться. Как уже отмечал в статье, это мощный инструмент для обмена опытом, причем неважно кто кому пишет комментарии к коду - опытный-молодому или наоборот. Коллега может легко предложить в конктретном сниппете заиспользовать какую-то недавно добавленную в язык фичу, о которой другие еще не успели почитать, дать отсылку на какие-то статьи с best practises или просто предложить более свежий взгляд на оформление кода. Мне очень нравится когда мы подтягиваем друг друга в таком ключе.
По поводу где и как можно попрактиковаться. Как уже здесь упомянали, можно попробовать вписаться в какой-нибудь open-source проект на гитхабе, например в библиотеку, которую сам используешь в повседневной жизни.
Или, для начала, можно просто поизучать существующие PR-ы. Просто заходи на интересующие тебя проекты в раздел pull-request-ов, как например, вот такой (первое что попалось под руку):
https://github.com/lodash/lodash/pull/5855
OlegZH
01.06.2025 08:48А можно на какой-то миг стать на место человека, который проводит этот самый код-ревью? Есть какой-нибудь безопасный пример, чтобы испытать себя? (Даже, если я не знаю стека технологий.)
Iluha05 Автор
01.06.2025 08:48Самое простое - на своем проекте договориться с кем-нибудь из коллег поревьюить друг друга, даже если этот процесс не интегрирован в компании.
Если речь о пет-проекте, то можно попросить кого-нибудь из знакомых-разработчиков помочь с этим.
VitalyZaborov
Вот это странная ситуация. Человек приходит на проект, где уже есть устоявшиеся правила, которые действительно соблюдаются командой. Он начинает их саботировать. Не проще ли уволить саботажника, чем жертвовать качеством кодовой базы ради его комфорта? На дистанции такое решение может довольно негативно сказаться.
vadimr
Чтобы уволить сотрудника, своим трудом производящего реальный коммерческий продукт, исключительно на том основании, что он не выполняет какие-то самодеятельные правила, разработанные его коллегами, нужна большая отмороженность со стороны руководства.
Заметьте, что "качество кодовой базы" сторонами конфликта, скорее всего, оценивается по-разному.
Если нет официально утверждённого стандарта предприятия, госта или закона, сотрудник в принципе имеет полное право послать такие правила. А у небольшого самостоятельного коллектива, разумеется, не будет стандартов предприятия.
В общем, вопрос, затронутый автором, касается стандартов качества разработки, и в конечном итоге неизбежно ведёт в бумажную бездну бюрократии, с какой стороны и с какими намерениями ни начинай путь. Ну, разве что может раньше наступить увольнение или ликвидация бизнеса.
clint_eastwood
это все бла бла бла.
посмотрите курс Егора Бугаенко который приводит все эти проблемы и как их решать.
как пример есть статистические анализаторы кода которые можно и нужно вводить в систему коммитов.
правила на бумажке... видел сам такое не раз конечно. это вме говорит о профнепригодности лида или всей команды
vadimr
С уважением отношусь к Егору Бугаенко, хотя и не разделяю его идей, но он мне не начальник, и автору поста, думаю, тоже.
Допустим, вы считаете, что нужно вводить в систему коммитов статистические анализаторы кода. А какой-нибудь разработчик считает, что ему это нафиг не нужно. И вообще он пишет на ассемблере и из средств организации логики программы признаёт только команду JMP. Но он единственный, кто знает, как в точности работает ядерный реактор, прошивку для которого он пишет. Поэтому в случае конфликта скорее уволят вас, а не его. (Фигура тут нарисована вымышленная, но одного дедушку примерно такого калибра я знал лично).
Я уж не говорю о том случае, если этот человек – знакомый дальнего родственника жены собственника фирмы.
Вообще это требование стандарта управления качеством ISO 9001. И если вы будете работать в энтерпрайзе, вас будут дрючить именно за это.
На мой взгляд, лучше двух IBMеров – Брукса и Фокса – про эти вещи до сих пор никто не написал.
Iluha05 Автор
Ситуация и правда довольно неприятная. Но к сожалению, увольнение - слишком радикальная мера. Пришедшие коллеги в целом - довольно сильные разработчики по хард скиллам, показывают высокую производительность и полезность в проекте. Саботировать начали только некоторые правила и далеко не сразу, без шума. Если ревьюер отмечал на код-ревью такие места, то они исправлялись, но в следующий раз те же самые правила могли опять игнорироваться (тем более что ревьюером мог выступать второй "новичок") - предположу что старые привычки брали свое. Выход на откровенный разговор плавно перерастал в конфликт, т.к. роли лида у нас в команде нет и с новчиками, по сути, приходилось договариваться заново на общих правах. Так у нас заведено.
Думаю при вертикальной структуре команды этот вопрос можно было бы решить иначе, но мы нашли выход и в целом нас всех устраивает такой "демократичный" подход.