Как обязательное код-ревью вредит командной работе

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

Инвестиции в CI - однин самых окупаемых видов техдолга, ведь они гарантированно влияют одновременно на time-to-market и на качество продукта. Переписывание с одного фреймворка на другой - это игра в рулетку по сравнению с инвестициями в подключение линтера и улучшением набора автотестов. Автотесты гораздо лучше находят баги чем человек, интерпретирующий код “в голове”.

А чем больше можно проверить автоматизированно, тем меньше комментариев по мелочи будет приходить от ревьюеров. Cпоры о кодстайле на ревью - вообще номер 1 источник токсичности и дедовщины в командах. Обязательно настрой у себя линтер и введи правило в команде, что замечания по стилю кода может давать только он, если ещё не.

Но самый большой вред код-ревью в том, что это узкое горлышко для процесса разработки. Если ты начал вкладываться в CI/CD, рано или поздно ты придёшь к trunk-based-development. Для достижения максимальной производительности по канонам методологии CI/CD, тебе нужно мерджить свой код в девелоп как можно чаще, но минимум раз в день. Для этого твои процессы CI должны быть максимально автоматизированными и быстрыми. Но опять же, люди - не роботы. Они очень разрдражаются, когда их заставляют переключать контекст. Сам представь, если бы я упоролся по TBD и начал просить тебя каждый час поревьюить новый пулл-реквест? Как быстро ты бы меня послал куда подальше?

Ладно, допустим ты безотказно принимаешь запросы на ревью. Скорее всего между запросом и ревью проходило бы больше часа, за который я мог бы подготовить новую пачку изменений в транк. Неудивительно, что сталкиваясь с таким latency от ревью кода, разработчики начинают складывать свои изменения в более крупные пулл-реквесты, которые становится ещё сложнее смотреть. И ревью за час - это ещё самый оптимистичный сценарий! Я знаю команды в которых ревью может занимать до недели.

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

Поэтому в голове возникает шальная мысль “А на что нам практика код-ревью? Сейчас запушу код, Петя придёт в понедельник, свежим взглядом посмотрит”. И открываю пулл-реквест, прекрасно осознавая, что он не готов на 100%, и с радостью перекладываю часть ответственности на ревьюера, ведь меня откровенно задолбала эта задача, а ещё меня ждёт пятничный бокал любимого империал-сауэр-смузи-пастри-эля.

Можно ли как-нибудь бороться с таким поведением? Если бы я был последним звеном перед попаданием кода в транк, такого бы не случилось.

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

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

Причём этот эффект растёт линейно с количеством ревьюеров за счёт размытия ответственности. Особенно чётко это проявляется в сообщениях “Можешь окнуть ревью по-быстрому? Гена уже посмотрел”, появляющихся у тебя в личке перед релизом.

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

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

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

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

Теперь, когда я привёл примеры вреда и пользы код-ревью, ситуация выглядит ужасно. Неужели код-ревью в 2к23 должно умереть, как практика? Нет, конечно. Я считаю, что код-ревью есть место в процессе разработки, просто оно должно перестать быть обязательным элементом этого процесса.

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

Я хочу чтобы каждый разработчик мог заливать небольшие (<100 строк) пулл-реквесты в транк без аппрува. Причём если он трогает только ту фичу, у которой он является владельцем - этот порог был ещё выше, а если он новичок, то порог был бы наоборот ниже.

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

Я не затронул другие решения, таких как парное программирование (которое ещё зовут Continuous Code Review). Какие у тебя есть идеи чтобы уменьшить проблемы код-ревью? Жду ответов в комментариях.