Arendaja palub assistendilt funktsiooni, mis kontrollib, kas kasutaja võib aruande alla laadida. Kood kompileerub. Õnneliku tee test läbib. Tõmbepäring näeb korralik välja. Kaks nädalat hiljem märkab kolleeg, et funktsioon kontrollib, kas kasutaja on sisse logitud, kuid ei kontrolli kunagi, kas aruanne kuulub talle.
See on illustreeriv stsenaarium, mitte dokumenteeritud intsident. See kirjeldab lünka, mille tehisintellekti loodud koodi ülevaatuse koolitus peab täitma: loodud koodis, mis läbib põhikontrolli, võib ikkagi olla autoriseerimis- või samaaegsusviga ning seda üle vaatav isik peab selle leidma ja selgitama, miks see on oluline.
See juhend on mõeldud insenerijuhtimise juhtidele ja insenerijuhtidele. See hõlmab jõudlusprobleemi kirjeldamist, lünkade diagnoosimist, disaini ettevalmistamist ja harjutamist, juhtumi läbitöötamist ning oskuste ülekandumist reaalsetele ülevaadetele. See käsitleb disaini koolitamist. Iga teie programmi defekti, testi ja ülevaate reegel peaksid olema valideeritud vaneminseneride ja teie turvameeskonna poolt.
Mis on tehisintellekti loodud koodi ülevaatamise koolitus?
Tehisintellekti abil genereeritud koodi ülevaatamise koolitus õpetab arendajatele, kuidas assistendile selgelt juhiseid anda ning seejärel vastust hinnata ja auditeerida: kas see on õige, kas see on ohutu, kas see käitub samaaegse koormuse korral, kas see on piisavalt tõhus? See ei ole kursus konkreetse tööriista kohta. See treenib ülevaatamise harjumust, mis jääb samaks ka tööriista muutudes.
Quick faktid
| Küsimus | Lühike vastus |
|---|---|
| Mis on ülesanne? | Auditeeri genereeritud koodi ja põhjenda iga riski testiga. |
| Mis punktisumma sa saad? | Kontrollimise kvaliteet ja kas leiti asjakohaseid defekte. |
| Kas turvalise kodeerimise reeglite viktoriinist piisab? | Ei. See kinnitab eeltingimusi, aga mitte seda, kas arendaja suudab märgata koodis viga, mis tundub usutav. |
| Kes sisu valideerib? | Insenerijuht ja teie turvameeskond. |
| Mida treeninguga parandada ei saa? | Ülevaatamise aeg, tööriistad, ebaselge omandiõigus ja surve kiireks ühinemiseks. |
| Kuidas sa tead, et see toimis? | Uus, nähtamatu koodiharjutus, mida hinnatakse kokkulepitud kriteeriumide alusel ja millele järgneb reaalsete arvustuste järelkontroll. |
1. Kirjeldage jõudlusprobleemi
Alusta ülesandest: auditeeri genereeritud koodi ja põhjenda riske testidega. Auditeerimine on kahtlustav lugemine. Põhjendamine on kahtluse muutmine tõendiks, tavaliselt testiks, mis ebaõnnestub, või reproduktsiooniks, mis näitab viga.
Uuring näitab, miks see vajab teadlikku harjutamist. GitHub Copiloti uuringus genereerisid Pearce ja tema kolleegid 89 stsenaariumi korral 1,689 programmi, mis valiti teadaolevate nõrkuste tüüpide jaoks, ning leidsid, et umbes 40 protsenti neist olid haavatavad (Pearce ja kolleegid, 2021). See oli varajane tööriist ja spetsiifiline stsenaariumide kogum, seega ärge käsitlege seda arvu tänapäeva assistentide määrana. Eraldi kasutajauuringus paluti osalejatel kirjutada koodi tehisintellekti assistendiga ja ilma. Assistendiga inimesed kirjutasid oluliselt vähem turvalist koodi ja uskusid tõenäolisemalt, et nende kood on turvaline (Perry ja kolleegid, 2023). Samas uuringus leiti, et osalejad, kes usaldasid abilist vähem ja reageerisid rohkem tema küsimustele, tekitasid vähem haavatavusi.
Koolituse kujundamise kohta järgneb kaks õppetundi. Usutav väljund vajab aktiivset arvustajat. Ja enesekindlus ei ole tõend, seega peab harjutus küsima testi, mitte arvamust.
Kirjutage toimivusaruanne ühe lausega ja laske insenerijuhil see üle vaadata: "Arendaja loetleb genereeritud muudatuse põhjal turva-, samaaegsus- ja efektiivsusriskid, mida ta näeb, ning igaühe kohta kirjeldab või kirjutab testi, mis seda näitaks."
2. Õppimis- ja kontekstilünga diagnoosimine
Enne kui midagi üles ehitad, võrdle ülesannet sellega, mida sinu praegune programm harjutab ja hindab. Tavaliselt eristavad koolituslünka millestki muust kolm küsimust:
- Kas praegune praktika kasutab tegelikku ülesannet? Kui koolitus hõlmab küll kiiret kirjutamist, aga arendajatel ei paluta kunagi väljundit üle vaadata, siis pole keegi auditeerimist harjutanud. Kui hindamine on valikvastustega test turvalise kodeerimise reeglite kohta, siis see mõõdab meeldejätmist.
- Mis on kognitiivne nõudlus? Bloomi muudetud taksonoomias on koodi ohutuse hindamine ja seda tõestava testi valimine analüüsi ja hindamise tasemel ning parema ülesande või paranduse loomine loomise tasemel. Tegevuste sobitamist nende tasemetega käsitletakse meie juhendis. õppetegevuste sobitamine Bloomi taksonoomiaga.
- Kas peale oskuste on takistuseks midagi muud? Kontrollige ülevaatamise aega, tööriistu ja omandiõigust. Kui ülevaatajatel on iga pull requesti kohta viis minutit aega, siis koolituse puudumine auditit ei too. Kui staatilist analüüsi või testimisraamistikku pole töövoogu alustatud, võib arendaja riski leida, kuid mitte seda põhjendada. Teatage koolituse puudumisest tingitud põhjustest inimestele, kes saavad need parandada.
3. Kujunduse ettevalmistamine ja harjutamine
Kui tead, milliseid lünki koolitusega täita saab, anna igale etapile eraldi ülesanne.
Ettevalmistus. Kontrollige eeltingimusi lühikese diagnostika abil: millised on teie testivirna levinumad nõrkuste kategooriad, kuidas teie testid on üles ehitatud, milline on teie meeskonna kasutatav kontrollnimekiri. Sellele etapile sobib iseseisvalt õppimine. Meenutuskontroll kinnitab ainult eeltingimusi.
Praktika. Kasutage realistlikult genereeritud koodist üles ehitatud auditiharjutusi. Lisage igale harjutusele väike arv erinevat tüüpi defekte, näiteks puuduv omanikukontroll, kahe päringu vaheline võidujooks ja ebaefektiivne tsükkel, lisaks veidi korras koodi. Arendaja vaatab riski üle, nimetab selle, ütleb selle tõsiduse ja pakub välja testi, mis seda näitaks. Küsige põhjendust, mitte reanumbrite loendit.
Tagasiside. Seo see otsustega, mitte koguskooriga. „Sa märkisid jagatud loenduril tsükli lipuga, aga mitte võidujooksu, ja sinu test poleks seda kinni püüdnud, sest see käivitab päringuid ükshaaval“ on kasulikum kui „Leitud 2/3“.
Otseülekanne või asünkroonne arvustus? Reaalajas tagasiside lisab kõige rohkem väärtust siis, kui risk on mitmetähenduslik ja arendajad õpivad vaneminseneride selgitustest, miks nad ühendamist blokeeriksid. Asünkroonsest ülevaatest piisab arendaja leidude võrdlemiseks kommenteeritud eksperdiarvamusega. Paljud meeskonnad kasutavad mõlemat: esmalt iseseisvat ettevalmistust ja seejärel keeruliste juhtumite puhul juhendatud sessiooni.
4. Töötage läbi realistlik näide
Illustreeriv. Insenerijuht peaks enne kasutamist juhtumi ja vastusekriteeriumid valideerima.
Juhul. Genereeritud lõpp-punkt tagastab kliendi arve arve ID järgi. See kontrollib, kas helistajal on kehtiv seanss, kasutab parameetriga päringut ja läbib põhitesti. Sama funktsioon suurendab jagatud allalaadimiste loendurit ilma lukustuseta.
Ülesanne. Arendaja nimetab iga riski, mida ta näeb, järjestab need ja kirjeldab testi, mis iga riski põhjendaks.
Esimene katse. „Näeb hea välja. Päring on parameetritega ja test läbib.“ Arendaja on käsitlenud läbivat testi tõendina ega ole küsinud, mida test ei kata.
Tagasiside ja proovi uuesti. Ülevaataja palub arendajal nimetada, mida seansi kontroll tõestab ja mida mitte. Uuesti proovimisel palutakse tal arvestada kahe erineva kliendi ja kahe samaaegse päringuga.
Tugevam katse. „Seansi kontroll tõestab, kes helistab, mitte seda, et arve on tema oma. Ma kirjutaksin testi, kus klient A küsib kliendi B arve ID-d ja ootab keeldumist. Loendur suureneb ilma sünkroniseerimiseta, seega võivad kaks päringut korraga uuenduse kaotada. Ma käivitaksin samaaegse testi ja võrdleksin loendurit. Päring ise on parameetritega määratud, seega ma ei kulutaks seal aega.“ Pane tähele, et see vastus järjestab riskid ja seob iga testiga.
Miks iga vastus on õigustatud või mittetäielik. Hinnake igaüht heakskiidetud kriteeriumide, mitte retsensendi eelistuste alusel. Esimene katse järgib harjumust, kuid jätab tõendid välja. Tugevam katse on spetsiifiline, prioritiseeritud ja testitav.
5. Hinnake võimekust ja plaanige üleandmist
Võimekuse tõendiks on uue harjutuse sooritamine, mida õppija pole varem näinud. Skooride kontrollimise kvaliteet ja asjakohaste puuduste tuvastamine. Lihtne rubriik kasutab kriteeriumi kohta skaalat 0 kuni 2:
| Kriteerium | Vaadeldavad tõendid |
|---|---|
| Ülesande täitmine | Auditeerib genereeritud koodi ja salvestab iga leiu taga olevad tõendid. |
| Põhjendus | Selgitab piiranguid, alternatiive ja seda, mis jääb ebakindlaks, ning järjestab riskid. |
| Piirid | Järgib meeskonna ülevaatusreegleid ja eskaleerib riski turvaspetsialistile, kui see on väljaspool tema pädevust. |
Ankrud: 0 puudub või ei ole toetatud, 1 on osaline oluliste puudujääkidega ja 2 on täielik ja põhjendatud kokkulepitud kriteeriumide alusel. Määrake kriitilised vead eraldi, näiteks kaitsmata juurdepääsuteega koodi kinnitamine, et üldskoor ei saaks neid varjata. See rubriik on ettepanek, mitte valideeritud valmisoleku standard: kohandage seda koos insenerijuhiga ja katsetage seda. Meie juhend... interaktiivse praktika kujundamine kasuliku tagasiside abil näitab, kuidas kirjutada otsustega seotud tagasisidet.
Planeeri ülekannet teadlikult. Pärast harjutust koosta igale arendajale päris pull request, mis sisaldab genereeritud koodi, ja vaata koos läbi nende leiud või tee lühike tagasivaade hiljutisele ülevaatele, millest midagi puudu jäi.
Kus interaktiivne edastamine aitab
Interaktiivsed formaadid aitavad, kus kõik peaksid enne grupiga kohtumist oma panuse andma. Otseülekande ajal saab moderaator näidata genereeritud koodijuppi, paluda igal arendajal sisestada riskid, mida nad näevad, ja testi, mille nad kirjutaksid, ning seejärel enne arutelu avaldada jaotuse. Sama harjutust saab ettevalmistuseks teha ka iseseisvalt. AhaSlides toetab interaktiivset õppimist ja liikumist reaalajas toimuva ja iseseisvalt sooritatava õppe vahel. See on esitlus- ja õppevahend, mitte koht koodi käivitamiseks, seega käivitage koodiharjutused oma keskkonnas. Kontrollige kõiki konkreetseid autori-, tagasiside- või aruandlusfunktsioone, millele kavatsete oma töövoo puhul toetuda. Vormingute valimise juhiste saamiseks vaadake meie artiklit Millal kasutada adaptiivset, interaktiivset ja reaalajas õppimist.
Mõõda, mis muutus
Otsusta eelnevalt, mis näitaks, et arendajad suudavad ülesandega toime tulla. Võrdle nähtamatu harjutuse verifitseerimise kvaliteeti ja defektide tuvastamist algtasemega. Määratle, kes on kaasatud, nimetaja ja ajastus. Kui tulemused paranevad, kontrolli enne koolituse arvestamist, mis samal perioodil veel muutus, näiteks uus staatilise analüüsi reegel, muudetud ülevaatuse kontrollnimekiri või assistendi vahetus.
Piirangud, mis võivad jääda
- Ülevaatamise aeg. Audit võtab kauem aega kui ülevaatamine ja tähtajad suruvad ülevaatamist edasi.
- Tööriistad. Ilma katserakmete või torujuhtme skaneerimiseta on riski raske põhjendada.
- Tööriistade vahetamine. Assistendid vahetuvad kiiresti, seega keskendu harjutustele arvustusharjumuse, mitte ühe toote kohta.
- Juhtumi katvus. Üks harjutus näitab mõnda tüüpi defekte. Skoor ei kirjelda arendaja otsustusvõimet üldiselt.
- Ülekanne. Töötoas esinemine ei ole sama mis tihedas arvustusjärjekorras esinemine.
Nimetage need sponsoritele varakult ja planeerige eraldi parandused. Koolitus parandab seda, mida arendaja suudab leida ja tõestada. See ei loo aega ega tööriistu.
Korduma kippuvad küsimused
Mis on tehisintellekti loodud koodi ülevaatamise koolitus?
See õpetab arendajatele tehisintellekti assistendi loodud koodi käivitama, hindama ja auditeerima, leides turvalisuse, samaaegsuse ja efektiivsuse probleeme ning toetades igaüht neist testiga.
Kas genereeritud kood on vähem turvaline kui inimese kood?
Uuringud viitavad riskile, kuid tulemused sõltuvad tööriistast, ülesandest ja uuringu ülesehitusest. Ühes kasutajauuringus leiti, et assistendiga osalejad kirjutasid vähem turvalist koodi ja tundsid end selle suhtes kindlamalt, mis on põhjus arvustusharjumuse treenimiseks.
Kuidas hinnata, kas arendajad saavad genereeritud koodi auditeerida?
Esitage uue koodi harjutus ja hinnake kontrolli kvaliteeti ning defektide tuvastamist kokkulepitud kriteeriumide alusel. Turvalise kodeerimise reeglite viktoriin kinnitab ainult eeltingimusi.
Kas koolituse jaoks on vaja koodi liivakasti?
Harjutuste tegemiseks on vaja kohta, mis on tavaliselt teie enda keskkond. Enne tööriistale lootmist kontrollige, kas see toetab teie vajadusi.
Kust alustada
Vali oma koodibaasis üks korduv genereeritud muudatuse tüüp. Kirjuta toimivusaruanne, lase insenerijuhil valideerida kavandatud vead ja testid, mis neid näitaksid, ning koosta kolmekriteeriumiline rubriik skaalaga 0 kuni 2 ja kriitiliste vigade loendiga. Enne juurutamist katseta seda väikese grupiga.
Et näha, kuidas auditit oma meeskonnaga reaalajas läbi viia ja hiljem iseseisvalt uuesti kasutada, uurige AhaSlides.
