Kaip peržiūrėti DI sugeneruotą kodą

Norėdami peržiūrėti DI sugeneruotą kodą, pirmiausia pažiūrėkite, kas pasikeitė – kurie failai ir kodėl – tada patys išbandykite elgesį, prieš skaitydami bet kurią eilutę. Po to patikrinkite sritis, kuriose DI kodas dažniausiai klysta: trūkstami serverio pusės leidimų tikrinimai, paslaptys, prieinamos naršyklei, nepatikrinta įvestis, paketai ar funkcijos, kurių nėra, ir pakeitimai dalykų, kurių niekada neprašėte liesti.

DI rašo kodą, kuris paprastai veikia ir dažnai atrodo tvarkingas. Todėl jį lengva patvirtinti neatidžiai. Šis vadovas – peržiūros rutina, tinkanti tiek tam, kas sklandžiai skaito kodą, tiek tam, kas jo visai neskaito.

Peržiūros mastas pagal riziką

Ne kiekvienas pakeitimas reikalauja to paties dėmesio.

1 žingsnis: pamatykite, kas pasikeitė

Prieš vertindami kodą, gaukite pakeitimų sąrašą:

• Jei projektas yra Git, pažiūrėkite diff: failus ir eilutes, pakeistas nuo paskutinio commit. Žr. kaip naudoti Git su DI sukurta programėle.
• Arba paklauskite DI tiesiogiai:

Išvardyk kiekvieną failą, kurį pakeitei paskutinio pakeitimo metu, ir kiekvienam vienu sakiniu paaiškink, kas pasikeitė ir kodėl.

Įspėjamieji ženklai šiame etape: failai, nesusiję su užklausa, ištrinti failai, konfigūracijos ar priklausomybių pakeitimai, kurių neprašėte.

2 žingsnis: pirmiausia išbandykite elgesį

Kodo skaitymas parodo, ką jis turėtų daryti; testavimas parodo, ką jis daro. Prieš skaitydami:

• Išbandykite pakeitimą kaip įprastas naudotojas kompiuteryje ir telefono dydžio ekrane.
• Išbandykite su neteisinga įvestimi: tušti laukai, labai ilgas tekstas, neigiami skaičiai, data praeityje.
• Išbandykite atsijungę ir kaip kitas naudotojas.
• Pakartokite svarbiausius srautus: registracija, prisijungimas, pagrindinis veiksmas, mokėjimas.

Jei testavimas nepavyksta, sutaupėte skaitymo laiko – aiškiai praneškite apie problemą ir leiskite DI ją ištaisyti. Žr. kaip parašyti gerą klaidos ataskaitą.

3 žingsnis: patikrinkite leidimus serveryje

Svarbiausias dalykas. DI įrankiai dažnai paslepia mygtuką puslapyje, bet palieka serverį pasiruošusį atlikti veiksmą kiekvienam, kas paprašo.

Kiekvienam maršrutui ar funkcijai, kuri skaito ar keičia duomenis, klauskite:

• Ar tikrinama, kad naudotojas yra prisijungęs?
• Ar tikrinama, kad šis naudotojas gali pasiekti šį įrašą?
• Ar tas patikrinimas vyksta serveryje, o ne tik puslapyje?

Kiekvienam API maršrutui, kurį pridėjai ar pakeitei, nurodyk, kokį leidimų patikrinimą jis atlieka serveryje, pacituodamas eilutę. Pažymėk kiekvieną maršrutą be jo.

Tada išbandykite: prisijunkite kaip naudotojas A, įsiminkite įrašo ID, prisijunkite kaip naudotojas B ir jį užklauskite. DI sukurtų programėlių saugumo kontrolinis sąrašas aprašo visą testą.

4 žingsnis: ieškokite nutekėjusių paslapčių

• Ieškokite pakeistuose failuose bet ko, kas panašu į raktą ar slaptažodį.
• Patikrinkite, kad slaptieji raktai skaitomi iš aplinkos kintamųjų ir naudojami tik serverio kode.
• Stebėkite viešus priešdėlius, pavyzdžiui VITE_ ar NEXT_PUBLIC_, ant slaptų kintamųjų – jie įkeliami į naršyklės kodą.

Žr. kaip saugoti API raktus.

5 žingsnis: patikrinkite įvestis ir klaidas

• Patikra serveryje. Naršyklės tikrinimus galima apeiti. Privalomi laukai, ilgiai, formatai ir leidžiamos reikšmės turi būti tikrinami ir serveryje.
• Duomenų bazės užklausos naudoja parametrus, o ne tekstą, sujungtą iš naudotojo įvesties.
• Klaidos nenuryjamos. try/catch, kuris nieko nedaro, paslepia gedimus. Klaidos turi būti įrašomos, o naudotojas turi matyti paprastą pranešimą.
• Naudotojams nerodomos vidinės detalės – steko pėdsakai ir duomenų bazės klaidos priklauso žurnalams.

6 žingsnis: patikrinkite, ar tai tikra

DI modeliai kartais sukuria kodą, kuris atrodo teisingai, bet nurodo dalykus, kurių nėra.

• Paketai: kiekviena nauja priklausomybė turi būti tikras, prižiūrimas paketas tiksliai tokiu pavadinimu. Atsargiai su pavadinimais, panašiais į populiarių paketų rašybos klaidas.
• Funkcijos ir API parinktys: jei kodas kviečia bibliotekos funkciją ar išorinio API parinktį, kurios nesate matę, patikrinkite oficialią dokumentaciją.
• Vietos rezervavimo kodas: ieškokite TODO, mock, fake, įkoduotų pavyzdinių duomenų ar funkcijų, grąžinančių fiksuotą reikšmę.

Ar pridėjai naujų paketų? Kiekvienam nurodyk tikslų pavadinimą, kam jis skirtas ir ar galėtume be jo apsieiti.

7 žingsnis: patikrinkite, ar tinka

Kodas gali veikti ir vis tiek apsunkinti programėlės keitimą vėliau:

• Dubliavimas. Ta pati logika, nukopijuota į kelias vietas, nuo laiko nukryps.
• Nuoseklumas. Turėtų sekti modelius, kuriuos naudoja likusi programėlė.
• Dydis. 20 eilučių užklausa, sukūrusi 600 eilučių, nusipelno klausimo.
• Negyvas kodas. Senos versijos, paliktos šalia naujų.

Ar projekte yra kodo, kuris dabar nenaudojamas dėl šio pakeitimo, ar logikos, dubliuotos kitur? Nieko nekeisk; tiesiog išvardyk.

Dažnos klaidos

• Patvirtinimas, nes atrodo švariai. Tvarkingas kodas vis tiek gali praleisti leidimų tikrinimą.
• Skaitymas vietoj testavimo. Pirmiausia testuokite, po to skaitykite.
• Testuojamas tik sėkmingas kelias. Išbandykite blogą įvestį, kitą naudotoją ir atsijungusį.
• Nepastebėti nesusiję failų pakeitimai. Klauskite, kodėl pasikeitė kiekvienas failas.
• Visiškas pasitikėjimas savo peržiūra. Naudokite DI peržiūrą kaip pirmą patikrinimą ir patvirtinkite testu.
• Savaitės pakeitimų peržiūra vienu metu. Peržiūrėkite mažus pakeitimus, kai jie vyksta.

Kontrolinis sąrašas

• Žinau, kurie failai pasikeitė ir kodėl, ir nieko nesusijusio nepasikeitė.
• Pakeitimas veikia kompiuteryje ir telefone, su bloga įvestimi, atsijungus ir kaip kitas naudotojas.
• Kiekvienas duomenų maršrutas tikrina prisijungimą ir nuosavybę serveryje.
• Jokių paslapčių kode ar naršyklės paketuose.
• Įvestis tikrinama serveryje; užklausos naudoja parametrus.
• Klaidos įrašomos, nenuryjamos ir nerodomos naudotojams išsamiai.
• Nauji paketai yra tikri ir reikalingi; neliko išgalvotų funkcijų ar vietos rezervavimo kodo.
• Didelės rizikos pakeitimai buvo atidžiai perskaityti ir, jei reikia, peržiūrėti antro žmogaus.

Kodo peržiūra Mythex

• Klausimų režimas atsako į klausimus apie kodą jo nekeisdamas – idealus užklausoms „paaiškink kiekvieną pakeitimą“ ir „kuriems maršrutams trūksta leidimų tikrinimo“. Žr. Pokalbis.
• Kodo rodinys rodo failų medį, redaktorių ir terminalą visuose planuose (Free – tik skaitymui, Pro – redaguojamas), kad patys galėtumėte perskaityti, kas pasikeitė. Žr. Kodo redaktorius.
• /test agentas paspaudinėja peržiūrą kaip naudotojas ir praneša apie sugedusius srautus.
• Kontroliniai taškai leidžia atšaukti pakeitimą, kuris neišlaiko peržiūros.

Jei peržiūrą atlieka jums programuotojas, kaip dirbti su programuotoju DI sukurtoje programėlėje aprašo perdavimą; jei peržiūra atskleidžia klaidą, žr. kaip derinti DI sukurtą programėlę.

Klausimai