Kehittäjä avaa pull-pyynnön, joka lisää alennuslaskennan kassapalveluun. Testit läpäisevät ja ero on lyhyt. Tarkistaja hyväksyy sen kahdessa minuutissa ja lisää siihen "LGTM". Kolme kuukautta myöhemmin tiimikaveri haluaa muuttaa samaa funktiota ja huomaa, että se sekoittaa hinnoittelusäännöt, pyöristämisen ja tietokannan käytön samassa paikassa. Kukaan ei voi varmasti sanoa, mitä se saa tehdä.
Tämä on havainnollistava skenaario, ei dokumentoitu tapaus. Se osoittaa, mitä vertaiskoodin tarkistuksen on tuotettava, kun se toimii oppimistoimintana: tarkastaja, joka pystyy näkemään uskottavan muutoksen, havaitsemaan huolenaiheen, joka ei vielä ole vika, ja selittämään sen tavalla, jonka perusteella tekijä voi toimia.
Tämä opas on tarkoitettu suunnittelupäälliköille ja suunnittelupäälliköille. Se näyttää, miten suunnitellaan koodintarkistusharjoituksia ...jotka kehittävät kyseistä taitoa tarkoituksella sen sijaan, että toivoisivat arvioijien poimivan sen jonosta. Se kattaa suorituskykyongelman, diagnosoitavat puutteet, valmistelun ja harjoittelun jäsentämisen, yhden käytännön esimerkin ja sen, miten tarkistetaan, että taito siirtyy todellisiin arviointeihin. Pyydä vanhempia insinöörejä validoimaan jokainen tapaus, vika ja kriteeri ennen kuin käytät sitä.
Mitä koodikatselmointiharjoitukset ovat?
Koodinkatselmointiharjoitukset ovat strukturoituja harjoitustehtäviä, joissa kehittäjä tarkastelee valmisteltua muutosta, selittää löydöksensä ja miksi se on tärkeää, sekä saa palautetta selityksen laadusta. Ne eroavat tiimisi päivittäisistä katselmoinneista. Muutos valitaan etukäteen, siihen liittyvät huolenaiheet tiedetään ja tavoitteena on parantaa tarkistajaa eikä toimittaa muutosta eteenpäin.
Nopeita faktoja
| Kysymys | Lyhyt vastaus |
|---|---|
| Mikä on tehtävä? | Selitä arvioinnin havainnot ja anna palautetta, jonka pohjalta kirjoittaja voi toimia. |
| Mitä pisteitä saat? | Tulosten tarkkuus ja selityksen hyödyllisyys. |
| Riittääkö virheiden laskeminen? | Ei. Arvosteluissa on kyse muustakin kuin vioista, joten harjoitus, joka palkitsee vain virheiden määrän, kouluttaa väärän tavan. |
| Mikä on kognitiivinen vaatimus? | Analysoi ja arvioi suunnitelma ja luo sitten parempi ehdotus. |
| Kuka vahvistaa tapauksen? | Suunnittelupäällikkö tai vanhempi insinööri, joka omistaa koodikannan. |
| Mitä harjoitukset eivät korjaa? | Arviointiaika, epäselvät omistajuussuhteet ja paine nopeaan fuusioon. |
| Mistä tiedät, että se toimi? | Uusi, näkymätön muutos, joka on tarkistettu sovittujen kriteerien perusteella, sekä todellisten arviointien seuranta. |
1. Kuvaile suorituskykyongelma
Aloita tehtävästä yhdellä lauseella: muutoksen jälkeen arvioija selittää, mitä hän löysi, miksi se on tärkeä ja mitä tekijä voisi tehdä asialle. "Selittää" on tärkein sana. Ongelman havaitseminen on puolet taidosta. Toinen puoli on sen sanominen niin, että eri näkökulmasta oleva kollega voi ymmärtää sen, punnita sitä ja toimia.
Nykyaikaista koodikatselmointia koskeva tutkimus tukee näkökulmaa virheiden metsästyksen ulkopuolelle. Microsoftilla tehdyssä tutkimuksessa Bacchelli ja Bird tarkkailivat, haastattelivat ja kyselytutkimuksella tutkivat kehittäjiä ja johtajia. He havaitsivat, että vikojen löytäminen oli edelleen tärkein katselmoinnin motivaatio, mutta katselmointien keskiössä oli vähemmän vikoja kuin ihmiset odottivat. Ne tarjosivat myös muita etuja, kuten tiedon jakamisen, tiimitietoisuuden ja vaihtoehtoisten ratkaisujen lisäämisen, ja tutkijat kuvailivat koodin ja muutosten ymmärtämistä katselmoinnin keskeiseksi osaksi (Bacchelli ja Bird, ICSE 2013). Se on tutkimus yhden yrityksen tiimeistä, joten käytä sitä syynä suunnitella ymmärrystä, älä hintana omallesi.
Googlen julkaisema arviointistandardi viittaa samaan suuntaan. Se kehottaa arvioijia hyväksymään muutoksen, kun se ehdottomasti parantaa koodin yleistä kuntoa, vaikka se ei olisi täydellistä. Siinä sanotaan, että arviointi voi opettaa kehittäjille jotain uutta, joten oppimista edistävät kommentit ovat tervetulleita (Googlen tekniset käytännöt). Molemmat lähteet kuvailevat arviointia paikaksi, jossa harkintaa käytetään ja välitetään eteenpäin. Tätä harjoituksissasi tulisi harjoitella.
2. Diagnosoi oppimis- ja kontekstikuivat
Vertaa tehtävää siihen, mitä nykyisessä ohjelmassasi harjoitellaan ja arvioidaan.
- Käyttääkö nykykäytäntö todellista tehtävää? Jos uudet arvioijat oppivat lukemalla tyylioppaan ja sitten tarkastelemalla reaaliaikaisia pull-requesteja, he harjoittelevat oikeassa työssä ilman turvallista paikkaa olla väärässä. Jos arviointi on testi arviointietiketistä, se mittaa sääntöjen muistamista, ei kykyä soveltaa niitä muutokseen.
- Mikä on kognitiivinen vaatimus? Tarkistetussa Bloomin taksonomiassa suunnittelun järkevyyden arviointi ja sen kompromissien punnitseminen tapahtuu analysointi- ja arviointitasoilla, ja paremman rakenteen ehdottaminen vie luontitasolle. Jos harjoituksesi kysyvät vain "mitä tämä koodi tekee?", ne pysähtyvät ymmärtämiseen. Oppaamme oppimistoimintojen yhdistäminen Bloomin taksonomiaan näyttää, miten aktiviteetti sovitetaan tasoon.
- Onko jokin muu kuin taito esteenä? Tarkista arviointiin käytetty aika, työkalut, omistajuus ja tiimin normit. Jos arvioijilla on viisi minuuttia aikaa pull-requestia kohden, mikään harjoitus ei tuota harkittua selitystä. Jos kirjoittajat ottavat jokaisen kommentin kritiikkinä, arvioijat pehmentävät havaintojaan, kunnes he eivät sano mitään. Ilmoita näistä syistä henkilöille, jotka voivat korjata ne.
3. Suunnittelun valmistelu, harjoittelu ja palaute
Anna jokaiselle vaiheelle erillinen tehtävä.
Valmistautuminen. Tarkista, mitä tarkistajat tarvitsevat ennen aloittamista: tiimin tarkistuslista, suunnitteluperiaatteet, joihin se perustuu, ja miten tulkitaan työkalujesi eroavaisuudet. Pidä tämä omaan tahtiin etenevänä ja lyhyenä. Palautustarkistus vahvistaa vain ennakkoedellytykset, eikä se ole todiste siitä, että joku osaa tarkistaa.
Harjoitella. Käytä valmiiksi tehtyjä muutoksia, joissa on pieni määrä erilaisia huolenaiheita: oikeellisuusvirhe, ylläpidettävyysongelma, kuten avoimen esimerkin sekalaiset vastuut, epäselvä nimi tai puuttuva testi, ja jonkin verran koodia, joka on kunnossa. Pyydä tarkistajaa kirjoittamaan kommentti, jonka hän jättäisi, luokittelemaan huolenaiheet ja kertomaan, mitä lisätietoja hän haluaisi. CodeRefineryn käytännönläheinen oppitunti näyttää muodon: ihmiset avaavat pull-pyynnön, joka sisältää pienen kirjoitusvirheen ja suuremman virheen, ja tarkistavat sen sitten vertaisena (CodeRefinery, Koodin tarkistuksen harjoittelu). Rakenna oma koodisi omasta koodikannastasi, jotta käytännöt ja kompromissit ovat todellisia.
Palaute. Linkitä se arvioijan tekemiin päätöksiin. "Huomasit pyöristysongelman, mutta kommentissasi sanottiin 'tämä näyttää väärältä' kertomatta, mikä syöte rikkoo sen" on hyödyllisempi kuin "löytyi 2/4".
Live-syöte vai asynkroninen tarkistus? Live-palaute lisää arvoa silloin, kun huolenaihe on epäselvä ja arvioijat oppivat kuulemalla vanhemman insinöörin kertovan, miksi he nostaisivat sen esiin tai jättäisivät sen sikseen. Asynkroninen arviointi riittää kommenttien vertaamiseen asiantuntija-arvioon, jossa on kommentteja.
4. Käytä realistista esimerkkiä
Havainnollistava. Tekniikan päällikön tulisi validoida tapaus ja vastauskriteerit ennen käyttöä.
Tapaus. Muutos lisää alennuslaskennan kassapalveluun. Se läpäisee testit. Yhdessä funktiossa se soveltaa prosentuaalisia ja kiinteitä alennuksia, pyöristää tuloksen, kirjoittaa tietokantaan ja lähettää tapahtuman. Sillä on yksi testi, yhdelle prosentuaaliselle alennukselle.
Tehtävä. Arvioija kirjoittaa kommentit, jotka arvioijat jättäisivät, luokittelee heidän huolenaiheensa ja kertoo, mitä heidän tulisi tietää ennen hyväksymistä.
Ensimmäinen yritys. "Näyttää hyvältä, testi läpäisee. Ehkä jakaa sen osiin?" Arvioija on huomannut jotakin, mutta ei ole sanonut mitä, miksi sillä on merkitystä tai mitä tehdä. Kirjoittaja ei voi toimia asian johdosta.
Palaute ja uudelleenyritys. Ohjaaja kysyy: mitä tuleva muutos tähän funktioon voisi rikkoa? Mitä pyytäisit kirjoittajaa lisäämään ennen hyväksyntääsi? Uudelleenyrityksessä pyydetään erityistä kommenttia jokaisesta huolenaiheesta, perusteluineen ja ehdotuksineen.
Vahvempi yritys. "Funktio soveltaa kahdenlaisia alennuksia: pyöristää, tallentaa ja julkaisee tapahtuman, joten pyöristämisen muutos voisi muuttaa sitä, mitä tallennamme ja mitä julkaisemme samanaikaisesti. Pyytäisin, että hinnoittelusäännöt siirrettäisiin puhtaaksi funktioksi, jota voimme testata erikseen. Yksittäinen testi kattaa vain prosentuaalisen alennuksen. Pyytäisin kiinteää alennusta ja tilausta, joka nollaa kokonaissumman. En ole varma, onko tapahtuman tarkoitus käynnistyä, kun kokonaissumma on nolla, joten kysyisin tekijältä." Huomaa, että tässä kommentissa nimetään huolenaihe, annetaan syy, esitetään konkreettinen ehdotus ja todetaan, mitä arvioija ei tiedä.
5. Arvioi kyvykkyydet ja suunnittele siirto
Kyvykkyyden näyttö on suoriutuminen uudessa muutoksessa, jota arvioija ei ole nähnyt. Pisteytä havaintojen tarkkuus ja selityksen hyödyllisyys. Yksinkertainen arviointimatriisi käyttää asteikkoa 0–2 kriteeriä kohden:
| Kriteeri | Havaittavissa oleva näyttö |
|---|---|
| Tehtävän suorittaminen | Löytää muutoksessa olevat olennaiset huolenaiheet ja kirjaa todisteet kutakin varten. |
| perustelut | Selittää, miksi kukin huolenaihe on tärkeä, tarjoaa vaihtoehdon ja sanoo, mikä on vielä epävarmaa. |
| Rajat | Noudattaa tiimin arviointisääntöjä ja pyytää apua tai tietoa, kun auktoriteetti tai konteksti puuttuu. |
Ankkurit: 0 tarkoittaa puuttuvaa tai ei-tuettua, 1 tarkoittaa osittaista ja olennaisia puutteita sisältävää ja 2 tarkoittaa täydellistä ja perusteltua sovittujen kriteerien perusteella. Määrittele kriittiset virheet erikseen, esimerkiksi muutoksen hyväksyminen, johon liittyy tietojen menetysriski, jotta hyvä kokonaispistemäärä ei voi peittää sitä. Mukauta kriteerejä suunnittelupäällikön kanssa; tämä arviointimatriisi on alustava ehdotus, ei validoitu valmiusstandardi. Lisätietoja pisteytyksen perusteluista on oppaassamme aiheesta interaktiivisen käytännön suunnittelu hyödyllisen palautteen avulla.
Suunnittele siirto. Harjoituksen jälkeen tarkista muutaman viikon kuluttua otos arvioijan oikeista arvioinneista samoja kriteerejä käyttäen. Vertaa ennen koulutusta tehtyyn lähtötasoon ja määritä populaatio ja ajoitus etukäteen. Tarkastele muita saman ajanjakson aikana tapahtuneita muutoksia, kuten uutta arviointityökalua tai henkilöstömuutosta, ennen harjoitusten kirjaamista.
6. Suorita harjoitus suorana tai omaan tahtiin AhaSlidesin avulla
Voit tehdä harjoituksen työpajassa tai antaa arvioijien työstää sitä itsenäisesti. Näytä valmisteltu muutos live-istunnossa ja käytä keskustelussa interaktiivisia dioja:
- Valitse vastaus kysymykseen "minkä huolenaiheen nostaisit esiin ensin?", jossa vaihtoehtoina ovat siemenillä määritellyt huolenaiheet. Näytä erotus ennen kuin paljastat oman sijoituksesi.
- Avoin loppu "kirjoita kommentti, jonka jättäisit". Arvostelijat voivat verrata sanamuotojaan muiden sanoihin, mikä osoittaa selitystaidon.
- Arvosteluasteikko kysymykseen "kuinka vakava tämä on?", jotta ryhmä voi nähdä, missä kohtaa arviot eroavat toisistaan, ja keskustella niiden syistä.
Niille arvioijille, jotka eivät voi osallistua, samaa sarjaa voidaan käyttää omaan tahtiin, jolloin jokaisen vastauksen jälkeen näytetään kommentoitu asiantuntija-arvio. Käsittele kaikkia koodin suoritusta, integraatioita tai tekoälyominaisuuksia koskevia väitteitä vahvistamattomina, ennen kuin olet kokeillut niitä omalla materiaalillasi.
Jos koulutat myös tekoälyn kirjoittamaa koodia tarkistajille, katso oheisoppaamme aiheesta Tekoälyn luoman koodin tarkistuskoulutusTuo viesti käsittelee tuotetun tuloksen auditointia. Tämä viesti käsittelee sitä, miten ihmiset tarkastelevat toistensa työtä ja miten he selittävät löydöksiään.
Rajoitukset, jotka saattavat jäädä
- Arviointiaika. Harkittu kommentti vie kauemmin aikaa kuin "LGTM", ja määräajat puoltavat lyhyempää versiota.
- Joukkueen normit. Jos palaute tulkitaan henkilökohtaiseksi kritiikiksi, arvioijat pehmentävät tai hylkäävät havaintojaan.
- Tapauksen kattavuus. Yhdessä harjoituksessa esitellään muutamia huolenaiheita. Pistemäärä ei kuvaa arvioijan harkintakykyä yleisesti.
- Siirto. Suoritus työpajassa ei ole sama asia kuin suoritus kiireisessä jonossa, joten tarkista myös oikeita arvosteluja.
Mainitse nämä sponsoreille ajoissa ja suunnittele erilliset korjaukset. Harjoitukset parantavat sitä, mitä arvioija voi nähdä ja selittää. Ne eivät luo aikaa tai normeja.
Usein kysyttyjä kysymyksiä
Mitä koodikatselmointiharjoitukset ovat?
Ne ovat valmiiksi harjoiteltuja tehtäviä, joissa kehittäjä tarkastelee muutosta, johon liittyy tunnettuja huolenaiheita, kirjoittaa kommentit ja saa palautetta tarkkuudesta ja hyödyllisyydestä. Tavoitteena on kehittää tarkastelijan taitoja, ei toimittaa muutosta eteenpäin.
Miten arvioit, onko arvioijan harkintakyky parantunut?
Anna uusi muutos, jota he eivät ole nähneet, ja pisteytä löydökset ja selitys sovittujen kriteerien perusteella. Tarkista sitten otos oikeista arvosteluista muutaman viikon kuluttua. Arviointisääntöjä koskeva tietokilpailu vahvistaa vain ennakkoedellytykset.
Onko vertaisarvioinnissa pääasiassa kyse virheiden löytämisestä?
Vikojen löytäminen on edelleen tärkein motivaatio, mutta eräässä Microsoftilla tehdyssä tutkimuksessa havaittiin, että katselmoinnit keskittyivät odotettua vähemmän vikoihin ja että ne edistivät myös tiedon jakamista ja tiimitietoisuutta. Suunnittele harjoituksia, jotka palkitsevat selittämistä ja ymmärrystä sekä vikojen määrää.
Mistä aloittaa
Valitse yksi muutostyyppi, jota tiimisi tarkastelee usein. Kirjoita suorituskykyselvitys, pyydä vanhempaa insinööriä valmistelemaan yksi muutos, jossa on kolme tai neljä huolenaihetta, ja laadi kolmen kriteerin arviointikehys asteikolla 0-2 ja luettelolla kriittisistä virheistä. Testaa sitä pienryhmässä ja vertaa sitten heidän seuraavia todellisia tarkastelujaan lähtötasoon.
Jos haluat nähdä, kuinka arviointiharjoitus voitaisiin suorittaa livenä oman tiimisi kanssa ja käyttää sitä uudelleen omaan tahtiin jälkeenpäin, tutustu AhaSlides-sivustoon.
