Прегледајте код који је генерисао AI

Прочитајте захтев пре сажетка

Почните од траженог понашања и критеријума прихватања. Затим испитајте стварни diff. Сажетак агента може да вам помогне да се снађете, али може и да изостави промене или нетачно опише провере.

Потврдите грану и commit који прегледате. Поред кода апликације проверите и промене конфигурације, зависности, инфраструктуре и тестова. Мала видљива функција може да садржи велику промену дозвола или понашања при постављању у окружење.

Прво прегледајте понашање са највећим последицама. Форматирање и именовање јесу важни, али не смеју да одвуку пажњу од границе података која недостаје.

Пратите идентитет до ресурса

Размотримо овај непотпун, измишљен endpoint. Пример илуструје проблем при прегледу; није продукциони код.

async function getInvoice(request) {
  const user = await requireSignedInUser(request);
  return database.invoice.findById(request.params.id);
}

Функција прибавља аутентификованог корисника. Не приказује одлуку о ауторизацији за фактуру. Особа која прегледа код мора да испита да ли други слој спроводи ту одлуку. Некоришћена вредност корисника разлог је за истраживање, а не сама по себи доказ грешке која може да се искористи.

Пратите захтев кроз стварни систем. Утврдите корисника и организацију на основу поузданих података о идентитету. Проверите како упит ограничава приступ траженом запису. Испитајте понашање при грешци и тестове забрањених захтева.

Не претпостављајте да скривено дугме штити API. Позивалац може да пошаље захтев без коришћења интерфејса. Не претпостављајте да важећи ID записа даје право приступа.

Питајте који би докази могли да одбаце промену

Тест који пролази можда користи припремљеног администраторског корисника или mock ауторизацију. Проверите да ли испитује важну границу. Где је прикладно, додајте случај са другом организацијом и стварном путањом ауторизације.

За промену корисничког интерфејса испитајте приказани резултат. Проверите рад тастатуром, празна стања, понашање при учитавању и грешке. Провера типова не може да докаже да је дијалог употребљив тастатуром.

За промену зависности проверите зашто је потребна. Прегледајте верзију, лиценцу и безбедносне налазе. Не прихватајте неповезану надоградњу само зато што ју је агент генерисао током задатка.

Обезбедите независан преглед

Други модел може да открије корисне проблеме. Може и да понови претпоставке из имплементације. Особи или моделу који прегледа промену дајте захтев и diff. Немојте унапред говорити да је промена већ исправна.

Захтевајте да налази наведу конкретну путању отказа и релевантан код. Непоткрепљена упозорења третирајте као питања за истраживање. Уверено одобрење третирајте као још једно мишљење док важне тврдње не добију доказе.

Људски преглед остаје одлука о одговорности. Особа која прегледа промену треба да је довољно разуме да објасни понашање, ризике и проверу. Ако је diff превелик, смањите опсег или га поделите на промене погодне за преглед.

Завршите преглед на коначној ревизији

После исправке поново покрените погођене провере. Испитајте да ли исправка ствара нов проблем. Обезбедите да се захтевани преглед, према политици репозиторијума, односи на коначну ревизију.

Напишите одлуку о прихватању кроз понашање и доказе. Забележите свако преостало ограничење, одговорну особу и следећу радњу. Не претварајте нерешен проблем у тврдњу да су све провере прошле.

Користите вежбу прегледа кода да увежбате препознавање одлуке која недостаје пре испитивања стварне промене.