Прибуток:
- Можливість використовувати ШІ як фільтр початкового огляду з категоріями та тегами серйозності
- Можливість фільтрувати висновки за допомогою людського розуму для перевірки/хибного позитивного результату/застосування
- Здатність забезпечити дотримання вимог людського схвалення щодо бізнес-правил, архітектури та важливих для безпеки рішень
Перегляд коду — це коли зміна, написана розробником, переглядається кимось іншим перед тим, як її об’єднати. Хороший огляд; Він рано виявляє помилки, ділиться інформацією та підтримує узгодженість кодової бази. Але огляди втомлюють, відволікають і стають поверхневими під тиском часу. Штучний інтелект тут є подвійним помічником: він дозволяє як попередньо очистити власний код, який ви надсилаєте на перевірку, так і детальніше перевірити чужий PR (пулл-запит).
Важлива відмінність полягає в наступному: штучний інтелект прискорює та покращує перевірку, але він не може взяти на себе відповідальність за затвердження. Речення «ШІ подивився, все чисто» не є підтвердженням. Остаточне рішення про «злиття» приймає інженер, який знає код і контекст.
Чим AI хороший і поганий у огляді
Підходить для: промахів перевірки нуля, витоків ресурсів (файл/посилання залишаються відкритими), неперехоплених винятків, явно неправильних умов (>= замість >), пропозицій щодо перейменування, читабельності, відсутності крайнього регістру, простих запахів безпеки (наприклад, конкатенація рядків SQL), виявлення дублікатів коду.
Слабкі сторони: глибокі недоліки, які порушують ваше бізнес-правило, але вимагають контексту та часу, наприклад синтаксично правильна логіка, архітектурна відповідність, реальні вузькі місця продуктивності, помилки паралельного виконання. ШІ також створює хибні спрацьовування (приймаючи щось, що насправді не є проблемою, за проблему) і хибні негативи (пропускаючи справжню помилку). Тому його результатом є «список попереджень», а не остаточний вердикт.
Застереження: те, що штучний інтелект каже «немає проблем», не означає, що код правильний. Помилкові негативи мовчать; Найнебезпечніші помилки - це ті, про які ніколи не згадується в огляді.
Етапи систематичного огляду
- Дайте контекст. Додайте до підказки мету зміни, відповідну проблему та критерії прийнятності, якщо такі є. Безцільне перегляд породжує безцільне тлумачення.
- Розбийте його на категорії. Попросіть модель класифікувати результати як «помилка/безпека/продуктивність/читабельність/стиль»; так ви відокремите критичне від шуму.
- Запит на етикетку серйозності. Дайте кожному знахідці оцінку «високий/середній/низький» і додайте «причину» та «рекомендоване виправлення».
- Відфільтруйте його своїми очима. Оцініть кожну знахідку: чи справжня вона (перевірте), чи хибно позитивна (напишіть обґрунтування), чи чогось не вистачає (додайте власні знання).
- Перевірте критичні шляхи вручну. Читайте та виконуйте маршрути, що включають гроші, ідентифікацію, авторизацію та видалення даних самостійно, не покладаючись на ШІ.
Три міні-чохли
Випадок 1 — виявлено тиху нульову помилку. Одна команда попередньо перевірила 380-рядковий PR. Модель позначила спосіб, у який відповідь зовнішньої служби може бути нульовою, але перевірки цього в коді не проводилися. Рецензент перевірив цей шлях і додав нульову перевірку; Подібна помилка спричинила 2-годинну перерву у виробництві в попередньому кварталі.
Випадок 2 — Хибнопозитивне усунення. ШІ позначив «можливу проблему продуктивності» в циклі. Рецензент закрив це як хибне спрацьовування, знаючи, що цикл працює лише з максимум 5 елементами (він перебирає enum). Модель, яка не знала контексту, попередила; Людина, яка знала контекст, прийняла правильне рішення.
Випадок 3 — помилка ШІ пропустив бізнес-правило. У той час як дисконтний обліковий запис має становити максимум 30% відповідно до правила кампанії, код допускає 50%. ШІ ніколи не помічав цієї синтаксично ідеальної логічної помилки; тому що він не знав правила. Помилка була виявлена під час огляду власником продукту, який знав критерії прийняття. Урок: перевірка бізнес-правил – це робота людини.
Чотири шаблони, які можна копіювати
Цілеспрямований, категоризований огляд:
Посада: Ретельний рецензент коду. Мета зміни: {{purpose / issue}}Переглянути цю різницю. Надайте висновки в цих категоріях: [Помилка] [Безпека][Продуктивність] [Читабельність] [Стиль]. Для кожного результату: файл: рядок, серйозність (висока/середня/низька), причина, рекомендоване вирішення. Позначте «можливо», якщо ви не впевнені. Ви не знаєте правил бізнесу; Запитайте мене про місця, де потрібні правила.{{diff}}
Щоб підготуватися до перегляду власного коду:
Перегляньте цю зміну, перш ніж відкривати PR. Шукайте: відсутність null/bugcheck, resource leak, edge case, secret, untested branch. Перелічіть висновки в порядку пріоритету; запропонуйте виправлення по 1 рядку для кожного.{{code}}
Полювання на краї:
Перелічіть вхідні дані та ситуації, коли ця функція може зламатися: порожній, нульовий, занадто великий, негативний, одночасний виклик, помилка мережі, часткові дані. Для кожного випадку напишіть очікувану поведінку та те, що робитиме поточний код.{{function}}
Сканування запаху безпеки (попередня перевірка):
Зверніть увагу на загальні запахи безпеки в цьому коді: конкатенація SQL/команд, неперевірений вхід, незмінний вбудований секрет, незахищена десеріалізація, відсутність перевірки привілеїв. Розділіть висновки на «певні / ймовірні / знання». Це попередній скринінг; Це не остаточне рішення.{{code}}
Слабка підказка / Сильна підказка
Слабкий: «У цьому PR є помилка?»
Сильна: «Мета: додати знижку за купоном до загальної суми кошика (знижка не повинна перевищувати 30% — ви не можете перевірити це правило самостійно, просто скажіть мені, чи код накладає верхню межу). Вивчіть різницю; надайте висновки за категорією + серйозністю + запропонованим виправленням, позначте «можливо», якщо не впевнені. [diff]»
Сильна версія чітко визначає намір, бізнес-правило та межі ШІ; Таким чином, приходять корисні знахідки, а область, невідома моделі, залишається відкритою.
Тип знахідки
Надійність ШІ
чоловіча роль
Відсутня перевірка на нуль/помилку
висока
Перевірити та застосувати
Читабельність/стиль
висока
Вибирайте за бажанням
Простий запах безпеки
середній
Завершити, сканувати за допомогою автомобіля
Дотримання бізнес-правил
низький
Це цілком людське.
Паралелізм/архітектура
низький
Потрібен експертний огляд
Перевірка штучним інтелектом не замінить перевірку людиною
Розташуйте штучний інтелект як «перший фільтр»: дешевий, швидкий, невтомний попередній проход. Цей фільтр звільняє увагу рецензента від неважливих деталей (пробіл, ім’я) і спрямовує його на місця, які дійсно вимагають обмірковування — бізнес-правило, архітектура, результат безпеки. Але схвалення злиття є підписом відповідальної особи в команді. Незалежний огляд принаймні одним компетентним інженером є обов’язковим для важливих для безпеки змін.
Порада: прочитайте список знахідок, які видає ШІ, як «що потрібно перевірити», а не як «що потрібно зробити». Або перевірте та застосуйте кожен пункт, або запишіть одним реченням, чому ви його пройшли; це трасування робить огляд доступним для перевірки.
Поширені помилки
- Це означає «AI подивився, все чисто». Це помилкове почуття впевненості через помилкові негативи.
- Без контексту. Без мети та критеріїв прийнятності модель створює лише поверхневі інтерпретації стилю.
- Сліпе застосування помилкових спрацьовувань. Виправлення кожного попередження моделі може порушити запущений код.
- Запитання моделі про бізнес-правило. Модель не знає правила; Перевірити це належить людині.
- Не дискримінуйте насильство. Помістити в один мішок важливу інформацію про безпеку та пропозицію назви затьмарює те, що є важливим.
Підсумовуючи
AI є невтомним першим фільтром у перевірці коду: він добре вловлює нульові/помилкові промахи, крайні випадки та простий захист; але він слабкий щодо недоліків, що вимагають контексту, таких як бізнес-правила, архітектура та паралелізм, і створює як помилкові спрацьовування, так і помилкові негативи. Запитуйте висновки за категоріями та серйозністю, фільтруйте кожен за допомогою людського інтелекту, вручну перевіряйте критичні шляхи. Погодження завжди є підписом відповідального інженера.
Аплікаційне завдання
Виберіть реальний або останній PR/diff. По-перше, попросіть штучний інтелект перевірити його за допомогою шаблону «об’єктивно-орієнтований перегляд категорії». Помістіть висновки в таблицю та вирішіть для кожного: правда (я перевірив), хибно позитивний (ось мої міркування) чи для впровадження. Потім зробіть екскурсію самостійно та спробуйте знайти принаймні одну річ (особливо бізнес-правило або граничний випадок), якої бракує ШІ, і запишіть це.
контрольний список
- [ ] Я використовую огляд штучного інтелекту як перший фільтр, а не як схвалення.
- [ ] Я додаю мету та критерії прийняття до підказки для перегляду.
- [ ] Я відокремлю висновки від шуму за категоріями та дуже хочу їх.
- [ ] Я свідомо фільтрую кожен висновок для підтвердження/хибного позитивного результату/застосування.
- [ ] Як людина, я перевіряю бізнес-правила та відповідність архітектурі.
- [ ] Мені потрібен дозвіл кваліфікованого інженера для важливих для безпеки змін.