Vizsgálja át az AI által generált kódot

Az összefoglaló előtt olvassa el a követelményt

Kezdje a kért működéssel és az elfogadási feltételekkel. Ezután vizsgálja meg a tényleges diffet. Az agent összefoglalója segíthet eligazodni, de kihagyhat módosításokat vagy pontatlanul írhatja le az ellenőrzéseket.

Ellenőrizze a vizsgált ágat és commitot. Az alkalmazáskód mellett nézze meg a konfiguráció, a függőségek, az infrastruktúra és a tesztek változásait is. Egy kicsinek látszó funkció nagy jogosultsági vagy telepítési változást rejthet.

Először a legjelentősebb következményekkel járó működést vizsgálja meg. A formázás és az elnevezés számít, de ne vonja el a figyelmet a hiányzó adathatárról.

Kövesse az identitást az erőforrásig

Vizsgálja meg ezt a hiányos, fiktív endpointot. A példa review-problémát szemléltet; nem éles kód.

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

A függvény lekér egy hitelesített felhasználót. Nem mutatja meg a számlára vonatkozó jogosultsági döntést. A reviewernek meg kell vizsgálnia, hogy másik réteg érvényesíti-e ezt. A fel nem használt user érték indokolja a vizsgálatot, de önmagában nem bizonyít kihasználható hibát.

Kövesse végig a kérést a tényleges rendszerben. Azonosítsa a megbízható felhasználói és szervezeti identitást. Ellenőrizze, hogyan korlátozza a lekérdezés a kért rekordhoz való hozzáférést. Vizsgálja meg a hibakezelést és a tiltott kérések tesztjeit.

Ne feltételezze, hogy egy elrejtett gomb védi az API-t. A hívó a felület használata nélkül is küldhet kérést. Ne feltételezze, hogy egy érvényes rekordazonosító hozzáférést ad.

Kérdezze meg, milyen bizonyíték indokolná az elutasítást

Egy sikeres teszt használhat adminisztrátori tesztadatot vagy mockolt jogosultságkezelést. Ellenőrizze, hogy valóban a fontos határt vizsgálja-e. Szükség szerint adjon hozzá másik szervezettel és valódi jogosultság-ellenőrzési útvonallal futó esetet.

Felületmódosításnál vizsgálja meg a megjelenített eredményt. Ellenőrizze a billentyűzetes kezelést, az üres állapotokat, a betöltést és a hibákat. A típusellenőrzés nem bizonyítja, hogy egy párbeszédablak billentyűzettel használható.

Függőség módosításánál ellenőrizze, miért szükséges a változás. Vizsgálja meg a verziót, a licencet és a biztonsági találatokat. Ne fogadjon el a feladathoz nem kapcsolódó frissítést csak azért, mert az agent munka közben létrehozta.

Tartsa függetlenül a review-t

Egy második modell hasznos problémákat találhat. A megvalósítás feltételezéseit is megismételheti. A reviewernek a követelményt és a diffet adja át. Ne közölje vele előre, hogy a módosítás már helyes.

Kérje, hogy a találatok konkrét hibafolyamatot és az érintett kódot azonosítsák. A bizonyíték nélküli figyelmeztetéseket vizsgálandó kérdésként kezelje. A magabiztos jóváhagyást is csak véleménynek tekintse, amíg a fontos állításokat bizonyíték nem támasztja alá.

Az emberi review továbbra is felelősségi döntés. A reviewernek eléggé értenie kell a módosítást ahhoz, hogy elmagyarázza annak működését, kockázatait és ellenőrzését. Ha a diff túl nagy, szűkítse a hatókört, vagy bontsa áttekinthető módosításokra.

A végső verzión zárja le a review-t

Javítás után futtassa újra az érintett ellenőrzéseket. Vizsgálja meg, okoz-e a javítás új problémát. Győződjön meg arról, hogy az előírt review a repozitár szabályzata szerint a végső verzióra vonatkozik.

Az elfogadási döntést a működésre és a bizonyítékokra alapozva írja le. A fennmaradó korlátokat felelőssel és következő lépéssel együtt rögzítse. A megoldatlan problémából ne legyen olyan állítás, hogy minden ellenőrzés sikeres.

A code review gyakorlatban gyakorolja a hiányzó döntés felismerését, mielőtt valódi módosítást vizsgálna.