Code review

Что такое code review

Code review (ревью кода, код-ревью) — практика, при которой изменения в коде перед попаданием в основную ветку читает и одобряет хотя бы один другой разработчик. Формально это ворота качества, фактически — ещё и главный способ передачи знаний в команде: за счёт ревью про каждый кусок системы знает больше одного человека.

Слово «ревью» само по себе шире: так называют любой разбор результата другими людьми. В IT встречаются три разных ревью, и их часто путают:

Ниже — про первое: когда в разработке говорят «ревью» без уточнения, имеют в виду именно его.

Зачем это нужно

• Дефекты дешевле находить до production. Стоимость ошибки растёт на каждом этапе: на ревью — пять минут, в проде — инцидент и SLA.
• Распространение знаний. Уходит человек в отпуск или из компании — система не становится чёрным ящиком.
• Единообразие. Через полгода код читается как написанный одним человеком, а не пятью.
• Ответственность. Автор знает, что код прочитают, и качество вырастает ещё до отправки.

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

Как проходит процесс

Ветка от main
    ↓
Коммиты + тесты
    ↓
Pull / Merge Request
    ↓
Автоматика: линтер, тесты, сборка в CI
    ↓
Ревью людьми → комментарии → правки
    ↓
Approve → merge в main → удаление ветки

Инструмент зависит от хостинга репозитория: pull request в GitHub и Bitbucket, merge request в GitLab. Суть одна — диалог вокруг диффа. Ветвление обычно подчиняется принятой в команде модели, например Git Flow.

Важное правило: всё, что может проверить машина, человек проверять не должен. Форматирование, стиль, неиспользуемые импорты, покрытие тестами — это работа линтера и CI/CD. Человек на ревью занимается тем, чего машина не умеет: логика, читаемость, уместность решения.

Что смотреть на ревью

• Решает ли изменение заявленную задачу. Начинать нужно с описания PR, а не с первой строчки диффа.
• Понятность. Если приходится вчитываться, чтобы понять намерение, — это замечание. Через год этот код будет читать человек без контекста.
• Границы и ошибки. Пустой список, null, таймаут внешнего сервиса, повторный вызов.
• Безопасность. Пользовательский ввод в SQL, секреты в коде, отсутствие проверки прав.
• Тесты. Есть ли они и проверяют ли они поведение, а не факт вызова функции.
• Простота. Абстракция «на будущее», которая нужна в одном месте, — это будущий долг, а не задел.

Чего на ревью делать не стоит: переписывать чужое решение под свой вкус. Если код работает, читается и решает задачу — «я бы сделал иначе» не основание блокировать merge.

Минорные изменения: что это

В контексте ревью минорные изменения — правки, не влияющие на работу системы: опечатка в комментарии, название переменной, лишняя пустая строка. Их называют nit (от nitpick, «придирка»). Такие замечания не должны блокировать merge — их помечают явно, чтобы автор понимал приоритет.

Полезная договорённость об уровнях комментариев:

must:      блокирует merge, нужно исправить
should:    стоит исправить, но на усмотрение автора
nit:       минорное, можно проигнорировать
question:  не замечание, а вопрос на понимание

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

В соседнем смысле «минорный» встречается в версионировании. По semver версия пишется как MAJOR.MINOR.PATCH: мажорная меняется при несовместимых изменениях, минорная — при добавлении функциональности с сохранением обратной совместимости, патч — при исправлениях. Обновление 2.3.1 → 2.4.0 минорное: старый код продолжит работать. Смысл слова определяется контекстом: рядом с диффом — «мелкая правка», рядом с номером версии — «обратно совместимое изменение».

Как делать ревью быстрым

Главный враг ревью — не строгость, а размер и задержка. PR на 2000 строк не читают, а одобряют не глядя; PR, который висит три дня, блокирует автора и обрастает конфликтами.

• Держите PR маленькими — 200–400 строк читаются внимательно, дальше внимание падает.
• Реагируйте в течение рабочего дня. Ревью в приоритете выше своей задачи: чужая работа стоит.
• Пишите нормальное описание PR — что и зачем, а не «фиксы».
• Спорите больше двух раундов — идите разговаривать. Тред на двадцать комментариев решается за три минуты голосом.
• Смягчайте формулировки. «Здесь потеряется исключение» вместо «ты не обработал ошибку»: обсуждается код, а не автор.
• Не одобряйте не глядя. Approve — это подпись, что вы разделяете ответственность за изменение.

Связанные термины

• Git — система контроля версий, вокруг которой строится процесс
• GitHub — pull request как основная форма ревью
• GitLab — merge request и встроенный CI
• CI/CD — автоматические проверки, снимающие рутину с ревьюера
• Agile / процессы разработки — где ревью входит в Definition of Done
• Тестирование и бенчмарки — то, что ревью не заменяет