Kehittäjä pyytää assistenttia tekemään funktion, joka tarkistaa, voiko käyttäjä ladata raportin. Koodi kääntyy. Happy-path-testi läpäisee. Pull-pyyntö näyttää siistiltä. Kaksi viikkoa myöhemmin kollega huomaa, että funktio tarkistaa, että käyttäjä on kirjautunut sisään, mutta ei koskaan tarkista, kuuluuko raportti hänelle.
Tämä on havainnollistava skenaario, ei dokumentoitu tapaus. Se kuvaa aukkoa, joka tekoälyn luoman koodin tarkistuskoulutuksen on paikattava: luodussa koodissa, joka läpäisee perustarkistuksen, voi silti olla valtuutus- tai samanaikaisuusvirhe, ja sitä tarkistavan henkilön on löydettävä se ja kerrottava, miksi se on tärkeä.
Tämä opas on tarkoitettu suunnittelupäälliköille ja suunnittelupäälliköille. Se kattaa suorituskykyongelman kuvaamisen, puutteiden diagnosoinnin, suunnittelun valmistelun ja käytännön toteutuksen, tapauksen läpikäymisen ja sen arvioinnin, voidaanko taitoa soveltaa todellisiin katselmointiin. Se käsittelee suunnittelun koulutusta. Jokainen ohjelmasi vika-, testi- ja katselmussääntö tulisi validoida vanhempien insinöörien ja tietoturvatiimisi toimesta.
Mitä on tekoälyn luoman koodin tarkistuskoulutus?
Tekoälyn luoman koodin tarkistuskoulutus opettaa kehittäjille, miten avustajalle annetaan selkeät ohjeet ja arvioida ja auditoida sitten vastaukset: onko ne oikein, onko ne turvallisia, toimiiko ne samanaikaisen kuormituksen aikana ja onko ne riittävän tehokkaita? Kyseessä ei ole kurssi, joka keskittyy tiettyyn työkaluun. Se kouluttaa tarkistuskäyttäytymisen, joka pysyy samana työkalun muuttuessa.
Nopeita faktoja
| Kysymys | Lyhyt vastaus |
|---|---|
| Mikä on tehtävä? | Auditoi luotu koodi ja perustele jokainen riski testillä. |
| Mitä pisteitä saat? | Todentamisen laatu ja se, löytyikö asiaankuuluvia vikoja. |
| Riittääkö pelkkä tietokilpailu turvallisen koodauksen säännöistä? | Ei. Se vahvistaa edellytykset, mutta ei sitä, pystyykö kehittäjä havaitsemaan koodissa virheen, joka näyttää uskottavalta. |
| Kuka vahvistaa sisällön? | Tekninen päällikkö ja turvallisuustiimisi. |
| Mitä harjoitus ei korjaa? | Arviointiaika, työkalut, epäselvät omistajuudet ja paine nopeaan yhdistymiseen. |
| Mistä tiedät, että se toimi? | Uusi, näkymätön koodiharjoitus, joka pisteytetään sovittujen kriteerien perusteella ja jonka jatkotoimet perustuvat todellisiin arviointeihin. |
1. Kuvaile suorituskykyongelma
Aloita tehtävästä: auditoi luotu koodi ja perustele riskit testeillä. Auditointi on epäluuloisesti lukemista. Todistaminen on epäilyn muuttamista todisteeksi, yleensä testiksi, joka epäonnistuu, tai toisinnoksi, joka osoittaa virheen.
Tutkimus viittaa siihen, miksi tämä vaatii tietoista harjoittelua. GitHub Copilot -tutkimuksessa Pearce ja kollegat loivat 1 689 ohjelmaa 89 skenaariossa, jotka valittiin tunnettujen heikkoustyyppien perusteella, ja havaitsivat, että noin 40 prosenttia niistä oli haavoittuvia (Pearce ja kollegat, 2021). Se oli varhainen työkalu ja tietty joukko skenaarioita, joten älä käsittele lukua nykypäivän avustajien lukuna. Erillisessä käyttäjätutkimuksessa osallistujia pyydettiin kirjoittamaan koodia tekoälyavustajan kanssa ja ilman. Avustajaa käyttävät kirjoittivat huomattavasti vähemmän turvallista koodia ja uskoivat todennäköisemmin koodinsa olevan turvallista (Perry ja kollegat, 2023). Samassa tutkimuksessa havaittiin, että osallistujat, jotka luottivat avustajaan vähemmän ja vastasivat enemmän hänen kehotteisiinsa, tuottivat vähemmän haavoittuvuuksia.
Koulutussuunnittelusta on kaksi oppituntia. Uskottava tuloste tarvitsee aktiivisen arvioijan. Ja luottamus ei ole todisteita, joten harjoituksen on pyydettävä testiä, ei mielipidettä.
Kirjoita suorituskykylausunto yhteen lauseeseen ja pyydä suunnittelupäällikköä tarkistamaan se: "Kehittäjä listaa luodun muutoksen perusteella näkemänsä tietoturva-, samanaikaisuus- ja tehokkuusriskit ja kuvaa tai kirjoittaa jokaiselle niistä testin, joka sen osoittaisi."
2. Diagnosoi oppimis- ja kontekstikuivat
Ennen kuin rakennat mitään, vertaa tehtävää nykyisen ohjelmasi harjoitteluun ja arviointiin. Kolme kysymystä erottaa yleensä koulutusaukon jostakin muusta:
- Käyttääkö nykykäytäntö todellista tehtävää? Jos koulutus kattaa ohjelmointiohjeiden kirjoittamisen, mutta ei koskaan pyydetä kehittäjiä tarkistamaan tuotosta, kukaan ei ole harjoitellut auditointia. Jos arviointi on monivalintatesti turvallisista koodaussäännöistä, se mittaa muistamista.
- Mikä on kognitiivinen vaatimus? Bloomin tarkistetussa taksonomiassa koodin turvallisuuden arviointi ja sitä todistavan testin valitseminen sijoittuvat analysointi- ja arviointitasoille, ja paremman kehotteen tai korjauksen suunnittelu vie luontitasolle. Aktiviteettien yhteensovittamista näille tasoille käsitellään oppaassamme. oppimistoimintojen yhdistäminen Bloomin taksonomiaan.
- Onko jokin muu kuin taito esteenä? Tarkista arviointiin kuluva aika, työkalut ja omistajuus. Jos arvioijilla on viisi minuuttia aikaa pull-pyyntöä kohden, koulutus ei tuota auditointia. Jos putkessa ei ole staattista analyysia tai testijohtimia, kehittäjä voi löytää riskin, mutta ei perustella sitä. Ilmoita koulutuksen puuttumisesta aiheutuvat syyt henkilöille, jotka voivat korjata ne.
3. Suunnittelun valmistelu ja harjoittelu
Kun tiedät, mitä aukkoja koulutus voi paikata, anna jokaiselle vaiheelle erillinen tehtävä.
Valmistautuminen. Tarkista esivaatimukset lyhyellä diagnostiikalla: yleisimmät heikkouskategoriat, joihin testipinosi kohdistuu, testiesi rakenne ja tiimisi käyttämä tarkistuslista. Omaan tahtiin opiskelu sopii tähän vaiheeseen. Kertaustarkistus vahvistaa vain esivaatimukset.
Harjoitella. Käytä realistisesti luodusta koodista rakennettuja auditointiharjoituksia. Syötä jokaiseen pieni määrä erityyppisiä vikoja, kuten puuttuva omistajuustarkistus, kahden pyynnön välinen kilpailu ja tehoton silmukka, sekä jonkin verran koodia, joka on kunnossa. Kehittäjä tarkastelee, nimeää jokaisen riskin, kertoo sen vakavuuden ja ehdottaa testiä, joka osoittaisi sen. Pyydä perusteluja, älä rivinumeroluetteloa.
Palaute. Yhdistä se päätöksiin kokonaispistemäärän sijaan. "Merkitsit silmukan, mutta et kilpailua jaetulla laskurilla, eikä testisi olisi havainnut sitä, koska se suorittaa pyyntöjä yksi kerrallaan" on hyödyllisempi kuin "2/3 löytyi".
Live-syöte vai asynkroninen tarkistus? Live-syöte tuo eniten arvoa silloin, kun riski on epäselvä ja kehittäjät oppivat kuulemalla vanhemman insinöörin selityksen siitä, miksi he estäisivät yhdistämisen. Asynkroninen arviointi riittää kehittäjän havaintojen vertaamiseen annotoituun asiantuntija-arviointiin. Monet tiimit käyttävät molempia: ensin omaan tahtiin valmistautumista ja sitten fasilitoitua istuntoa vaikeiden tapausten parissa.
4. Käytä realistista esimerkkiä
Havainnollistava. Tekniikan päällikön tulisi validoida tapaus ja vastauskriteerit ennen käyttöä.
Tapaus. Luotu päätepiste palauttaa asiakkaan laskun laskun ID:n perusteella. Se tarkistaa, että soittajalla on kelvollinen istunto, käyttää parametrisoitua kyselyä ja läpäisee perustestin. Sama funktio kasvattaa jaetun latauslaskurin arvoa ilman lukitusta.
Tehtävä. Kehittäjä mainitsee jokaisen näkemänsä riskin, luokittelee ne ja kuvailee testin, joka tukisi kutakin riskiä.
Ensimmäinen yritys. "Näyttää hyvältä. Kysely on parametrisoitu ja testi läpäisee sen." Kehittäjä on pitänyt läpäisevää testiä todisteena eikä ole kysynyt, mitä testi ei kata.
Palaute ja uudelleenyritys. Tarkistaja pyytää kehittäjää nimeämään, mitä istunnon tarkistus todistaa ja mitä ei. Uudelleenyrityksessä häntä pyydetään ottamaan huomioon kaksi eri asiakasta ja kaksi samanaikaista pyyntöä.
Vahvempi yritys. "Istunnon tarkistus todistaa kuka soittaa, ei sitä, että lasku on heidän. Kirjoittaisin testin, jossa asiakas A pyytää asiakkaan B laskutunnusta ja odottaa hylkäämistä. Laskuria kasvatetaan ilman synkronointia, joten kaksi pyyntöä samanaikaisesti voisi menettää päivityksen. Suorittaisin rinnakkaisen testin ja vertaisin laskuria. Kysely itsessään on parametrisoitu, joten en käyttäisi siihen aikaa." Huomaa, että tämä vastaus luokittelee riskit ja sitoo jokaisen testiin.
Miksi kukin vastaus on puolusteltava tai epätäydellinen. Arvioi kutakin hyväksyttyjen kriteerien perusteella, älä arvioijan mieltymysten perusteella. Ensimmäinen yritys noudattaa tapaa, mutta jättää pois todisteet. Vahvempi yritys on täsmällinen, priorisoitu ja testattavissa.
5. Arvioi kyvykkyydet ja suunnittele siirto
Osoitus kyvykkyydestä on suoritus uudessa harjoituksessa, jota oppija ei ole nähnyt. Pisteytyksen varmennuslaatu ja asiaankuuluvien puutteiden tunnistaminen. Yksinkertainen arviointimatriisi käyttää asteikkoa 0–2 kriteeriä kohden:
| Kriteeri | Havaittavissa oleva näyttö |
|---|---|
| Tehtävän suorittaminen | Tarkastaa luodun koodin ja tallentaa jokaisen löydöksen taustalla olevat todisteet. |
| perustelut | Selittää rajoitukset, vaihtoehdot ja epävarmat asiat sekä luokittelee riskit. |
| Rajat | Noudattaa tiimin tarkastussääntöjä ja vie asian tietoturva-asiantuntijan puheille, kun riski on hänen vastuualueensa ulkopuolella. |
Ankkurit: 0 puuttuu tai sitä ei tueta, 1 on osittainen ja siinä on olennaisia puutteita, ja 2 on täydellinen ja perusteltu sovittujen kriteerien perusteella. Määrittele kriittiset virheet erikseen, kuten suojaamattoman käyttöpolun omaavan koodin hyväksyminen, jotta kokonaispistemäärä ei voi peittää sellaista. Tämä arviointimatriisi on ehdotus, ei validoitu valmiusstandardi: mukauta sitä suunnittelupäällikön kanssa ja kokeile sitä. Oppaamme... interaktiivisen käytännön suunnittelu hyödyllisen palautteen avulla näyttää, miten kirjoitetaan päätöksiin linkittävää palautetta.
Suunnittele siirto harkitusti. Harjoituksen jälkeen yhdistä jokainen kehittäjä aidon pull-requestin kanssa, joka sisältää luodun koodin, ja tarkastele heidän löydöksiään yhdessä tai tee lyhyt retrospektiivi äskettäisestä tarkastelusta, josta jäi jotain huomaamatta.
Missä interaktiivinen toimitus auttaa
Interaktiiviset formaatit auttavat, koska kaikkien tulisi sitoutua ennen ryhmän tapaamista. Live-istunnossa fasilitaattori voi näyttää luodun koodinpätkän, pyytää jokaista kehittäjää kirjoittamaan näkemänsä riskit ja testin, jonka he kirjoittaisivat, ja sitten paljastaa aukeaman ennen keskustelua. Sama harjoitus voidaan suorittaa omaan tahtiin valmistautumisen helpottamiseksi. AhaSlides tukee vuorovaikutteista oppimista ja siirtymistä live-oppimisen ja omaan tahtiin tapahtuvan toteutuksen välillä. Se on esitys- ja oppimistyökalu, ei paikka koodaamiseen, joten suorita koodiharjoitukset omassa ympäristössäsi. Tarkista kaikki erityiset kirjoitus-, palaute- tai raportointitoiminnot, joita aiot käyttää omassa työnkulussasi. Katso ohjeita formaattien valintaan artikkelistamme milloin käyttää adaptiivista, interaktiivista ja reaaliaikaista oppimista.
Mittaa, mikä muuttui
Päätä etukäteen, mikä osoittaisi kehittäjien pystyvän tehtävään. Vertaa näkymättömän harjoituksen todennuksen laatua ja vikojen tunnistamista lähtötasoon. Määrittele, ketkä ovat mukana, nimittäjä ja ajoitus. Jos tulokset paranevat, tarkista, mitä muuta on muuttunut samalla ajanjaksolla, kuten uusi staattisen analyysin sääntö, tarkistettu tarkistuslista tai avustajan vaihtuminen, ennen koulutuksen hyvittämistä.
Rajoitukset, jotka saattavat jäädä
- Arviointiaika. Tarkastus kestää kauemmin kuin silmäilty tarkastus, ja määräajat hidastavat silmäiltyä tarkastusta.
- Työkalut. Ilman testijohtosarjaa tai skannausta putkistossa riskiä on vaikea osoittaa.
- Työkalujen vaihtaminen. Avustajat vaihtuvat nopeasti, joten pidä harjoituksia arvostelutottumuksista, älä yhdestä tuotteesta.
- Tapauksen kattavuus. Yhdessä harjoituksessa esitellään muutamia vikatyyppejä. Pistemäärä ei kuvaa kehittäjän harkintakykyä yleisesti.
- Siirto. Suoritus työpajassa ei ole sama asia kuin suoritus kiireisessä arviointijonossa.
Mainitse nämä sponsoreille ajoissa ja suunnittele erilliset korjaukset. Koulutus parantaa sitä, mitä kehittäjä voi löytää ja todistaa. Se ei luo aikaa tai työkaluja.
Usein kysyttyjä kysymyksiä
Mitä on tekoälyn luoman koodin tarkistuskoulutus?
Se opettaa kehittäjiä kehottamaan, arvioimaan ja auditoimaan tekoälyassistentin tuottamaa koodia, löytämään tietoturva-, samanaikaisuus- ja tehokkuusongelmia ja tukemaan kutakin testillä.
Onko luotu koodi vähemmän turvallinen kuin ihmisen koodi?
Tutkimukset viittaavat riskiin, mutta tulokset riippuvat työkalusta, tehtävästä ja tutkimusasetelmasta. Yhdessä käyttäjätutkimuksessa havaittiin, että avustajan kanssa työskentelevät osallistujat kirjoittivat vähemmän turvallista koodia ja tunsivat olonsa itsevarmemmiksi sen suhteen, minkä vuoksi arviointitottumusta kannattaa kouluttaa.
Miten arvioit, voivatko kehittäjät auditoida luotua koodia?
Anna uusi koodiharjoitus ja pisteytä sen todentamisen laatu ja vikojen tunnistaminen sovittujen kriteerien perusteella. Turvallisen koodauksen sääntöjä koskeva tietokilpailu vahvistaa vain esitiedot.
Tarvitsetko koodihiekkalaatikkoa koulutusta varten?
Tarvitset paikan harjoitusten suorittamiseen, joka on yleensä oma ympäristösi. Tarkista, että käyttämäsi työkalu tukee tarpeitasi, ennen kuin luotat siihen.
Mistä aloittaa
Valitse yksi toistuva muutostyyppi koodikannassasi. Kirjoita suorituskykylausunto, pyydä suunnittelupäällikköä validoimaan kylvetyt viat ja testit, jotka ne osoittaisivat, ja laadi kolmikriteerinen arviointimatriisi asteikolla 0-2 ja luettelolla kriittisistä virheistä. Testaa sitä pienryhmässä ennen julkaisua.
Jos haluat nähdä, miten auditointiharjoitus voitaisiin suorittaa omassa tiimissäsi ja miten sitä voitaisiin käyttää uudelleen omaan tahtiin jälkikäteen, tutustu aiheeseen AhaSlides.
