Привет, Habr! Меня зовут Михаил Тетерин, я разработчик в Lenta tech, и сегодня расскажу, как мы упростили и ускорили процесс code review с помощью собственного инструмента — «ревью-рулетки». Это решение появилось из повседневной боли, когда merge requests зависают, разработчики неохотно разбирают задачи на ревью, а в чатах идет бесконечное «посмотри мой MR, пожалуйста».

Зачем вообще нужен code review

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

А в зрелой команде, где все понимают контекст и пишут код на одном уровне, главное — это качество. Ревью помогает находить более оптимальные решения, обнаруживать баги до того, как они попадут в прод, и облегчает поддержку проекта. Хорошо оформленный merge request сокращает путь фичи до продакшена.

Почему ревью тормозит, и как мы это исправили

Когда я только пришёл в команду, ревью организовывали так: разработчик создавал MR и делился ссылкой в чат. Потом ждали, пока кто-нибудь из коллег согласится посмотреть. В команде была договоренность о том, что каждый MR должны посмотреть два человека. Иногда выходило так, что и три человека ревьюили из-за мискоммуникации. Даже когда MR получал нужное количество апрувов, его могли забыть смержить. Зачастую комментарии оставались без ответа на протяжении нескольких дней — ревью растягивалось на дни или недели.

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

Как работает «ревью-рулетка»

Всё изменилось, когда мы написали собственного бота, назвали его «ревью-рулетка», и он стал незаменимым участником команды.

Когда разработчик создает merge request в GitLab, бот ловит webhook, автоматически выбирает ревьюеров из заранее настроенного пула и отправляет в чат сообщение с названием MR, ссылкой и списком назначенных ревьюеров. Всё это происходит за секунды — и никому больше не нужно договариваться вручную.

Если кто-то не успел вовремя посмотреть MR, бот напоминает об этом утром в личных сообщениях. Он учитывает выходные и отпуска, не тревожит зря и точно знает, кому и когда нужно написать. После того как все ревьюеры апрувят MR, в чат прилетает зеленая галочка — значит, можно мержить. Тимлиды тоже получают уведомления и могут видеть всю активность без необходимости вручную проверять репозитории.

Сегодня «ревью-рулетку» используют 10 команд, в которых суммарно около 100 человек. Мы смогли масштабировать единый процесс и получить стабильные результаты на уровне всей организации.

«Ревью-рулетка» решает сразу несколько проблем:

• устраняет “человеческий фактор” при назначении ревьюеров;

• сокращает “висячие” merge requests;

• экономит нервы тимлиду (он видит всё в одной системе);

• создает единый, предсказуемый процесс.

А главное — теперь ревью не тормозит, а помогает ускорить разработку.

Почему это сработало

Автоматизация сняла с команды необходимость распределять задачи по ревью вручную, исключила забывчивость и снизила когнитивную нагрузку. Ревью стало предсказуемым, процесс — прозрачным, а нагрузка на тимлида снизилась. Самое главное, мы перестали терять задачи на стадии ревью и ускорили цикл поставки.

Технически бот устроен вот так:

• GitLab, Jira и Mattermost связаны через API и webhook-и;

• распределение ревьюеров происходит случайным образом, но с учётом весов — чтобы не перегружать одних и тех же людей;

• админка позволяет гибко настраивать команды, ветки, ревью-группы, учитывать отпуска, редактировать правила;

• есть визуальные треды в чатах, напоминания по статусам и гибкая система фильтрации событий.

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

Что мы ещё добавили

Внедрили стандарт Conventional Comments — это способ давать конструктивную и структурированную обратную связь. Комментарии маркируются как:

• nitpick — мелкая правка;

• suggestion — предложение;

• praise — похвала.

Дополнительно используются два декоратора:

• blocking — ошибка, блокирующая merge;

• if-minor — исправить, если несложно.

Такой подход снижает недопонимание между автором и ревьюером и помогает быстрее двигаться к итоговому апруву.

Два главных преимущества «ревью-рулетки»

1. Сокращение времени на ревью: автоматическое назначение, напоминания, прозрачность статусов — ускоряют процесс прохождения MR.

2. Повышение вовлеченности команды: ревью стало не обязанностью, а частью рабочего процесса. Люди начали активнее участвовать в ревью, потому что теперь это удобно и честно распределено.

Что дальше?

Сегодня «ревью-рулетку» используют несколько команд в Lenta tech. Мы собираем фидбэк, дорабатываем функциональность и… планируем выложить её в open source.

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

А как вы организовали процесс code-review у себя в команде? Что работает, а что нет?