Прибыль:
- Возможность использовать ИИ в качестве фильтра первоначальной проверки с категориями и тегами серьезности.
- Способность фильтровать выводы человеческим разумом для проверки/ложного срабатывания/применения
- Способность обеспечивать соблюдение требований по одобрению человеком бизнес-правил, архитектуры и решений, важных для безопасности.
Проверка кода — это когда изменение, написанное разработчиком, проверяется кем-то другим перед его объединением. Хороший обзор; Он выявляет ошибки на ранней стадии, обменивается информацией и поддерживает согласованность базы кода. Но обзоры утомляют, отвлекают и становятся поверхностными в условиях нехватки времени. Искусственный интеллект здесь двойной помощник: он позволяет как предварительно очистить собственный код, который вы отправляете на проверку, так и более зорким взглядом изучить чужой пиар (pull request).
Критическое различие заключается в следующем: ИИ ускоряет и улучшает рассмотрение, но не может взять на себя ответственность за одобрение. Предложение «ИИ посмотрел, все чисто» не является одобрением. Окончательное решение о слиянии принимает инженер, знающий код и контекст.
Обзор того, чем ИИ хорош и плох
Подходит для: промахов проверки на null, утечек ресурсов (файл/ссылка остается открытым), неперехваченных исключений, явно неправильных условий (>= вместо >), предложений по переименованию, удобочитаемости, отсутствия краевого регистра, простых признаков безопасности (например, объединения строк SQL), обнаружения дублированного кода.
Слабые стороны: глубокие недостатки, которые нарушают ваши бизнес-правила, но требуют контекста и времени, например синтаксически правильная логика, соответствие архитектуре, реальные узкие места в производительности, ошибки параллелизма. ИИ также выдает ложноположительные результаты (принимая за проблему то, что на самом деле не является проблемой) и ложноотрицательные результаты (упуская настоящую ошибку). Таким образом, его вывод представляет собой «список предостережений», а не окончательный вердикт.
Внимание: то, что ИИ говорит «нет проблем», не доказывает, что код правильный. Ложноотрицательные результаты молчат; Самые опасные ошибки — те, о которых никогда не упоминается в обзоре.
Этапы систематического обзора
- Дайте контекст. Добавьте в приглашение цель изменения, соответствующую проблему и критерии приемки, если таковые имеются. Бесцельный обзор приводит к бесцельной интерпретации.
- Разбейте это на категории. Попросите модель классифицировать результаты как «ошибка/безопасность/производительность/читаемость/стиль»; так вы отделите критическое от шума.
- Запросите метку серьезности. Дайте каждому результату оценку «высокая/средняя/низкая» и укажите «причину» и «рекомендуемое исправление».
- Отфильтруйте это своими глазами. Оцените каждую находку: реальна ли она (проверьте), ложноположительная ли она (напишите обоснование), нет ли чего-то недостающего (дополните свои знания).
- Проверьте критические пути вручную. Читайте и выполняйте маршруты, связанные с деньгами, идентификацией, авторизацией и удалением данных самостоятельно, не полагаясь на ИИ.
Три мини-кейса
Случай 1. Обнаружена тихая нулевая ошибка. Одна команда попросила ИИ предварительно просмотреть 380-строчный PR. В модели отмечен способ, при котором ответ внешней службы может быть нулевым, но в коде для этого не было выполнено никаких проверок. Рецензент проверил этот путь и добавил нулевую проверку; Аналогичная ошибка привела к 2-часовому перерыву в производстве в предыдущем квартале.
Случай 2 — Ложноположительное исключение. ИИ в цикле отметил «возможную проблему с производительностью». Рецензент закрыл это как ложное срабатывание, зная, что цикл работает только с максимум 5 элементами (он перебирает перечисление). Модель, не зная контекста, предупредила; Человек, который знал контекст, принял правильное решение.
Случай 3 — ИИ пропустил ошибку бизнес-правила. Хотя согласно правилу кампании скидка на счет должна составлять максимум 30 %, код допускал 50 %. ИИ никогда не замечал этой синтаксически совершенной логической ошибки; потому что он не знал правила. Баг был обнаружен в обзоре владельцем продукта, который знал критерии приемки. Урок: проверка бизнес-правил — это человеческая работа.
Четыре копируемых шаблона
Целенаправленный обзор по категориям:
Роль: Дотошный рецензент кода. Цель изменения: {{цель/проблема}}Просмотрите эту разницу. Предоставьте результаты по следующим категориям: [Ошибка] [Безопасность] [Производительность] [Читаемость] [Стиль]. Для каждого результата: файл:строка, серьезность (высокая/средняя/низкая), причина, рекомендуемое исправление. Отметьте «возможно», если не уверены. Вы не знаете правил бизнеса; Спросите меня о местах, где требуются правила.{{diff}}
Чтобы подготовиться к просмотру собственного кода:
Ознакомьтесь с этим изменением, прежде чем открывать PR. Ищите: отсутствие нулевого значения/проверки ошибок, утечку ресурсов, крайний случай, секретную, непроверенную ветку. Перечислите результаты в порядке приоритетности; предложите исправление по 1 строке для каждого.{{code}}
Охота за крайними случаями:
Перечислите входные данные и ситуации, в которых эта функция может выйти из строя: пусто, нулевое значение, слишком большое значение, отрицательное значение, одновременный вызов, сетевая ошибка, частичные данные. Для каждого случая напишите ожидаемое поведение и то, что будет делать текущий код.{{function}}
Сканирование запахов безопасности (предварительная проверка):
Обратите внимание на общие признаки безопасности в этом коде: конкатенация SQL/команд, непроверенный ввод, неизменяемый встроенный секрет, небезопасная десериализация, отсутствие проверки привилегий. Разделите выводы на «достоверные/вероятные/знания». Это предварительный просмотр; Это не окончательное решение.{{code}}
Слабая подсказка / Сильная подсказка
Слабый: «Есть ли в этом пиаре ошибка?»
Сильное: «Цель: добавить скидку по купону к общей сумме корзины (скидка должна быть не более 30 % — вы не можете проверить это правило самостоятельно, просто сообщите мне, устанавливает ли код верхний предел). Изучите различия; дайте результаты по категориям + серьезность + предлагаемое исправление, отметьте «возможно», если не уверены. [разница]»
В сильной версии четко указаны намерения, бизнес-правила и границы ИИ; Таким образом, приходят полезные результаты, и область, неизвестная модели, остается ясной.
Тип поиска
надежность ИИ
роль мужчины
Отсутствует проверка на нулевое значение/ошибку
высокий
Проверьте и примените
Читабельность/стиль
высокий
Выбирайте по предпочтениям
Простой запах безопасности
средний
Завершить, отсканировать с помощью автомобиля
Соблюдение бизнес-правил
низкий
Это совершенно человечно.
Параллелизм/архитектура
низкий
Требуется экспертиза
Проверка ИИ не является заменой проверки человеком
Позиционируйте обзор ИИ как «первый фильтр»: дешевый, быстрый и неутомимый предварительный проход. Этот фильтр освобождает внимание человека-рецензента от неважных деталей (пробела, имени) и направляет его на места, которые действительно требуют размышления — бизнес-правила, архитектура, результат безопасности. Но одобрение слияния — это подпись ответственного лица внутри команды. Независимая проверка, проводимая как минимум одним компетентным инженером, обязательна для изменений, важных для безопасности.
Совет: читайте список выводов, которые выдает ИИ, как «что нужно проверить», а не как «что нужно сделать». Либо проверьте и примените каждый пункт, либо запишите в одном предложении, почему вы его прошли; эта трассировка делает проверку проверяемой.
Распространенные ошибки
- Это значит «ИИ посмотрел, все чисто». Это ложное чувство уверенности из-за ложноотрицательных результатов.
- Не давая контекста. Без цели и критериев приемлемости модель дает лишь поверхностные интерпретации стиля.
- Слепое применение ложных срабатываний. Исправление каждого предупреждения модели может привести к поломке работающего кода.
- Спрашиваем модель о бизнес-правилах. Модель не знает правила; Задача человека проверить это.
- Не допускайте дискриминации в отношении насилия. Помещение критического заключения безопасности и предложенного имени в одну сумку затмевает то, что важно.
В заключение
ИИ — это неутомимый первый фильтр при проверке кода: он хорошо улавливает промахи по нулевым значениям/ошибкам, крайние случаи и простую безопасность; но он слаб в отношении недостатков, требующих контекста, таких как бизнес-правила, архитектура и параллелизм, и дает как ложноположительные, так и ложноотрицательные результаты. Запрашивайте результаты по категориям и серьезности, фильтруйте их с помощью человеческого интеллекта, проверяйте критические пути вручную. Одобрение всегда является подписью ответственного инженера.
Задача приложения
Выберите реальный или недавний PR/diff. Во-первых, попросите ИИ просмотреть его с помощью шаблона «объективно-ориентированного обзора по категориям». Поместите результаты в таблицу и решите для каждого из них: верно (я проверил), ложноположительно (вот мои рассуждения) или будет реализовано. Затем совершите экскурсию самостоятельно и попытайтесь найти хотя бы одну вещь (особенно бизнес-правило или крайний случай), которой не хватает ИИ, и запишите это.
контрольный список
- [ ] Я использую обзор ИИ в качестве первого фильтра, а не одобрения.
- [ ] Я добавляю цель и критерии приемки в запрос на проверку.
- [ ] Я отделяю выводы от шума по категориям и сильно их желаю.
- [ ] Я сознательно фильтрую каждый вывод, чтобы подтвердить/ложноположительно/применить.
- [ ] Как человек, я проверяю соответствие бизнес-правилам и архитектуре.
- [ ] Для внесения критических с точки зрения безопасности изменений мне требуется одобрение квалифицированного инженера.