Добици:
- Могућност коришћења АИ као почетног филтера за преглед са категоријама и ознакама озбиљности
- Способност филтрирања налаза људским умом за верификацију/лажно позитиван/примену
- Способност спровођења захтева људског одобрења за пословна правила, архитектуру и безбедносне критичне одлуке
Преглед кода је када промену коју је написао програмер прегледа неко други пре него што се споји. Добра рецензија; Рано хвата грешке, дели информације и одржава базу кода доследном. Али рецензије су заморне, склоне ометању и постају површне под притиском времена. Вештачка интелигенција је овде двоструки помоћник: омогућава вам да унапред очистите сопствени код који шаљете на преглед и да оштријим оком испитате туђи ПР (повуци захтев).
Критична разлика је следећа: АИ убрзава и побољшава преглед, али не може преузети одговорност за одобрење. Реченица "АИ погледао, чисто је" није потврда. Коначна одлука о "спајању" је на инжењеру који познаје код и контекст.
У чему је АИ добра и лоша у прегледу
Добро за: промашаје нулте провере, цурење ресурса (датотека/линк остају отворени), неухваћени изузеци, очигледно погрешни услови (>= уместо >), предлози за преименовање, читљивост, недостају ивица, једноставне безбедносне мирисе (као што је спајање СКЛ низова), откривање дупликата кода.
Слабости: Дубоке мане које крше ваша пословна правила, али захтевају контекст и тајминг, као што су синтаксички исправна логика, архитектонска усклађеност, стварна уска грла у перформансама, грешке истовремености. АИ такође производи лажне позитивне резултате (помешати нешто што заправо није проблем за проблем) и лажне негативне (недостаје права грешка). Стога је његов резултат „листа опреза“, а не коначна пресуда.
Опрез: Само зато што АИ каже „нема проблема“ не доказује да је код тачан. Лажни негативи ћуте; Најопасније грешке су оне које се никада не помињу у рецензији.
Кораци систематског прегледа
- Дајте контекст. Додајте сврху промене, релевантно питање и критеријуме прихватања, ако их има, у упит. Бесмислени преглед производи бесмислено тумачење.
- Поделите га у категорије. Замолите модел да класификује налазе као „буг/сигурност/перформансе/читљивост/стил”; па одвајаш критичко од буке.
- Затражите ознаку озбиљности. Дајте сваком налазу „високу/средњу/ниску” оцену и укључите „узрок” и „препоручену исправку”.
- Филтрирајте га својим очима. Процените сваки налаз: да ли је стваран (провери), да ли је лажно позитиван (напишите оправдање), да ли нешто недостаје (додајте своје знање).
- Ручно проверите критичне путање. Читајте и извршавајте руте које укључују новац, идентитет, ауторизацију и брисање података без ослањања на АИ.
Три мини кућишта
Случај 1 — Ухваћена је тиха нулта грешка. Један тим је претходно прегледао АИ ПР од 380 редова. Модел је означио начин на који одговор екстерне услуге може бити нула, али у коду нису извршене провере за то. Људски рецензент је верификовао ову путању и додао нулту проверу; Слична грешка изазвала је двочасовни прекид производње у претходном кварталу.
Случај 2 — Лажно позитивна елиминација. АИ је означио „могући проблем са перформансама“ у петљи. Рецензент је ово затворио као лажно позитивно, знајући да петља ради само са највише 5 елемената (петља преко енума). Манекенка, која није познавала контекст, упозорила је; Особа која је познавала контекст донела је исправну одлуку.
Случај 3 — АИ пропустио грешку пословног правила. Док би рачун за попуст требало да буде максимално 30% према правилу кампање, код је дозвољавао 50%. АИ никада није приметио ову синтаксички савршену логичку грешку; јер није знао правило. Грешка је ухваћена у прегледу од стране власника производа који је знао критеријуме прихватања. Поука: валидација пословних правила је људски посао.
Четири шаблона за копирање
Циљно оријентисана, категоризована рецензија:
Улога: Педантан рецензент кода. Сврха промене: {{пурпосе / иссуе}}Прегледајте ову разлику. Наведите налазе у овим категоријама: [Буг] [Безбедност][Перформансе] [Читљивост] [Стил]. За сваки налаз: датотека:ред, озбиљност (висока/средња/ниска), узрок, препоручена исправка. Означите „могуће“ ако нисте сигурни. Не познајете правила пословања; Питајте ме о местима која захтевају правила.{{дифф}}
Да бисте се припремили за преглед сопственог кода:
Прегледајте ову промену пре него што отворите ПР. Потражите: недостаје нулл/бугцхецк, цурење ресурса, рубни случај, тајна, нетестирана грана. Наведите налазе по приоритету; предложи исправку 1 ред за сваки.{{цоде}}
Потрага за ивичним случајем:
Наведите улазе и ситуације у којима би ова функција могла да се поквари: празна, нула, превелика, негативна, истовремени позив, мрежна грешка, делимични подаци. За сваки случај напишите очекивано понашање и шта ће тренутни код урадити.{{фунцтион}}
Безбедносно скенирање мириса (пре скрининга):
Потражите уобичајене безбедносне мирисе у овом коду: СКЛ/командна конкатенација, непотврђени унос, непроменљива уграђена тајна, несигурна десеријализација, недостатак провере привилегија. Одвојите налазе на "извесно / вероватно / знање". Ово је прелиминарни скрининг; То није коначна одлука.{{цоде}}
Слаби промпт / Јаки промпт
Слаб: "Да ли постоји грешка у овом ПР-у?"
Снажно: „Сврха: додајте попуст купона у укупну количину корпе (попуст не сме бити већи од 30% — не можете сами да проверите ово правило, само ми реците да ли код намеће горњу границу). Испитајте разлику; дајте налазе по категорији + озбиљности + предложена исправка, означите 'могуће' ако нисте сигурни. [разлика]"
Јака верзија јасно наводи намеру, пословна правила и границе АИ; Тако долазе корисни налази и област непозната моделу остаје јасна.
Проналажење типа
АИ поузданост
улога човека
Недостаје провера нуле/грешке
висока
Потврдите и примените
Читљивост/стил
висока
Изаберите по жељи
Једноставан безбедносни мирис
средње
Завршите, скенирајте возилом
Усклађеност са пословним правилима
ниско
То је потпуно људски.
Конкуренција/архитектура
ниско
Потребан је преглед стручњака
Преглед вештачке интелигенције није замена за људски преглед
Поставите АИ преглед као „први филтер“: јефтин, брз, неуморан прелиминарни пролаз. Овај филтер ослобађа пажњу рецензента од неважних детаља (простор, име) и усмерава је на места која заиста захтевају размишљање — пословно правило, архитектура, безбедносни резултат. Али одобрење спајања је потпис одговорне особе унутар тима. Независна провера од стране најмање једног компетентног инжењера је обавезна за промене које су критичне за безбедност.
Савет: Прочитајте листу налаза које АИ производи као „ствари које треба проверити“, а не као „да се уради“. Или проверите и примените сваку ставку или запишите у једној реченици зашто сте је положили; овај траг чини преглед подложним ревизији.
Уобичајене грешке
- То значи "АИ је погледао, чисто је". Ово је лажни осећај самопоуздања због лажних негатива.
- Не дајући контекст. Без сврхе и критеријума прихватљивости, модел производи само површне стилске интерпретације.
- Слепо примењивање лажних позитивних резултата. Поправљање сваког упозорења модела могло би да поквари покренути код.
- Питајући модел о пословном правилу. Модел не познаје правило; На човеку је да то провери.
- Не дискриминишите насиље. Стављање критичног безбедносног налаза и предлога имена у исту торбу засењује оно што је важно.
Укратко
АИ је неуморан први филтер у прегледу кода: добро хвата промашаје нулте/грешке, рубне случајеве и једноставне безбедносне мирисе; али је слаб у погледу недостатака који захтевају контекст, као што су пословна правила, архитектура и конкурентност, и производи и лажне позитивне и лажне негативне. Затражите налазе по категорији и озбиљности, филтрирајте сваки помоћу људске интелигенције, ручно верификујте критичне путање. Одобрење је увек потпис одговорног инжењера.
Задатак апликације
Изаберите прави или недавни ПР/разл. Прво, нека га АИ прегледа помоћу шаблона „објективно оријентисан, преглед категорије“. Ставите налазе у табелу и одлучите за сваки: тачно (верификовао сам), лажно позитивно (ево мог образложења) или да се примени. Затим идите у обилазак и покушајте да пронађете бар једну ствар (нарочито пословно правило или ивицу) која недостаје вештачкој интелигенцији и запишите је.
контролна листа
- [ ] Користим АИ преглед као први филтер, а не препоруку.
- [ ] Додајем сврху и критеријуме прихватања у упит за преглед.
- [ ] Одвајам налазе од буке по категоријама и снажно их желим.
- [ ] Свесно филтрирам сваки налаз да бих потврдио/лажно позитиван/применио.
- [ ] Као човек, проверавам пословна правила и усклађеност архитектуре.
- [ ] Захтевам одобрење од квалификованог инжењера за промене које су критичне за безбедност.