Peržiūrėkite DI sugeneruotą kodą

Perskaitykite reikalavimą prieš santrauką

Pradėkite nuo prašomo veikimo ir priėmimo kriterijų. Tada išnagrinėkite tikrąjį diff. Agento santrauka gali padėti susiorientuoti, bet joje gali trūkti pakeitimų ar būti netiksliai aprašyti patikrinimai.

Patvirtinkite peržiūrimą šaką ir commit. Tikrinkite ne tik programos kodą, bet ir konfigūracijos, priklausomybių, infrastruktūros bei testų pakeitimus. Nedidelė matoma funkcija gali apimti didelį teisių ar diegimo veikimo pakeitimą.

Pirmiausia peržiūrėkite veikimą, galintį turėti rimčiausių pasekmių. Formatavimas ir pavadinimai svarbūs, bet jie neturi nukreipti dėmesio nuo trūkstamos duomenų ribos.

Atsekite tapatybę iki ištekliaus

Apsvarstykite šį nepilną išgalvotą API adresą. Pavyzdys iliustruoja peržiūros problemą; tai nėra produkcinis kodas.

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

Funkcija gauna autentifikuotą naudotoją. Ji nerodo autorizavimo sprendimo dėl sąskaitos faktūros. Peržiūrėtojas turi ištirti, ar šį sprendimą užtikrina kitas sluoksnis. Nenaudojama naudotojo reikšmė yra priežastis tirti, o ne savaiminis įrodymas, kad klaida galima pasinaudoti.

Atsekite užklausą per tikrąją sistemą. Nustatykite patikimą naudotojo ir organizacijos tapatybę. Patikrinkite, kaip užklausa riboja prieigą prie prašomo įrašo. Išnagrinėkite klaidų tvarkymą ir draudžiamų užklausų testus.

Nemanykite, kad paslėptas mygtukas apsaugo API. Užklausą galima išsiųsti nesinaudojant sąsaja. Nemanykite, kad tinkamas įrašo ID suteikia prieigą.

Paklauskite, kokie įrodymai leistų atmesti pakeitimą

Sėkmingas testas gali naudoti administratoriaus testinius duomenis ar imituotą autorizavimą. Patikrinkite, ar jis išbando svarbią ribą. Kur tinkama, pridėkite atvejį su kita organizacija ir tikru autorizavimo keliu.

Keisdami naudotojo sąsają, išnagrinėkite atvaizduotą rezultatą. Patikrinkite valdymą klaviatūra, tuščias būsenas, įkėlimą ir klaidas. Tipų patikrinimas negali įrodyti, kad dialogo langą galima valdyti klaviatūra.

Keisdami priklausomybę, patikrinkite, kodėl jos reikia. Peržiūrėkite versiją, licenciją ir saugumo radinius. Nepriimkite nesusijusio atnaujinimo vien todėl, kad agentas jį sugeneravo vykdydamas užduotį.

Išlaikykite peržiūros nepriklausomumą

Antras modelis gali rasti naudingų problemų. Jis taip pat gali pakartoti įgyvendinimo prielaidas. Peržiūrėtojui pateikite reikalavimą ir diff. Nesakykite jam, kad pakeitimas jau teisingas.

Reikalaukite, kad radiniai nurodytų konkretų gedimo kelią ir susijusį kodą. Nepagrįstus įspėjimus vertinkite kaip klausimus, kuriuos reikia ištirti. Užtikrintą pritarimą laikykite dar viena nuomone, kol svarbūs teiginiai neturi įrodymų.

Žmogaus peržiūra išlieka atsakomybės sprendimu. Peržiūrėtojas turi pakankamai suprasti pakeitimą, kad paaiškintų jo veikimą, riziką ir patikrinimą. Jei diff per didelis, sumažinkite apimtį arba padalykite darbą į peržiūrimus pakeitimus.

Užbaikite galutinės versijos peržiūrą

Po pataisos pakartokite paveiktus patikrinimus. Ištirkite, ar pataisa nesukuria naujos problemos. Užtikrinkite, kad pagal kodo saugyklos taisykles privaloma peržiūra būtų atlikta galutinei versijai.

Sprendimą priimti pakeitimą pagrįskite veikimu ir įrodymais. Kiekvienam likusiam apribojimui nurodykite atsakingą asmenį ir kitą veiksmą. Neišspręstos problemos nepaverskite teiginiu, kad visi patikrinimai sėkmingi.

Atlikite kodo peržiūros pratimą ir pasimokykite nustatyti trūkstamą sprendimą prieš nagrinėdami tikrą pakeitimą.