Перейти к основному содержимому

Ревью сгенерированного кода

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

Почему это важно. За то, что попало в кодовую базу с вашего одобрения, отвечаете вы, и «это написал ассистент» никогда не было приемлемым объяснением инцидента в продакшене. Объём делает задачу тяжелее: сгенерировать больше кода, чем кто-нибудь реально прочитает, очень легко.

Что нужно понимать​

  • Понимаете ли вы изменение достаточно, чтобы за него отвечать
  • Как оно поведёт себя в случаях, о которых в запросе не было ни слова
  • Существует ли на самом деле каждый использованный API и ведёт ли себя так, как предполагалось
  • Решает ли код настоящую задачу или только сформулированную
  • Подходит ли он этой кодовой базе или какой-то абстрактной

Основные темы​

Что проверять в первую очередь​

  • Существование: есть ли на самом деле каждый использованный API, пакет и параметр
  • Граничные случаи: пусто, null, ошибка, параллельный доступ, очень большой объём
  • Обработка ошибок — то, что тихо опускают чаще всего
  • Освобождение ресурсов: подписки, контроллеры, файлы
  • Безопасность: авторизация, инъекции, секреты, логирование

Соответствие проекту​

  • Следует ли код принятым здесь подходам — или подходам другого фреймворка
  • Не дублирует ли он то, что уже есть
  • Не тянет ли новую зависимость ради того, что в проекте уже реализовано
  • Совпадает ли уровень абстракции с окружающим кодом

Характерные провалы​

  • Правдоподобные API, которых никогда не существовало
  • Код, который компилируется и при этом неуловимо неверен
  • Избыточное проектирование: слои и настройки под требования, которых никто не формулировал
  • Комментарии, описывающие замысел, а не поведение, — они прячут расхождение между ними
  • Тесты, проверяющие то, что код делает, а не то, что он должен делать

Метод​

  • Запускать всегда: «компилируется» не значит «работает»
  • Читать сам diff, а не его пересказ
  • Сверяться с документацией, а не с уверенным тоном ответа
  • Попросить объяснение — и проверить объяснение
  • Если направление неверное, отбрасывать и переформулировать задачу, а не латать результат

Объём​

  • Держать изменения такими, чтобы их можно было честно прочитать
  • Не принимать то, чего вы не читали
  • Замечать момент, когда ревью превратилось в беглый просмотр

Уровни​

УровеньКак это выглядит
JuniorПроверяет, что код компилируется и делает очевидное.
MiddleСмотрит на граничные случаи, обработку ошибок и соответствие проекту. Незнакомые API сверяет с документацией.
SeniorЧитает сгенерированный код с недоверием, находит тонкие ошибки корректности и проблемы безопасности, удерживает объём так, чтобы ревью оставалось настоящим.

Практика​

Для начала​

  • Проверьте каждый API Возьмите сгенерированное изменение и сверьте каждый вызов с документацией.

  • Найдите границы Для сгенерированной функции выпишите входные данные, которые она не обрабатывает. Проверьте их.

  • Перескажите своими словами Объясните сгенерированное изменение другому человеку, не подглядывая в код.

Дальше​

  • Ищите ошибку намеренно Возьмите изменение и, прежде чем принять его, попробуйте найти случай, в котором оно неверно.

  • Разберите тесты Посмотрите на сгенерированные тесты: проверяют они поведение или реализацию.

  • Отбросьте и переформулируйте Когда результат уходит не туда, выбросьте его и измените постановку задачи вместо правок на месте.

Проверьте себя​

  • Сможете ли вы на разборе инцидента объяснить каждую строку, принятую вами на этой неделе?
  • Когда вы в последний раз поймали уверенно выдуманный API?
  • Что, по вашему опыту, сгенерированное изменение обычно упускает?
  • Вы читаете сами изменения или их пересказ?
  • Сколько сгенерированного кода вы приняли, ни разу не запустив?
  • Что заставит вас отбросить результат целиком, а не чинить его?

Материалы​

  • Google's Code Review Developer Guide — на что смотреть в любом изменении. Этот чек-лист применим к сгенерированному коду без единой поправки и хорошо защищает от беглого просмотра.
  • OWASP Code Review Guide — сторона безопасности: именно здесь у сгенерированного кода чаще всего пробелы, потому что в запросе о ней не упоминали.
  • Exploring Generative AI — отчёты практиков из Thoughtworks о том, где результат ломается в реальных кодовых базах, с примерами.
  • Test Desiderata — полезно, когда нужно оценить сгенерированные тесты: они часто выглядят основательно, но не проверяют ничего важного.
  • Anthropic: reducing hallucinations — почему возникает уверенная выдумка и что её снижает; заодно подсказывает, куда смотреть внимательнее всего.