Зачем вообще ревьюить чужой код
Code review — это не ритуал галочки перед мерджем, а способ сделать код понятнее, надёжнее и дешевле в сопровождении. Заодно это один из немногих формализованных процессов, где разработчики реально учатся друг у друга, а не только из книжек.
Код-ревью — это когда один или несколько разработчиков, кроме автора, просматривают изменения в коде и дают обратную связь: вопросы, замечания, предложения по улучшению. Идеально — до попадания кода в основную ветку или на прод.
И да, сейчас будет не про «ставьте пробелы по гайду» (хотя и это важно), а про то, как ревьюить чужой код так, чтобы пользы было и автору, и ревьюеру, и продукту.
---
Базовые термины простым языком
Что такое code review на практике
Чтобы не путаться, договоримся о терминах:
- Pull Request (PR) / Merge Request (MR) — «пакет изменений», который автор отправляет на проверку.
- Ревьюер — тот, кто смотрит на изменения, придирается и задаёт вопросы.
- Апрув — согласие, что изменения можно влить в основную ветку.
- Blocker / Must-fix — проблема, без исправления которой мержить нельзя.
- Nit / Minor — мелочь, поправить хорошо бы, но не критично.
Сухо, но без этого далеко не уедем: без общего языка все обсуждения превращаются в «я так вижу».
Диаграмма процесса ревью (словами)
Представим «диаграмму» как путь PR:
1. Автор пишет код →
2. Автор создаёт PR →
3. Ревьюер читает изменения →
4. Оставляет комментарии →
5. Автор отвечает / фиксит →
6. Повтор 3–5 до договорённости →
7. Апрув →
8. Мерж.
Если бы это была блок-схема, она выглядела бы так:
- Старт
↓
- "Код готов?" → нет → "Писать код"
↓ да
- "Создать PR"
↓
- "Ревью"
↓
- "Нужны правки?" → да → "Исправить" → обратно на "Ревью"
↓ нет
- "Апрув и мерж"
↓
- Конец.
Скучновато, пока сюда не добавим людей, эмоции и дедлайны.
---
Чего мы хотим от хорошего code review
Три главные цели
В живой команде цели ревью обычно такие:
- Качество: меньше багов, утечек, костылей.
- Понятность: любой разработчик через полгода откроет файл и не проклянёт автора.
- Общее знание: код знают не один-два человека, а команда.
И вот тут вылезает вопрос: *как правильно делать ревью кода*, чтобы не утонуть во взаимных обидах и велосипедах?
---
Культура и стандарты: договориться, прежде чем спорить
Стандарты code review в команде разработчиков
Один из частых источников конфликтов — отсутствие правил. Каждый ревьюит по-своему, авторы каждый раз гадают: сегодня мне поправят архитектуру или пробелы?
Минимальный набор, который стоит зафиксировать:
- Зачем мы делаем ревью (официально, в одном документе).
- Что точно проверяем (архитектура, безопасность, перфоманс, читаемость).
- Что не обсуждаем на ревью (например, форматирование, если это целиком на плечах линтера).
- Сроки ревью: через сколько часов/дней ожидать первый фидбек.
- Кто может аппрувить какие части системы.
Это и есть реальные стандарты code review в команде разработчиков, а не просто «у нас кто свободен — тот и смотрит».
Кейс из практики: конфликт из-за «комментариев ради комментариев»
Команда на проекте (10 человек) стонет: «ревью тормозит всё, контекст обсуждений — хаос». Через пару недель поиска причин выяснилось:
- Один разработчик исправлял каждую мелочь: перенос строки, кавычки, названия переменных «по вкусу».
- Другие ревьюеры смотрели только на бизнес-логику.
- Автор PR не понимал, что из 40 комментариев важно, а что — вкусовщина.
Решение оказалось банальным, но рабочим:
1. Выделили три уровня комментариев:
- `must` — блокер, без исправления не мержим;
- `should` — желательно поправить;
- `nit` — «на будущее» / косметика.
2. Договорились, что:
- к стилю кода придирается только линтер;
- ревьюер не может блокировать мерж, ссылаясь только на личный вкус.
Через месяц скорость ревью выросла, авторы стали меньше защищаться и больше спрашивать «почему так».
---
code review лучшие практики: не быть ботом и не играть в начальника
Не смотреть на код как на экзамен
Ревью — это диалог, а не защита диплома. Как только ревью превращается в оценку человека, а не кода, начинаются пассивные агрессии, «молчаливые апрувы» и внутренние списки «с кем лучше не работать».
Помогает простое правило: критикуем решение, а не личность.
Вместо:
- «Ты опять написал нечитаемую функцию»
лучше:
- «Функция делает три вещи сразу — предлагаю разбить на отдельные шаги, так проще отлаживать».
Смотреть не только на «что сделано», но и «зачем»
Один из самых полезных приёмов — начинать ревью не с кода, а с описания задачи и контекста. Например:
- Какую проблему решаем?
- Есть ли ограничения по перфомансу/безопасности?
- Есть ли уже похожие места в кодовой базе?
Если этого нет в описании PR — спросить. Вежливо и прямо.
Кейс: баг из-за «молча принятого» решения
Компания добавляла кеширование в сервис. Разработчик сделал хранение в памяти, без инвалидирования, потому что «будет быстрее». Ревьюер глянул код, увидел, что всё компилируется, и поставил апрув — спешили к релизу.
Через неделю продажники жалуются: пользователи видят устаревшие данные. Виноват формально автор, но по факту — и ревьюер: он не задал вначале базовый вопрос: «А как здесь обновляется кеш и как долго живут данные?».
Вывод: ревью начинается с проверки идеи решения, а не скобочек.
---
Технические аспекты: на что смотреть глазами инженера
Пять основных «углов обзора» ревьюера
Когда смотришь на PR, полезно проходить его «слоями»:
- Корректность: код делает именно то, что написано в задаче?
- Границы: а что будет, если придут странные данные, упадёт сервис, сеть дернётся?
- Читаемость: через месяц вы сами поймёте, что здесь происходит?
- Сопровождаемость: как легко это протестировать, изменить, расширить?
- Согласованность: это решение похоже на уже существующие в проекте или мы плодим «зоопарк»?
Можно мысленно рисовать такой «слоёный пирог»:
- Слой 1: «Работает ли хоть как-то?»
- Слой 2: «Упадёт ли в реальном мире?»
- Слой 3: «Смогу ли я это поддерживать?»
- Слой 4: «Это вписывается в общую архитектуру?»
И идти сверху вниз, не перескакивая.
Сравнение: ревью «по стилю» vs ревью «по сути»
- Ревью по стилю:
- Быстрое, поверхностное, часто автоматизируемое линтерами и форматтерами.
- Помогает сделать код «ровным» визуально.
- Почти не улучшает архитектуру и надёжность.
- Ревью по сути:
- Медленнее, требует концентрации и понимания домена.
- Находит логические ошибки и архитектурные проблемы.
- Дороже, но приносит максимальную пользу продукту.
Зрелые команды стараются перенести максимум стилистики на «автоботов» (линтер, форматтер, CI), а время людей расходовать на смысл.
---
Инструменты и процесс: как не утонуть в PR’ах
Инструменты для code review GitHub GitLab Bitbucket
Современные платформы сильно влияют на стиль ревью:
- GitHub — удобные обсуждения, draft PR, suggested changes, code owners.
- GitLab — тесная интеграция с CI/CD, можно требовать прохождение пайплайнов до ревью.
- Bitbucket — хорошо заходит тем, у кого много интеграций с Jira и экосистемой Atlassian.
Главное — использовать то, что у инструмента уже есть:
- шаблоны PR (чек-листы, описание задачи, скриншоты);
- обязательные ревьюеры для критичных модулей;
- авто-назначение ревью по code owners.
Как организовать процесс code review в компании
Сами по себе инструменты ничего не решают, если процесс хаотичный. Рабочая схема часто выглядит так:
1. Лимит на размер PR
К примеру, не больше 300–400 строк чистых изменений. Всё, что крупнее — разбивать на логические части.
2. Сроки
Внутри команды договариваются: первый фидбек — в течение, скажем, 4 рабочих часов. Если ревьюер занят — автор может вежливо пинговать или переназначить.
3. Очередь ревью
Некоторые команды ставят правило: «Перед тем как брать новую задачу, посмотри хотя бы один чужой PR».
4. Множественные ревьюеры
Для важных модулей: 2 апрува, и хотя бы один от человека, знакомого с доменом.
Это не бюрократия, а способ не превращать ревью в «кто громче крикнул — того и правда».
Кейс: ускорили релизы, просто поменяв порядок действий
В одной компании разработчики сначала полностью дописывали фичу, а уже потом отдавали огромный PR (по 1000+ строк) на ревью. Ревьюеры откладывали такие «кирпичи» до последнего, баги всплывали перед релизом.
Решение:
- Ввели ограничение: один PR — один небольшой, логически цельный шаг.
- Приучили делать draft PR в начале работы, чтобы обсудить подход.
- Добавили правило: фичу нельзя считать «начатой», пока не создан draft PR с черновым решением и описанием.
Через пару спринтов:
- количество конфликтов по архитектуре уменьшилось;
- ревью стали короче, обсуждения — конкретнее;
- таски перестали улетать в «доделать в следующий спринт».
---
Коммуникация на ревью: как говорить, чтобы друг друга слушали
Тон комментариев: не быть пассивно-агрессивным ботом
Несколько простых приёмов, которые снижают градус:
- Формулировать как наблюдение + вопрос, а не как вердикт.
«Мне кажется, здесь дублируется логика из X. Есть причина не использовать её?» вместо «Ты дублируешь код».
- Показывать альтернативу в коде, а не просто «сделай нормально».
- Разделять «мне так привычнее» и «у нас так принято».
Полезно явно писать, к какому уровню относится комментарий:
- `nit:` «nit: можно переименовать переменную, будет понятнее».
- `suggestion:` «suggestion: вынести вот этот блок в отдельный метод».
- `must:` «must: при текущей логике теряем часть данных, нужно исправить до мержа».
Как защищать своё решение без войны за эго
Автор кода тоже отвечает за тон. Вместо обороны «вы ничего не понимаете» лучше:
- Объяснить контекст, которого у ревьюера может не быть.
- Признать, если решение компромиссное: «Да, это неидеально, но сроки жали. Давайте заведём отдельную задачу на рефакторинг, вот кандидаты на улучшение».
- Попросить помощь в формулировке лучшего варианта, если сомневаетесь.
---
Типичные ошибки на ревью и как их избегать
Ошибка 1: «Я просто пролистал, там всё нормально»
Быстрый апрув без реального просмотра — один из худших вариантов. Он создаёт иллюзию контроля, но не приносит пользы.
Лучше честно сказать: «Сорри, сейчас нет времени посмотреть как следует» и не ставить апрув, чем давать ложное ощущение проверки.
Ошибка 2: превращать ревью в микроменеджмент
Когда ревьюер навязывает каждую мелочь, это убивает мотивацию.
Помогает простой фильтр: «То, что я предлагаю, существенно влияет на читаемость, надёжность или архитектуру?»
Если нет — это кандидат на `nit` или вообще на молчание, особенно если линтер уже всё поправит.
Ошибка 3: огромные PR без описания
Легендарный «вот тут 2k строк изменений, но там ничего сложного».
Живой подход:
- Чёткий заголовок: что именно делает PR.
- 2–5 пунктов в описании: какие изменения внутри.
- Если есть спорные решения — отдельный абзац: «Вот здесь я выбрал такой подход, потому что…».
---
Обучение через code review: как расти обеим сторонам
Ревью как инструмент менторства
Для джунов и мидлов ревью — лучший источник прикладных знаний «как принято у нас». Но чтобы это работало, нужно:
- объяснять почему так, а не просто «делай так»;
- иногда отправлять не «переделай всё», а «сделай первый шаг, потом посмотрим вместе»;
- показывать хорошие примеры: «Вон там похожая задача решена удачно, посмотри паттерн».
Кейс: как один формат комментариев помог вырастить мидлов
В одной команде с сильным сеньором сделали правило: на каждое существенное замечание он добавляет «поясняющий хвост»:
- Что здесь не так.
- К чему это может привести.
- Какой альтернативный подход есть.
Типичный комментарий выглядел не как «не делай так», а как мини-статья. Через полгода два джуна спокойно закрывали большинство задач без его участия и стали мидлами. А сами комментарии превратились в живую «вики», которую новички перечитывали, просматривая старые PR.
---
Итого: практическая «памятка» для ревьюера и автора
Для ревьюера
- Проверяйте идею решения, а не только код.
- Договаривайтесь о критериях до того, как спорить.
- Используйте инструменты, а не пытайтесь быть живым линтером.
- Разделяйте блокеры и пожелания.
- Помните: ваша задача — не показать, что вы умнее, а сделать код и продукт лучше.
Для автора
- Дробите задачи на небольшие PR.
- Пишите понятные описания: контекст, цель, спорные решения.
- Будьте готовы изменить решение, если аргументы ревьюера сильнее.
- Спрашивайте, если замечание непонятно; уточняйте, что именно ожидается.
---
Если в команде договориться о понятных правилах, использовать подходящие инструменты и помнить, что по обе стороны ревью — живые люди, а не «валидаторы», то code review превращается не в пытку, а в мощный и довольно приятный способ расти и делать продукт крепче.
