Hogyan nézd át a mesterséges intelligencia által generált kódot

Az MI által generált kód átnézéséhez kezdd azzal, mi változott – mely fájlok és miért –, majd tesztelj magad a viselkedésre, mielőtt bármelyik kódsort elolvasnád. Ezután ellenőrizd azokat a területeket, ahol az AI-kód a leggyakrabban hibázik: hiányzó szerveroldali jogosultság-ellenőrzések, a böngészőnek kitett titkok, nem validált bemenetek, nem létező csomagok vagy függvények, és olyan módosítások, amelyekhez soha nem kérted hozzá nyúlni.

Az AI olyan kódot ír, amely általában lefut, és gyakran rendezettnek tűnik. Emiatt könnyű anélkül jóváhagyni, hogy valóban ellenőriznéd. Ez az útmutató egy átnézési rutin, amely akkor is működik, ha folyékonyan olvasol kódot, és akkor is, ha egyáltalán nem.

Igazítsd az átnézést a kockázathoz

Nem minden változtatás igényel ugyanolyan figyelmet.

1. lépés: Lásd, mi változott

Mielőtt megítélnéd a kódot, szerezd meg a változások listáját:

• Ha a projekt Gitben van, nézd meg a diff-et: az utolsó commit óta változott fájlokat és sorokat. Lásd: hogyan használd a Gitet AI-val épített alkalmazással.
• Vagy kérdezd meg közvetlenül az AI-t:

Sorold fel az összes fájlt, amelyet az utolsó változtatásban módosítottál, és fájlonként egy mondatban magyarázd el, mi változott és miért.

Piros zászlók ezen a szinten: a kéréshez nem kapcsolódó fájlok, törölt fájlok, olyan konfiguráció- vagy függőségváltozások, amelyeket nem kértél.

2. lépés: Teszteld először a viselkedést

A kód olvasása megmondja, mit kellene csinálnia; a tesztelés megmondja, mit csinál valójában. Mielőtt olvasnál:

• Próbáld ki a változtatást normál felhasználóként, asztali gépen és telefonméretű képernyőn.
• Próbáld ki hibás bemenettel: üres mezők, nagyon hosszú szöveg, negatív számok, múltbeli dátum.
• Próbáld ki kijelentkezve, és másik felhasználóként.
• Futtasd újra a legfontosabb folyamatokat: regisztráció, bejelentkezés, a fő művelet, fizetés.

Ha a teszt megbukik, időt spóroltál a kód olvasásával – jelezd világosan, és hagyd, hogy az AI javítsa. Lásd: hogyan írj jó hibajelentést.

3. lépés: Ellenőrizd a jogosultságokat a szerveren

Ez a legfontosabb ellenőrizendő dolog. Az AI-eszközök gyakran elrejtenek egy gombot az oldalon, de a szerver továbbra is hajlandó végrehajtani a műveletet bárkinek, aki kéri.

Minden olyan útvonalhoz vagy függvényhez, amely adatot olvas vagy módosít, kérdezd meg:

• Ellenőrzi-e, hogy a felhasználó be van-e jelentkezve?
• Ellenőrzi-e, hogy ez a felhasználó hozzáférhet-e ehhez a rekordhoz?
• Ez az ellenőrzés a szerveren van, nem csak az oldalon?

Minden hozzáadott vagy módosított API-útvonalhoz mondd meg, milyen jogosultság-ellenőrzést végez a szerveren, idézd a megfelelő sort. Jelöld meg azt az útvonalat, amelyiknek nincs ilyen.

Ezután teszteld: jelentkezz be az A felhasználóként, jegyezd fel egy rekord azonosítóját, majd jelentkezz be a B felhasználóként, és kérd le azt. A teljes tesztet a biztonsági ellenőrzőlista az AI-val épített alkalmazásokhoz tartalmazza.

4. lépés: Keress kiszivárgott titkokat

• Keress a változott fájlokban mindent, ami kulcsnak vagy jelszónak néz ki.
• Ellenőrizd, hogy a titkos kulcsok környezeti változókból olvasódnak-e, és csak szerverkódban használódnak-e.
• Figyelj a nyilvános előtagokra, például VITE_ vagy NEXT_PUBLIC_ előtagra a titkos változókon – ezek bekerülnek a böngészőkódba.

Lásd: hogyan őrizd meg biztonságban az API-kulcsaidat.

5. lépés: Ellenőrizd a bemenetet és a hibákat

• Validálás a szerveren. A böngészős ellenőrzések átugorhatók. A kötelező mezőket, a hosszúságokat, a formátumokat és az engedélyezett értékeket a szervernek is ellenőriznie kell.
• Az adatbázis-lekérdezések paramétereket használnak, nem olyan szöveget, amely a felhasználói bemenetet egy lekérdezésbe illeszti.
• A hibák nem vesznek el csendben. Egy üres try/catch elrejti a hibákat. A hibákat naplózni kell, a felhasználók pedig egyszerű üzenetet lássanak.
• Nincsenek belső részletek a felhasználóknak – a veremkövetések és az adatbázis-hibák a naplókba valók.

6. lépés: Ellenőrizd, hogy valódi-e

Az AI-modellek néha olyan kódot írnak, amely jónak látszik, de nem létező dolgokra hivatkozik.

• Csomagok: minden új függőség legyen valódi, karbantartott csomag pontosan ezzel a névvel. Legyél óvatos a népszerű csomagok elírásaira emlékeztető nevekkel.
• Függvények és API-opciók: ha a kód olyan könyvtári függvényt vagy külső API-opciót hív, amelyet még sosem láttál, nézd meg a hivatalos dokumentációt.
• Helyőrző kód: keress TODO, mock, fake, beégetett mintaadatokat vagy fix értéket visszaadó függvényeket.

Adtál hozzá új csomagokat? Mindegyiknél add meg a pontos nevet, hogy mire való, és hogy el tudnánk-e hagyni.

7. lépés: Ellenőrizd, hogy illeszkedik-e

A kód működhet, és mégis nehezebbé teheti az alkalmazás későbbi módosítását:

• Duplikáció. Ugyanaz a logika több helyre másolva eltér egymástól.
• Következetesség. Kövesse azokat a mintákat, amelyeket az alkalmazás többi része használ.
• Méret. Egy 20 soros kérés, amelyből 600 sor lett, kérdést érdemel.
• Holt kód. Régi verziók, amelyek az újak mellett maradtak.

Van-e a projektben olyan kód, amely a változtatás miatt már nem használt, vagy máshol duplikált logika? Ne változtass semmin, csak sorold fel.

Gyakori hibák

• Jóváhagyás csak azért, mert tisztának tűnik. A szép kód is kihagyhat jogosultság-ellenőrzést.
• Olvasás tesztelés helyett. Először teszteld, utána olvasd.
• Csak a boldog útvonal tesztelése. Próbálj hibás bemenetet, rossz felhasználót és kijelentkezett állapotot.
• A nem kapcsolódó fájlváltozások figyelmen kívül hagyása. Kérdezd meg, miért változott minden fájl.
• Az önátnézésnek teljes bizalom. Az AI átnézését első körként használd, és teszteléssel erősítsd meg.
• Egy hét változtatásának egyszerre átnézése. A kis változtatásokat azonnal nézd át.

Ellenőrzőlista

• Tudom, mely fájlok változtak és miért, és nem változott semmi nem kapcsolódó.
• A változtatás működik asztali gépen és telefonon, hibás bemenettel, kijelentkezve és másik felhasználóként.
• Minden adatútvonal ellenőrzi a bejelentkezést és a tulajdonjogot a szerveren.
• Nincsenek titkok a kódban vagy a böngészőcsomagokban.
• A bemenet a szerveren validált; a lekérdezések paramétereket használnak.
• A hibák naplózva vannak, nem vesznek el csendben, és nem jelennek meg részletesen a felhasználóknak.
• Az új csomagok valódiak és szükségesek; nem maradt kitalált függvény vagy helyőrző.
• A magas kockázatú változtatásokat alaposan átolvasták, és szükség esetén egy második átnéző is átnézte.

Kódátnézés a Mythexen

• Az Ask mode a kódról szóló kérdésekre válaszol anélkül, hogy szerkesztene – ideális olyan kérésekhez, mint „magyarázd el minden változtatást” vagy „mely útvonalakról hiányzik a jogosultság-ellenőrzés”. Lásd: Chat.
• A Code view minden csomagon megmutatja a fájlfát, a szerkesztőt és a terminált (Free csomagon csak olvasható, Pro csomagon szerkeszthető), így magad olvashatod el, mi változott. Lásd: Code editor.
• A /test az ügynökkel végigkattintatja az előnézetet felhasználóként, és jelenti a hibás folyamatokat.
• A Checkpoints lehetővé teszik, hogy visszavond azt a változtatást, amely nem megy át az átnézésen.

Ha fejlesztő nézi át helyetted, a hogyan dolgozz fejlesztővel AI-val épített alkalmazáson útmutató az átadást fedi le; ha az átnézés hibát talál, lásd: hogyan hibakeresd az AI-val épített alkalmazást.

Kérdések