Преглеждайте код, генериран с AI

Прочетете изискването преди обобщението

Започнете с поисканото поведение и критериите за приемане. След това прегледайте действителния diff. Обобщението на агента може да помогне да се ориентирате, но може да пропусне промени или да опише проверките неточно.

Потвърдете кой клон и commit преглеждате. Освен кода на приложението проверете и промените в конфигурацията, зависимостите, инфраструктурата и тестовете. Малка видима функционалност може да включва голяма промяна в правата или поведението при внедряване.

Първо прегледайте поведението с най-големи последствия. Форматирането и имената са важни, но не трябва да отвличат вниманието от липсваща граница на данните.

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

Разгледайте този непълен, измислен endpoint. Примерът илюстрира проблем при преглед; не е код за продукционна среда.

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

Функцията получава удостоверен потребител. Тя не показва решение за правото на достъп до фактурата. Проверяващият трябва да установи дали друг слой прилага това решение. Неизползваната стойност user е причина за проучване, но сама по себе си не доказва дефект, който може да бъде използван за атака.

Проследете заявката през действителната система. Определете доверените потребител и организация. Проверете как заявката към данните ограничава достъпа до поискания запис. Прегледайте поведението при грешка и тестовете за забранени заявки.

Не приемайте, че скрит бутон защитава API. Извикващ код може да изпрати заявка, без да използва интерфейса. Не приемайте, че валиден идентификатор на запис дава достъп.

Попитайте какви доказателства биха отхвърлили промяната

Успешен тест може да използва администраторски тестов потребител или mock за проверката на правата. Проверете дали тества съществената граница на достъпа. Добавете случай с различна организация и действителен път за проверка на правата, когато е подходящо.

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

За промяна в зависимост проверете защо е нужна. Прегледайте версията, лиценза и констатациите за сигурността. Не приемайте несвързано обновяване само защото агентът го е генерирал по време на задачата.

Запазете независимостта на прегледа

Втори модел може да открие полезни проблеми. Може и да повтори предположенията на реализацията. Дайте на проверяващия изискването и diff-а. Избягвайте да му казвате, че промяната вече е правилна.

Изисквайте констатациите да посочват конкретен път до неуспех и съответния код. Разглеждайте неподкрепените предупреждения като въпроси за проучване. Разглеждайте увереното одобрение като още едно мнение, докато важните твърдения получат доказателства.

Човешкият преглед остава решение за отговорността. Проверяващият трябва да разбира достатъчно от промяната, за да обясни поведението, рисковете и проверките ѝ. Ако diff-ът е твърде голям, намалете обхвата или го разделете на промени, които могат да се прегледат.

Завършете прегледа върху окончателната версия

След поправка изпълнете отново засегнатите проверки. Прегледайте дали поправката създава нов проблем. Уверете се, че задължителният преглед се отнася за окончателната версия според политиката на хранилището.

Опишете решението за приемане чрез поведение и доказателства. Запишете всяко оставащо ограничение с отговорник и следващо действие. Не превръщайте нерешен проблем в твърдение, че всички проверки са преминали успешно.

Използвайте упражнението за преглед на код, за да се упражните в откриване на липсващото решение, преди да преглеждате реална промяна.