Tarkasta AI:n generoima koodi

Lue vaatimus ennen yhteenvetoa

Aloita pyydetystä toiminnasta ja hyväksymiskriteereistä. Tarkasta sitten varsinainen diff. Agentin yhteenveto auttaa suunnistamaan, mutta siitä voi puuttua muutoksia tai se voi kuvata tarkistukset väärin.

Varmista tarkasteltava branch ja commit. Katso sovelluskoodin lisäksi konfiguraatio-, riippuvuus-, infrastruktuuri- ja testimuutokset. Pieni näkyvä ominaisuus voi sisältää suuren muutoksen käyttöoikeuksiin tai julkaisemiseen.

Tarkasta ensin toiminta, jonka virheillä on suurimmat seuraukset. Muotoilu ja nimeäminen ovat tärkeitä, mutta ne eivät saa viedä huomiota puuttuvalta tietorajalta.

Seuraa identiteetti resurssille asti

Tarkastellaan puutteellista, kuvitteellista endpointia. Esimerkki havainnollistaa tarkastustilannetta eikä ole tuotantokoodia.

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

Funktio hakee tunnistetun käyttäjän. Se ei näytä laskua koskevaa authorization-päätöstä. Tarkastajan pitää selvittää, valvooko jokin toinen kerros sitä. Käyttämätön user-arvo on syy tutkia, ei yksin todiste hyödynnettävästä haavoittuvuudesta.

Seuraa pyyntö todellisen järjestelmän läpi. Tunnista luotettu käyttäjä ja organisaatio. Miten query rajaa pääsyn pyydettyyn tietueeseen? Tarkasta virhetilanteet ja kiellettyjen pyyntöjen testit.

Piilotettu painike ei suojaa API:a. Kutsuja voi tehdä pyynnön ilman käyttöliittymää. Kelvollinen tietuetunnistekaan ei anna käyttöoikeutta.

Etsi näyttö, joka voisi hylätä muutoksen

Onnistunut testi voi käyttää admin-fixturea tai mockata authorizationin. Selvitä, kulkeeko testi olennaisen rajan kautta. Lisää tarvittaessa toisen organisaation tapaus todellisella authorization-polulla.

Käyttöliittymämuutos pitää katsoa renderöitynä. Tarkista näppäimistökäyttö, tyhjät tilat, lataus ja virheet. Type check ei osoita dialogin toimivan näppäimistöllä.

Riippuvuusmuutoksessa selvitä tarve. Tarkasta versio, lisenssi ja tietoturvahavainnot. Älä hyväksy asiaan liittymätöntä päivitystä vain siksi, että agentti teki sen tehtävän aikana.

Pidä tarkastus riippumattomana

Toinen malli voi löytää hyödyllisiä ongelmia. Se voi myös toistaa toteutuksen oletukset. Anna tarkastajalle vaatimus ja diff. Älä kehystä muutosta valmiiksi oikeaksi.

Pyydä havainnoille konkreettinen virhepolku ja siihen liittyvä koodi. Perusteettomat varoitukset ovat selvitettäviä kysymyksiä. Vakuuttava hyväksyntäkin on mielipide, kunnes olennaisille väitteille on näyttöä.

Ihmisen review on edelleen vastuupäätös. Tarkastajan pitää ymmärtää muutos niin, että hän osaa selittää toiminnan, riskit ja tarkistukset. Jos diff on liian suuri, rajaa sitä tai jaa työ tarkastettaviin muutoksiin.

Päätä review lopullisen version perusteella

Aja korjauksen jälkeen siihen liittyvät tarkistukset uudelleen. Katso, syntyikö korjauksesta uusi ongelma. Varmista, että vaadittu review koskee lopullista versiota repositorion käytännön mukaisesti.

Kirjaa hyväksyntä toiminnan ja näytön kautta. Nimeä jäljelle jäävälle rajoitukselle omistaja ja seuraava toimi. Älä muuta avointa kysymystä väitteeksi kaikkien tarkistusten onnistumisesta.

Harjoittele puuttuvan päätöksen tunnistamista code review -harjoituksessa ennen oikean muutoksen tarkastusta.