Код-ревью (Code Review)

Код-ревью — это практика, при которой кто-то, отличный от автора, изучает предложенное изменение — обычно pull request (PR) или merge request — прежде чем оно будет слито в общую кодовую базу. Ревьюер проверяет корректность (действительно ли логика делает то, что заявлено), сопровождаемость (читаемо ли это, соответствует ли соглашениям команды), проблемы безопасности и упущенные граничные случаи, оставляет комментарии или запрашивает изменения перед одобрением. Почему это важно для создателей AI/SaaS-продуктов: код-ревью — это основной человеческий барьер качества в современном рабочем процессе разработки, и его важность в эпоху AI-написания кода не уменьшилась, а выросла — сгенерированный AI код часто выглядит правдоподобно, но может содержать тонкие логические ошибки, пробелы в безопасности (например, отсутствующие проверки авторизации) или ненужную сложность, которую уверенно выглядящий диф может маскировать. Ревью также является способом распространения неявных знаний по команде и способом, которым junior-разработчики изучают соглашения кодовой базы. Всё чаще AI-инструменты тоже непосредственно участвуют в этом этапе: автоматизированные боты ревью (например, ревьюер PR на базе Claude или код-ревью Copilot от GitHub) оставляют первый проход комментариев — отмечая очевидные проблемы — прежде чем человек делает окончательный, требующий суждения проход. Как это работает: разработчик открывает PR, описывающий изменение как диф относительно целевой ветки. Ревьюеры читают диф (часто с построчными комментариями к конкретным строкам), могут запросить изменения (блокируя слияние до их устранения), одобрить или оставить необязательные предложения. Многие команды требуют минимального числа одобрений и прохождения проверок CI перед слиянием PR, что обеспечивается правилами защиты веток на хостинговой платформе. Практический пример: разработчик открывает PR с заголовком «Добавить массовый CSV-экспорт для отчётов». Бот AI-ревью запускается автоматически и комментирует: «Строка 34: здесь весь набор данных загружается в память перед потоковой передачей в CSV — для крупных аккаунтов это может вызвать OOM; рассмотрите потоковую передачу на основе курсора». Затем человек-ревьюер добавляет: «Также этот эндпоинт не проверяет, есть ли у запрашивающего пользователя право экспорта для этого конкретного отчёта — см. паттерн в `reports_controller.rb`, строка 12». Автор исправляет обе проблемы, отправляет обновлённый коммит (тред обсуждения PR остаётся привязанным к исходным комментариям, чтобы ревьюеры могли проверить исправление), и человек-ревьюер нажимает «Одобрить», что в сочетании с зелёным прогоном CI разблокирует кнопку слияния. Весь обмен постоянно сохраняется в PR, так что через шесть месяцев новый член команды, задающийся вопросом «почему этот эндпоинт использует потоковую передачу вместо загрузки всего сразу», может прочитать исходный комментарий ревью и сразу понять обоснование.