Что такое код-ревью и кто им занимается

• Что такое код-ревью
• Зачем нужен код-ревью
• Кто занимается код-ревью
• Как проходит код-ревью на практике
• Какие инструменты используют для код-ревью
• Какие навыки нужны для проведения код-ревью
• Правила хорошего код-ревью

Код-ревью (от англ. code review — «проверка кода») — это процесс в программировании, когда один или несколько разработчиков изучают код коллеги до того, как он отправится в основную кодовую базу проекта. Проверяющий смотрит не только на то, работает ли код, но и на то, как он написан: понятна ли логика, нет ли уязвимостей, соответствует ли код принятым в команде стандартам. По сути, это техническая дискуссия: автор кода и ревьюер вместе решают, достаточно ли хорошо написан фрагмент, чтобы стать частью продукта.

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

Ревью — часть регулярной работы с кодом. Разобраться в основах разработки и понять, как устроена рутина в команде, поможет бесплатный курс «Какую профессию в программировании выбрать». Он рассчитан на тех, кто делает первые шаги в IT, и включает практические задания, понятные объяснения и реальный опыт работы с кодом.

Чаще всего code review проводят коллеги по команде. Конкретная роль того, кто делает проверку, зависит от размера компании и устройства процессов.

• Тимлид — главный технический ориентир для команды: следит за качеством решений, разбирает сложные случаи и чаще всего первым смотрит код коллег перед тем, как тот уходит в основную ветку.
• Senior-программист берёт на себя проверку, когда тимлид занят или задача требует глубокой экспертизы в конкретной области, к примеру в производительности запросов к базе данных или в криптографии.
• Коллеги по команде — middle- и иногда junior-разработчики. Ревью нужно для кода любого члена команды вне зависимости от грейда: нет такой нормы, что проверяют исключительно работу джунов, в то время как сеньоры отправляют свои задачи без проверки.

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

Каждая команда выстраивает процесс под свои задачи. Но типовая последовательность шагов выглядит примерно одинаково в большинстве российских IT-компаний.

• Автор готовит изменения. Разработчик завершает задачу, запускает автоматические проверки (линтер и тесты) и только после этого открывает pull request — запрос на слияние кода с основной веткой проекта. Обычно к нему добавляют краткое описание: что изменилось и почему именно так. Это экономит время ревьюера и снижает число уточняющих вопросов.
• Назначение ревьюера. В небольших командах ревьюера выбирают вручную — обычно того, кто лучше всего знает затронутую часть кода. В крупных компаниях процесс автоматизирован в соответствии с загрузкой членов команды.
• Проверка кода. Ревьюер движется от общего к частному: сначала разбирается, какую задачу решал автор, затем оценивает архитектуру и логику и только потом смотрит на отдельные функции и алгоритмы. Такой порядок позволяет не тратить время на точечные правки в коде, который в итоге придётся переписать целиком.
• Обратная связь и доработка. Ревьюер оставляет комментарии в интерфейсе системы контроля версий. Автор вносит правки и обновляет pull request — при необходимости цикл повторяется.
• Финальное согласование. Распространённая практика — подтверждение: от тимлида или старшего коллеги, а также от представителя смежного отдела, который проверяет общий стандарт кода. После этого изменения сливаются в основную ветку.

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

• Техническая экспертиза. Ревьюер должен ориентироваться в архитектурных паттернах, принципах безопасности и производительности.
• Умение расставлять приоритеты. Задача не добиться совершенства, а обеспечить последовательное улучшение кодовой базы: код, который становится лучше, не должен неделями зависать в ревью только потому, что он не идеален.
• Письменная коммуникация. Опытный ревьюер отличается от новичка умением чётко и ёмко формулировать мысли в тексте. Комментарий без объяснения причины не помогает автору исправиться и создаёт напряжение в команде.
• Понимание контекста. Прежде чем оценивать код, ревьюер разбирается, какую задачу он решает.
• Готовность сомневаться в себе. Если архитектурное решение кажется избыточным, стоит сначала спросить, есть ли у этой сложности причина, а не сразу требовать переработки.

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