Давайте честно. Если вы ищете "ревью кода 1" — скорее всего, вы либо сталкиваетесь с задачами на собеседованиях, либо пытаетесь понять, как вообще организовать этот процесс в команде. И то, и другое — норм. Только вот большинство материалов в сети дают либо академическую теорию, либо разбор конкретных задач с тренажёров. А реальная жизнь сильно сложнее.
Поговорим о code review так, будто мы сидим на кухне в офисе и пьём остывший кофе.
Зачем вообще это нужно
На одном проекте мы год жили без обязательного review. Ну как жили — релизили баги в прод каждую неделю, потом героически чинили. Когда ввели обязательное одобрение MR от второго разработчика — количество инцидентов упало раза в три за месяц. Не потому что мы стали умнее. Просто кто-то второй смотрел на код свежим взглядом.
Code review решает несколько задач. Первая — ловить баги до того, как они улетят к пользователям. Вторая — обмен знаниями. Если джуниор написал странную конструкцию, а синьор в комментах объяснил, почему так делать не надо, — это обучение. Третья — единый стиль кодовой базы. Когда пять человек пишут на одном проекте без review, через полгода получается зоопарк из пяти разных стилей.
Но есть нюанс. Review само по себе не панацея. Если процесс организован криво — получите затянутые сроки, обиженных разработчиков и код, который всё равно придёт в прод с багами.
Уровни зрелости review
Забавно, но в поиске часто встречаются запросы типа "ревью кода 2", "ревью кода 3", "ревью кода 4", "ревью кода 7". Обычно это задачи с тренажёров типа Silvertests или Taskcode. Но давайте используем эту нумерацию иначе — как уровни зрелости вашего процесса.
Уровень 1 — review нет вообще. Коммитнул в main, молодец. Работает на стартапах из двух человек, но даже там рано или поздно начинает болеть.
Уровень 2 — формальное review. MR создаётся, кто-то ставит approve не глядя, код улетает. Бюрократия в чистом виде.
Уровень 3 — реальное review. Коллеги читают код, оставляют комментарии, автор правит. Процесс работает, но долго.
Уровень 4 — review с автоматизацией. Линтеры, статический анализ, AI-ассистенты ловят очевидные проблемы. Люди фокусируются на архитектуре и логике.
Уровень 5 — культура review. Команда не боится критики, все понимают ценность процесса, время на review заложено в планирование.
Большинство команд застревают где-то между вторым и третьим уровнем. И это больно.
Как организовать процесс
По-хорошему, правила должны быть зафиксированы. Не в голове у тимлида, а в документе, доступном всем.
Во-первых, размер MR имеет значение. Если пул-реквест на 2000 строк — его никто не будет нормально ревьюить. Просто физически невозможно удержать в голове все зависимости. Оптимально: 200-400 строк. Больше — разбивайте на несколько MR.
Во-вторых, сроки. Review не должно висеть неделями. В команде мы договорились: MR должен быть просмотрен в течение 24 часов. Если не успеваешь — отписываешься, когда сможешь. Это не жёсткое правило, но культура работает.
В-третьих, автор MR должен помочь ревьюеру. Нормальный description, скриншоты если UI, пояснения почему сделано так а не иначе.
## Что сделано
- Добавлена валидация email при регистрации
- Исправлен баг с двойной отправкой формы
## Как тестировать
1. Зайти на /register
2. Ввести невалидный email — должна быть ошибка
3. Ввести валидные данные — должен создаться пользователь
## Скриншоты
[скриншот формы с ошибкой валидации]
Пример description, который экономит время ревьюеру.
Типичные ошибки
Ошибка первая — ревьюить всё подряд. "Тут отступ не тот", "переменную можно назвать лучше", "лично я бы написал иначе". Это утомляет. Фокусируйтесь на важном: баги, уязвимости, архитектурные проблемы. Стиль — это линтер, не человек.
Ошибка вторая — учить вместо комментировать. "Ты неправильно написал, надо так" — плохо. "А что если тут возникнет исключение? Может, обернуть в try-catch?" — хорошо. Вопросы заставляют думать, утверждения — защищаться.
Ошибка третья — затягивать review. MR висит неделю, автор уже забыл что писал. Потом комменты прилетают, и контекст потерян. Review пока свежо.
Ошибка четвёртая — бояться отказать. Если код плохой — не approve. Не из вредности, а из ответственности. Лучше спор в комментах, чем откат в проде.
Есть ещё позиция "ревью кода не нужно". Иногда её аргументируют скоростью. Дескать, мы стартап, нам надо быстро, некогда заниматься бюрократией. Честно? Это работает до первого крупного факапа. Потом либо внедряют review, либо команда учится на своих ошибках. За счёт пользователей.
Чеклист для ревьюера
Не держите его в голове. Шорткат:
Проверяю логику. Делает ли код то, что должен? Не сломал ли автор что-то смежное?
Смотрю на граничные случаи. Что если массив пустой? Что если пользователь введёт 10 миллионов символов? Что если сеть упадёт посередине запроса?
Проверяю безопасность. SQL-инъекции, XSS, открытые эндпоинты, захардкоженные креды. Это критично.
# Плохо
query = f"SELECT * FROM users WHERE id = {user_input}"
# Тоже плохо, но почему-то часто встречается
password = "admin123" # TODO: вынести в env
Оцениваю читаемость. Через год кто-то будет это читать. Поймёт ли он, что тут происходит?
Смотрю на тесты. Есть ли они? Покрывают ли кейсы?
Всё остальное — дело линтеров и автоматизации.
Автоматизация — друг человека
Человек плохая замена машине для рутинных задач. Проверить отступы, найти неиспользуемые переменные, отловить потенциальный null pointer — это робот должен делать, не вы.
Настроенный CI/CD pipeline с линтерами, статическим анализом и автотестами снимает 70-80% нагрузки с ревьюера. Остаётся логика, архитектура, бизнес-смысл.
# .gitlab-ci.yml пример
stages:
- lint
- test
- review
lint:
stage: lint
script:
- pip install ruff mypy
- ruff check .
- mypy src/
test:
stage: test
script:
- pytest --cov=src tests/
coverage: '/TOTAL.+?(\d+%)$/'
Базовый пайплайн, который экономит время ревьюеров.
AI-инструменты — следующий шаг. Они не заменят человека, но подсветят очевидные проблемы. Баги с null-указателями, незакрытые ресурсы, потенциальные уязвимости. В Distiq, кстати, сделали бота, который автоматически ревьюит MR в GitLab и GitHub. Оставляет инлайн-комментарии, предлагает исправления. Российский сервис, данные не уходят за рубеж — для компаний с требованиями по локализации это важно. Интегрируется за пару минут через webhook. Сам пользуюсь на пет-проектах — экономит время на рутине, оставляет голову для сложных задач.
Культура важнее процесса
Можно прописать идеальный процесс, настроить автоматизацию, сделать чеклисты. Но если в команде токсичная атмосфера — ничего не заработает.
Review не должно быть полем битвы. Это не "я умный, ты глупый". Это "давай вместе сделаем код лучше". Хороший тон — хвалить в комментах не только ругать. "Крутой рефакторинг", "элегантное решение" — это мотивирует.
Если комменты остаются без ответа — тоже плохо. Автор должен реагировать: исправил, объяснил почему так, поспорил если не согласен. Диалог, не монолог.
И главное — review это часть работы. Не "отвлекающий фактор", не "бюрократия". Время на review должно учитываться при планировании спринта. Если разработчик тратит 2 часа в день на review коллег — это работа, не помеха работе.
Нормальное code review — это баланс между скоростью и качеством. Автоматизация рутинных проверок, чёткие правила, здоровая культура в команде. И тогда "ревью кода 1" — неважно, задача это с тренажёра или ваш первый опыт внедрения процесса — перестаёт быть проблемой. Становится просто частью работы.