Programuotojas paprašo asistento funkcijos, kuri patikrintų, ar vartotojas gali atsisiųsti ataskaitą. Kodas kompiliuojamas. „Happy Path“ testas sėkmingas. Užklausa atrodo tvarkinga. Po dviejų savaičių kolega pastebi, kad funkcija tikrina, ar vartotojas yra prisijungęs, bet niekada netikrina, ar ataskaita priklauso jam.
Tai iliustracinis scenarijus, o ne dokumentuotas incidentas. Jame aprašoma spraga, kurią turi užpildyti dirbtinio intelekto sugeneruoto kodo peržiūros mokymai: sugeneruotas kodas, kuris praeina pagrindinį patikrinimą, vis tiek gali turėti autorizacijos ar lygiagretumo trūkumą, ir jį peržiūrintis asmuo turi jį rasti ir paaiškinti, kodėl tai svarbu.
Šis vadovas skirtas inžinerijos įgūdžių lavinimo vadovams ir inžinerijos vadybininkams. Jame aprašoma, kaip aprašyti našumo problemą, diagnozuoti spragas, parengti projektą ir jį taikyti praktikoje, išnagrinėti atvejį ir įvertinti, ar įgūdžiai pritaikomi realiose peržiūrose. Jame kalbama apie mokymo projektavimą. Kiekvieną jūsų programos defektą, testą ir peržiūros taisyklę turėtų patvirtinti vyresnieji inžinieriai ir jūsų saugumo komanda.
Kas yra dirbtinio intelekto sugeneruoto kodo peržiūros mokymai?
Dirbtinio intelekto sugeneruoto kodo peržiūros mokymai moko kūrėjus aiškiai pateikti asistentui instrukcijas, o tada įvertinti ir audituoti atsakymus: ar jie teisingi, ar saugūs, ar veikia esant vienalaikiam apkrovimui, ar pakankamai efektyvūs? Tai nėra kursai apie konkretų įrankį. Jie lavina peržiūros įprotį, kuris išlieka toks pat, kai įrankis pasikeičia.
Greiti faktai
| klausimas | Trumpas atsakymas |
|---|---|
| Kokia užduotis? | Patikrinkite sugeneruotą kodą ir pagrįskite kiekvieną riziką testu. |
| Ką skaičiuoji? | Patikros kokybė ir ar buvo rasti atitinkami defektai. |
| Ar pakanka viktorinos apie saugaus kodavimo taisykles? | Ne. Tai patvirtina prielaidas, bet ne tai, ar kūrėjas gali pastebėti kode esantį trūkumą, kuris atrodo tikėtinas. |
| Kas patvirtina turinį? | Inžinerijos vadovas ir jūsų apsaugos komanda. |
| Ko negali išspręsti treniruotės? | Peržiūros laikas, įrankiai, neaiškūs savininkai ir spaudimas greitai susijungti. |
| Iš kur žinai, kad suveikė? | Naujas, nematomas kodo pratimas, vertinamas pagal sutartus kriterijus, o po realių peržiūrų – stebimas tolesnis darbas. |
1. Aprašykite našumo problemą
Pradėkite nuo užduoties: audituokite sugeneruotą kodą ir pagrįskite riziką testais. Auditas – tai skaitymas su įtarimu. Pagrįsti – tai įtarimo pavertimas įrodymu, dažniausiai testu, kuris nepavyksta, arba atkūrimu, rodančiu trūkumą.
Tyrimas rodo, kodėl tam reikia sąmoningo praktikavimo. „GitHub Copilot“ tyrime Pearce'as ir jo kolegos sukūrė 1,689 programas pagal 89 scenarijus, pasirinktus pagal žinomus silpnųjų vietų tipus, ir nustatė, kad apie 40 procentų jų buvo pažeidžiamos (Pearce ir kolegos, 2021). Tai buvo ankstyvas įrankis ir konkretus scenarijų rinkinys, todėl šio skaičiaus nevertinkite kaip šiandieninių asistentų rodiklio. Atskirame vartotojų tyrime dalyvių buvo paprašyta rašyti kodą su dirbtinio intelekto asistentu ir be jo. Tie, kurie naudojo asistentą, rašė žymiai mažiau saugaus kodo ir buvo labiau linkę manyti, kad jų kodas yra saugus (Perry ir kolegos, 2023 m.). Tame pačiame tyrime nustatyta, kad dalyviai, kurie mažiau pasitikėjo asistentu ir labiau įsitraukė į jo užduotis, mažiau jautėsi pažeidžiami.
Toliau pateikiamos dvi pamokos apie mokymo dizainą. Tikėtinam rezultatui reikalingas aktyvus recenzentas. O pasitikėjimas nėra įrodymas, todėl pratimo metu reikia klausti apie testą, o ne nuomonę.
Parašykite našumo teiginį vienu sakiniu ir paprašykite inžinerijos vadovo jį patikrinti: „Atsižvelgiant į sugeneruotą pakeitimą, kūrėjas išvardija saugumo, lygiagretumo ir efektyvumo rizikas, kurias jis mato, ir kiekvienai iš jų aprašo arba parašo testą, kuris tai parodytų.“
2. Nustatykite mokymosi ir konteksto spragas
Prieš ką nors kurdami, palyginkite užduotį su tuo, ką praktikuoja ir vertina jūsų dabartinė programa. Trys klausimai paprastai skiria mokymo spragą nuo kažko kito:
- Ar dabartinė praktika naudoja tikrąją užduotį? Jei mokymai apima teksto rašymą, bet niekada neprašoma kūrėjų peržiūrėti rezultato, niekas nėra praktikavęs audito. Jei vertinimas yra saugaus kodavimo taisyklių testas su pasirenkamaisiais atsakymais, jis matuoja įsiminimą.
- Koks yra kognityvinis poreikis? Pagal atnaujintą Bloomo taksonomiją, kodo saugumo vertinimas ir jį įrodančio testo pasirinkimas patenka į analizės ir vertinimo lygius, o geresnės užklausos ar pataisymo kūrimas pasiekia kūrimo lygį. Veiklų priskyrimas šiems lygiams aprašytas mūsų vadove. mokymosi veiklų derinimas su Bloomo taksonomija.
- Ar kliūčių kelia kažkas kita, o ne įgūdžiai? Patikrinkite peržiūros laiką, įrankius ir nuosavybę. Jei recenzentai turi penkias minutes vienai užklausai, be mokymų auditas nebus atliktas. Jei nėra statinės analizės ar testavimo rinkinio, kūrėjas gali rasti riziką, bet jos nepagrindti. Praneškite apie priežastis, nesusijusias su mokymais, žmonėms, kurie gali jas išspręsti.
3. Dizaino parengimas ir praktika
Kai žinosite, kurias spragas mokymai gali užpildyti, kiekvienam etapui paskirkite atskirą užduotį.
Paruošimas. Patikrinkite privalomuosius testus atlikdami trumpą diagnostiką: nurodykite dažniausiai pasitaikančias jūsų testų rinkinio silpnąsias vietas, kaip struktūrizuoti jūsų testai, jūsų komandos naudojamą peržiūros kontrolinį sąrašą. Šiam etapui tinka savarankiškas mokymasis. Prisiminimo patikrinimas patvirtina tik privalomuosius testus.
Praktika. Naudokite audito pratimus, sudarytus iš realistiškai sugeneruoto kodo. Kiekvienam pratimui pridėkite nedidelį skaičių skirtingų rūšių defektų, pavyzdžiui, trūkstamą nuosavybės patikrinimą, lenktynes tarp dviejų užklausų ir neefektyvų ciklą, bei šiek tiek tinkamo kodo. Kūrėjas peržiūri, įvardija kiekvieną riziką, nurodo jos rimtumą ir pasiūlo testą, kuris ją parodytų. Prašykite argumentų, o ne eilučių numerių sąrašo.
Atsiliepimai. Susiekite tai su sprendimais, o ne su bendru balu. „Bendrame skaitiklyje pažymėjote ciklą, bet ne lenktynes, ir jūsų testas nebūtų to aptikęs, nes užklausos vykdomos po vieną“ yra naudingiau nei „Rasta 2 iš 3“.
Tiesioginė įvestis ar asinchroninė peržiūra? Tiesioginė analizė suteikia daugiausiai vertės, kai rizika yra dviprasmiška, o kūrėjai mokosi iš vyresniojo inžinieriaus paaiškinimo, kodėl jie blokuotų sujungimą. Asinchroninės peržiūros pakanka, kad būtų galima palyginti kūrėjo išvadas su anotuota eksperto peržiūra. Daugelis komandų naudoja abu metodus: pirmiausia savarankišką pasiruošimą, o vėliau moderuotą sesiją sudėtingų atvejų nagrinėjimui.
4. Pateikite realų pavyzdį
Iliustracinis pavyzdys. Prieš naudodamas atvejį ir atsakymo kriterijus, inžinerijos vadovas turėtų juos patvirtinti.
Byla. Sugeneruotas galinis taškas grąžina kliento sąskaitą faktūrą pagal sąskaitos faktūros ID. Jis patikrina, ar skambinantysis turi galiojantį seansą, naudoja parametrinę užklausą ir išlaiko pagrindinį testą. Ta pati funkcija padidina bendrinamą atsisiuntimų skaitiklį be užrakto.
Užduotis. Kūrėjas nurodo kiekvieną įžvelgiamą riziką, ją surūšiuoja ir aprašo testą, kuris kiekvieną pagrįstų.
Pirmas bandymas. „Atrodo gerai. Užklausa yra parametrizuota ir testas sėkmingas.“ Kūrėjas sėkmingą testą traktavo kaip įrodymą ir neklausė, ko testas neapima.
Atsiliepimas ir bandymas dar kartą. Recenzentas prašo kūrėjo įvardyti, ką sesijos patikrinimas įrodo, o ko ne. Pakartotinio bandymo metu jo prašoma atsižvelgti į du skirtingus klientus ir dvi vienalaikes užklausas.
Stipresnis bandymas. „Seanso patikrinimas įrodo, kas skambina, o ne tai, kad sąskaita faktūra yra jų. Parašyčiau testą, kuriame klientas A prašo kliento B sąskaitos faktūros ID ir tikisi atmetimo. Skaitliukas didinamas be sinchronizacijos, todėl dvi užklausos vienu metu gali prarasti atnaujinimą. Paleisčiau lygiagretų testą ir palyginčiau skaičių. Pati užklausa yra parametrizuota, todėl negaiščiau laiko.“ Atkreipkite dėmesį, kad šis atsakymas suskirsto rizikas į kategorijas ir susieja kiekvieną su testu.
Kodėl kiekvienas atsakymas yra pagrįstas arba neišsamus. Vertinkite kiekvieną pagal patvirtintus kriterijus, o ne pagal recenzento pageidavimus. Pirmasis bandymas vadovaujasi įpročiu, bet praleidžia įrodymus. Stipresnis bandymas yra konkretus, prioritetinis ir išbandomas.
5. Įvertinkite pajėgumus ir planuokite perdavimą
Gebėjimų įrodymas yra naujo pratimo, kurio besimokantysis nėra matęs, atlikimas. Balų patikrinimo kokybė ir atitinkamų trūkumų nustatymas. Paprastoje vertinimo skalėje kiekvienam kriterijui naudojama 0–2 balų skalė:
| kriterijus | Stebimi įrodymai |
|---|---|
| Užduoties vykdymas | Audituoja sugeneruotą kodą ir užfiksuoja kiekvieno radinio įrodymus. |
| Priežastys | Paaiškinami apribojimai, alternatyvos ir tai, kas lieka neaišku, bei įvertinama rizika. |
| Ribos | Laikosi komandos peržiūros taisyklių ir, kai rizika peržengia jo kompetencijos ribas, praneša apie tai saugumo specialistui. |
Inkarai: 0 – nėra arba nepalaikoma, 1 – dalinis su atitinkamais praleidimais, o 2 – išsamus ir pagrįstas pagal sutartus kriterijus. Atskirai apibrėžkite kritines klaidas, pvz., kodo su neapsaugotu prieigos keliu patvirtinimą, kad bendras balas negalėtų jų paslėpti. Ši vertinimo skalė yra pasiūlymas, o ne patvirtintas pasirengimo standartas: pritaikykite ją kartu su inžinerijos vadovu ir išbandykite. Mūsų vadovas, skirtas... interaktyvios praktikos kūrimas su naudingu grįžtamuoju ryšiu rodoma, kaip rašyti atsiliepimus, susietus su sprendimais.
Sąmoningai suplanuokite perkėlimą. Po pratimo kiekvienam kūrėjui pateikite tikrą užklausą (pull request), kurioje būtų sugeneruotas kodas, ir kartu peržiūrėkite jų išvadas arba atlikite trumpą retrospektyvą apie neseniai atliktą peržiūrą, kurioje kažko trūksta.
Kur padeda interaktyvus pristatymas
Interaktyvūs formatai padeda, kai visi turi įsipareigoti prieš susitikdami su grupe. Tiesioginės sesijos metu moderatorius gali parodyti sugeneruotą fragmentą, paprašyti kiekvieno kūrėjo įvesti matomas rizikas ir testą, kurį parašytų, o tada atskleisti išklotinę prieš diskusiją. Tas pats pratimas gali būti atliekamas savarankiškai, kad būtų lengviau pasiruošti. AhaSlides palaiko interaktyvų mokymąsi ir perėjimą tarp tiesioginio ir savarankiško pristatymo. Tai pristatymo ir mokymosi priemonė, o ne vieta kodui vykdyti, todėl kodo pratimus atlikite savo aplinkoje. Patikrinkite visas konkrečias kūrimo, atsiliepimų ar ataskaitų teikimo funkcijas, kuriomis planuojate remtis savo darbo eigoje. Norėdami gauti informacijos apie formatų pasirinkimą, žr. mūsų straipsnį apie Kada naudoti adaptyvų, interaktyvų ir tiesioginį mokymąsi.
Išmatuokite, kas pasikeitė
Iš anksto nuspręskite, kas parodytų, kad kūrėjai gali atlikti užduotį. Palyginkite nematomo pratimo patikrinimo kokybę ir defektų nustatymą su pradiniu lygiu. Apibrėžkite, kas įtraukiamas, vardiklį ir laiką. Jei rezultatai pagerėja, prieš įskaitydami mokymus, patikrinkite, kas dar pasikeitė per tą patį laikotarpį, pavyzdžiui, nauja statinės analizės taisyklė, peržiūrėtas peržiūros kontrolinis sąrašas ar asistento pakeitimas.
Apribojimai, kurie gali likti
- Peržiūros laikas. Auditas trunka ilgiau nei peržiūra, o terminai stumia į priekį peržiūrą.
- Įrankiai. Be bandymų laido ar skenavimo vamzdyne, riziką sunku pagrįsti.
- Keičiant priemones. Asistentai keičiasi greitai, todėl pratimus skirkite apžvalgų rašymo įpročiui, o ne vienam produktui.
- Bylos aprėptis. Viename pratime pateikiami keli defektų tipai. Įvertinimas neapibūdina kūrėjo sprendimo apskritai.
- Perdavimo. Pasirodymas seminare nėra tas pats, kas pasirodymas užimtoje peržiūros eilėje.
Iš anksto įvardinkite šiuos dalykus rėmėjams ir suplanuokite atskirus taisymus. Mokymai pagerina tai, ką kūrėjas gali rasti ir įrodyti. Jie nesukuria laiko ar įrankių.
Dažnai užduodami klausimai
Kas yra dirbtinio intelekto sugeneruoto kodo peržiūros mokymai?
Tai moko kūrėjus, kaip pateikti instrukcijas, įvertinti ir audituoti dirbtinio intelekto asistento sukurtą kodą, rasti saugumo, lygiagretumo ir efektyvumo problemas ir kiekvieną iš jų pagrįsti testu.
Ar sugeneruotas kodas yra mažiau saugus nei žmogaus kodas?
Tyrimai rodo riziką, tačiau rezultatai priklauso nuo įrankio, užduoties ir tyrimo dizaino. Vieno naudotojų tyrimo metu nustatyta, kad dalyviai su asistentu rašė mažiau saugų kodą ir jautėsi dėl jo labiau pasitikintys savimi, todėl reikėtų lavinti peržiūros įprotį.
Kaip vertinate, ar kūrėjai gali audituoti sugeneruotą kodą?
Pateikite naują kodo užduotį ir įvertinkite jos kokybės patikrinimą bei defektų identifikavimą pagal sutartus kriterijus. Saugaus kodavimo taisyklių testas patvirtina tik išankstinius reikalavimus.
Ar mokymams reikalinga kodo smėlio dėžė?
Jums reikia vietos, kurioje galėtumėte atlikti pratimus, o tai paprastai būna jūsų aplinka. Prieš pasikliaudami įrankiu, patikrinkite, ar jis atitinka jūsų poreikius.
Kur pradėti
Pasirinkite vieną pasikartojantį sugeneruoto pakeitimo tipą savo kodo bazėje. Parašykite našumo ataskaitą, paprašykite inžinerijos vadovo patvirtinti numatytus defektus ir testus, kurie juos parodytų, ir sukurkite trijų kriterijų vertinimo skalę nuo 0 iki 2 ir kritinių klaidų sąrašą. Prieš diegdami, išbandykite ją su maža grupe.
Norėdami sužinoti, kaip auditą būtų galima atlikti tiesiogiai su jūsų komanda ir vėliau pakartotinai atlikti savarankiškai, peržiūrėkite AhaSlides.
