Review AI-gegenereerde code

Lees de eis vóór de samenvatting

Begin met het gevraagde gedrag en de acceptatiecriteria. Inspecteer daarna de werkelijke diff. De samenvatting van een agent kan helpen navigeren, maar kan wijzigingen weglaten of controles onnauwkeurig beschrijven.

Bevestig de branch en commit die u reviewt. Controleer naast applicatiecode ook wijzigingen in configuratie, dependencies, infrastructuur en tests. Een kleine zichtbare functie kan een grote wijziging in rechten of deploymentgedrag bevatten.

Review eerst het gedrag met de grootste gevolgen. Opmaak en naamgeving zijn belangrijk, maar mogen niet afleiden van een ontbrekende gegevensgrens.

Volg de identiteit tot de resource

Neem dit onvolledige, fictieve endpoint. Het voorbeeld illustreert een reviewprobleem; het is geen productiecode.

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

De functie verkrijgt een geauthenticeerde gebruiker. Ze toont geen autorisatiebesluit voor de factuur. Een reviewer moet inspecteren of een andere laag dat besluit afdwingt. De ongebruikte user-waarde is een reden voor onderzoek, op zichzelf geen bewijs van een uit te buiten defect.

Volg het verzoek door het werkelijke systeem. Identificeer de vertrouwde gebruiker en organisatie. Controleer hoe de query toegang tot het gevraagde record beperkt. Inspecteer foutgedrag en tests voor verboden verzoeken.

Neem niet aan dat een verborgen knop de API beschermt. Een aanroeper kan een verzoek versturen zonder de interface te gebruiken. Neem niet aan dat een geldig record-ID toegang geeft.

Vraag welk bewijs de wijziging kan afwijzen

Een geslaagde test kan administratortestdata gebruiken of autorisatie mocken. Controleer of de test de relevante grens raakt. Voeg waar passend een geval met een andere organisatie en een werkelijk autorisatiepad toe.

Inspecteer bij een interfacewijziging het gerenderde resultaat. Controleer toetsenbordbediening, lege toestanden, laadgedrag en fouten. Een typecheck kan niet aantonen dat een dialoog met het toetsenbord bruikbaar is.

Verifieer bij een dependencywijziging waarom die nodig is. Review versie, licentie en beveiligingsbevindingen. Accepteer geen niet-gerelateerde upgrade alleen omdat de agent die tijdens de taak heeft gegenereerd.

Houd review onafhankelijk

Een tweede model kan nuttige problemen vinden. Het kan ook aannames uit de implementatie herhalen. Geef een reviewer de eis en diff. Vertel niet vooraf dat de wijziging al correct is.

Vereis dat bevindingen een concreet foutpad en de relevante code aanwijzen. Behandel ongefundeerde waarschuwingen als onderzoeksvragen. Behandel zelfverzekerde goedkeuring als een andere mening totdat belangrijke beweringen bewijs hebben.

Menselijke review blijft een besluit over verantwoordelijkheid. Een reviewer moet voldoende van de wijziging begrijpen om gedrag, risico’s en verificatie uit te leggen. Verklein de scope of verdeel de wijziging in reviewbare delen als de diff te groot is.

Sluit de review af op de laatste revisie

Voer na een correctie de betrokken controles opnieuw uit. Inspecteer of de correctie een nieuw probleem veroorzaakt. Zorg dat de verplichte review volgens het repositorybeleid op de laatste revisie van toepassing is.

Schrijf het acceptatiebesluit in termen van gedrag en bewijs. Leg elke resterende beperking vast met een verantwoordelijke en volgende actie. Verander een onopgelost probleem niet in de bewering dat alle controles zijn geslaagd.

Gebruik de codereviewoefening om het ontbrekende besluit te leren herkennen voordat u een echte wijziging onderzoekt.