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

Прочитајте го барањето пред резимето

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

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

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

Следете го идентитетот до ресурсот

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

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

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

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

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

Прашајте кои докази би ја отфрлиле промената

Успешен тест може да користи тестен администратор или имитирана авторизација. Проверете дали ја испитува важната граница. Каде што е соодветно, додајте случај со друга организација и вистинска патека за авторизација.

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

За промена на зависност, проверете зошто е потребна. Прегледајте ги верзијата, лиценцата и безбедносните наоди. Не прифаќајте неповрзана надградба само затоа што агентот ја генерирал за време на задачата.

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

Втор модел може да открие корисни проблеми. Може и да ги повтори претпоставките од имплементацијата. Дајте му ги на рецензентот барањето и разликите во кодот. Не кажувајте му дека промената е веќе точна.

Барајте наодите да наведат конкретна патека до неуспех и релевантен код. Третирајте непоткрепени предупредувања како прашања за истражување. Третирајте уверено одобрување како уште едно мислење додека важните тврдења не добијат докази.

Човечкиот преглед останува одлука за одговорност. Рецензент треба доволно да ја разбира промената за да ги објасни однесувањето, ризиците и проверките. Ако разликите се премногу обемни, намалете го опфатот или поделете ја работата на промени што може да се прегледаат.

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

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

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

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