Arendaja avab pull-requesti, mis lisab kassateenusele allahindluse arvutuse. Testid läbivad ja erinevus on lühike. Retensent kiidab selle kahe minutiga heaks ja lisab märge "LGTM". Kolm kuud hiljem peab meeskonnakaaslane sama funktsiooni muutma ja avastab, et see segab hinnakujundusreegleid, ümardamist ja andmebaasile juurdepääsu ühes kohas. Keegi ei saa kindlalt öelda, mida see teha tohib.
See on illustreeriv stsenaarium, mitte dokumenteeritud juhtum. See näitab, mida vastastikuse koodi ülevaatamise tulemused peavad olema, kui see toimib õppetegevusena: retsensent, kes suudab näha usutavat muutust, märgata probleemi, mis pole veel viga, ja selgitada seda viisil, mille alusel autor saab tegutseda.
See juhend on mõeldud inseneriõppe juhtidele ja insenerijuhtidele. See näitab, kuidas kujundada koodi ülevaatamise harjutused mis arendavad seda oskust sihipäraselt, selle asemel, et loota, et retsensendid selle järjekorrast üles korjavad. See hõlmab jõudlusprobleemi, diagnoositavaid lünki, ettevalmistuse ja harjutamise struktureerimist, ühte praktilist näidet ning seda, kuidas kontrollida oskuse ülekandumist reaalsetesse ülevaatustesse. Enne vanemate inseneride kasutamist laske iga juhtum, defekt ja kriteerium valideerida.
Mis on koodiülevaatuse harjutused?
Koodiülevaatuse harjutused on struktureeritud harjutusülesanded, mille käigus arendaja vaatab üle ettevalmistatud muudatuse, selgitab oma leide ja nende olulisust ning saab tagasisidet selgituse kvaliteedi kohta. Need erinevad teie meeskonna igapäevastest ülevaadetest. Muudatus valitakse ette, sellega seotud probleemid on teada ja eesmärk on ülevaataja täiustamine, mitte muudatuse edastamine.
Quick faktid
| Küsimus | Lühike vastus |
|---|---|
| Mis on ülesanne? | Selgitage ülevaate tulemusi ja andke tagasisidet, mille põhjal autor saab tegutseda. |
| Mis punktisumma sa saad? | Leidude täpsus ja selgituse kasulikkus. |
| Kas defektide loendamine on piisav? | Ei. Arvustused on enamat kui lihtsalt vead, seega harjutus, mis premeerib ainult vigade arvu, treenib valet harjumust. |
| Mis on kognitiivne nõudlus? | Analüüsi ja hinda disaini ning seejärel loo parem ettepanek. |
| Kes kinnitab juhtumi õigsust? | Insenerijuht või vaneminsener, kellele kuulub koodibaas. |
| Mida harjutused ei paranda? | Ülevaatamise aeg, ebaselge omandiõigus ja surve kiireks ühinemiseks. |
| Kuidas sa tead, et see toimis? | Uus, nähtamatu muudatus, mida on hinnatud kokkulepitud kriteeriumide alusel, millele lisandub tegelike ülevaadete järelkontroll. |
1. Kirjeldage jõudlusprobleemi
Alusta ülesandega ühes lauses: muudatuse korral selgitab retsensent, mida ta leidis, miks see on oluline ja mida autor sellega teha saaks. Oluline sõna on „selgitada“. Probleemi märkamine on pool oskusest. Teine pool on selle väljaütlemine nii, et erineva vaatega kolleeg saaks sellest aru, kaaluda ja tegutseda.
Kaasaegse koodiülevaatuse uuringud toetavad veaotsingu kõrvalt vaatamist. Microsofti uuringus jälgisid, intervjueerisid ja küsitlesid Bacchelli ja Bird arendajaid ja juhte. Nad leidsid, et vigade leidmine oli endiselt peamine ülevaatuse motivatsioon, kuid ülevaatused keskendusid vigadele vähem, kui inimesed ootasid. Need pakkusid ka muid eeliseid, nagu teadmiste jagamine, meeskonna teadlikkus ja alternatiivsed lahendused, ning teadlased kirjeldasid koodi ja muudatuste mõistmist ülevaatuse põhiaspektina (Bacchelli ja Bird, ICSE 2013). See on ühe ettevõtte meeskondade uuring, seega kasutage seda põhjusena arusaamise kujundamiseks, mitte oma meeskonna määramiseks.
Google'i avaldatud ülevaatusstandard osutab samale seisukohale. See ütleb ülevaatajatele, et nad peaksid muudatuse heaks kiitma siis, kui see kindlasti parandab koodi üldist seisukorda, isegi kui see pole täiuslik, ning see ütleb, et ülevaatamine võib arendajatele midagi uut õpetada, seega on teretulnud kommentaarid, mis aitavad kellelgi õppida (Google'i inseneritavad). Mõlemad allikad kirjeldavad arvustust kui kohta, kus otsustusvõimet rakendatakse ja edasi antakse. Seda peaksid teie harjutused harjutama.
2. Õppimis- ja kontekstilünga diagnoosimine
Võrdle ülesannet sellega, mida sinu praegune programm harjutab ja hindab.
- Kas praegune praktika kasutab tegelikku ülesannet? Kui uued arvustajad õpivad stiilijuhendit lugedes ja seejärel reaalajas pull requeste üle vaadates, harjutavad nad päris töö peal, kus pole kohta, kus eksida. Kui hindamine on arvustuse etiketi viktoriin, mõõdab see reeglite meeldejätmist, mitte oskust neid muudatusele rakendada.
- Mis on kognitiivne nõudlus? Bloomi taksonoomia uuendatud versioonis toimub disaini terviklikkuse hindamine ja kompromisside kaalumine analüüsi ja hindamise tasandil ning parema struktuuri pakkumine jõuab loomise tasandile. Kui teie harjutused küsivad ainult "mida see kood teeb?", siis piirduvad need mõistmisega. Meie juhend ... õppetegevuste sobitamine Bloomi taksonoomiaga näitab, kuidas tegevust tasemele sobitada.
- Kas peale oskuste on takistuseks midagi muud? Kontrollige ülevaatamiseks kuluvat aega, tööriistu, vastutust ja meeskonna norme. Kui retsensentidel on iga päringu jaoks viis minutit, ei anna ükski harjutus läbimõeldud selgitust. Kui autorid võtavad iga kommentaari kriitikana, pehmendavad retsensendid oma järeldusi seni, kuni nad enam midagi ei ütle. Teatage neist põhjustest inimestele, kes saavad need parandada.
3. Kujunduse ettevalmistamine, harjutamine ja tagasiside
Andke igale etapile eraldi ülesanne.
Ettevalmistus. Enne alustamist kontrollige, mida arvustajad vajavad: meeskonna ülevaatuse kontroll-lehte, disainipõhimõtteid, millele see tugineb, ja seda, kuidas lugeda teie tööriistade erinevust. Hoidke see omas tempos ja lühike. Tagasikutsumise kontroll kinnitab ainult eeltingimusi ja see ei ole tõend selle kohta, et keegi oskab üle vaadata.
Praktika. Kasutage ettevalmistatud muudatusi, milles on väike arv erinevat tüüpi probleeme: õigsusviga, hooldatavuse probleem, näiteks segatud vastutus avanäites, ebaselge nimi või puuduv test ja osa korras koodist. Paluge retsensendil kirjutada kommentaar, mida ta jätaks, seadke probleemid järjekorda ja öelge, millist lisateavet ta sooviks. CodeRefinery praktiline õppetund näitab skeemi: inimesed avavad pull-requesti, mis sisaldab väikest trükiviga ja suuremat viga, ning seejärel vaatavad selle partnerina üle (CodeRefinery, Koodiülevaate harjutamine). Ehita enda oma koodibaasist, et konventsioonid ja kompromissid oleksid reaalsed.
Tagasiside. Seo see arvustaja tehtud otsustega. „Sa märkasid ümardamisprobleemi, aga sinu kommentaaris öeldi, et „see näeb vale välja”, aga ei täpsustatud, milline sisend seda rikub” on kasulikum kui „leiti 2/4”.
Otseülekanne või asünkroonne arvustus? Otseülekanne annab kõige rohkem väärtust siis, kui mure on mitmetähenduslik ja retsensendid õpivad vaneminseneri selgitustest, miks nad mure tõstataksid või sellest lahti ei annaks. Asünkroonsest arvustusest piisab kommentaaride võrdlemiseks annoteeritud eksperdihinnanguga.
4. Töötage läbi realistlik näide
Illustreeriv. Insenerijuht peaks enne kasutamist juhtumi ja vastusekriteeriumid valideerima.
Juhul. Muudatus lisab kassateenusele allahindluse arvutuse. See läbib kõik testid. Ühes funktsioonis rakendab see protsentuaalseid ja fikseeritud allahindlusi, ümardab tulemuse, kirjutab andmebaasi ja saadab sündmuse. Sellel on üks test, ühe protsendilise allahindluse jaoks.
Ülesanne. Retensent kirjutab kommentaarid, mida retsensendid jätaksid, järjestab nende mured ja ütleb, mida nad peaksid enne heakskiitmist teadma.
Esimene katse. „Näeb hea välja, test läbib. Võib-olla jagaks selle pooleks?“ Retensent on midagi märganud, aga pole öelnud, mida, miks see oluline on või mida teha. Autor ei saa selle põhjal midagi ette võtta.
Tagasiside ja proovi uuesti. Koolitaja küsib: milline oleks selle funktsiooni tulevase muutmise korral rikke oht? Mida paluksite autoril enne kinnitamist lisada? Uuesti proovimisel küsitakse iga mure kohta konkreetset kommentaari koos põhjenduse ja ettepanekuga.
Tugevam katse. „Funktsioon rakendab kahte tüüpi allahindlust: ümardab, salvestab ja avaldab sündmuse, seega ümardamise muutmine võib muuta seda, mida me salvestame ja mida me samal ajal avaldame. Ma paluksin, et hinnakujundusreeglid viiakse puhtasse funktsiooni, mida saaksime iseseisvalt testida. Üksik test hõlmab ainult protsentuaalset allahindlust. Ma paluksin fikseeritud allahindlust ja tellimust, mis viib summa nullini. Ma pole kindel, kas sündmus peaks käivituma, kui summa on null, seega küsiksin autorilt.“ Pange tähele, et see kommentaar nimetab mure, annab põhjuse, teeb konkreetse ettepaneku ja märgib, mida retsensent ei tea.
5. Hinnake võimekust ja plaanige üleandmist
Võimekuse tõendiks on uue muudatuse tegemine, mida retsensent pole varem näinud. Hinnake leidude täpsust ja selgituse kasulikkust. Lihtne rubriik kasutab kriteeriumi kohta skaalat 0 kuni 2:
| Kriteerium | Vaadeldavad tõendid |
|---|---|
| Ülesande täitmine | Leiab muudatuses esinevad olulised murekohad ja dokumenteerib igaühe kohta tõendid. |
| Põhjendus | Selgitab, miks iga mure on oluline, pakub alternatiivi ja ütleb, mis jääb ebaselgeks. |
| Piirid | Järgib meeskonna arvustusreegleid ja küsib abi või teavet, kui autoriteet või kontekst on puudulikud. |
Ankrud: 0 tähendab puudumist või toetuseta, 1 tähendab osalist oluliste puudujääkidega ja 2 tähendab täielikku ja kokkulepitud kriteeriumide alusel põhjendatud. Määrake kriitilised vead eraldi, näiteks muudatuse kinnitamine andmete kadumise riskiga, nii et hea üldskoor ei saa seda varjata. Kohandage kriteeriume koos insenerijuhiga; see rubriik on algne ettepanek, mitte valideeritud valmisoleku standard. Lisateavet hindamispõhjenduse kohta leiate meie juhendist interaktiivse praktika kujundamine kasuliku tagasiside abil.
Planeeri üleminek. Pärast harjutust kontrolli paar nädalat hiljem samade kriteeriumide alusel valimit retsensendi tegelikest arvustustest. Võrdle enne koolitust võetud lähtetasemega ning määra eelnevalt kindlaks populatsioon ja ajastus. Enne harjutuste arvestamist vaata üle samal perioodil toimunud muud muudatused, näiteks uus hindamisvahend või personalivahetus.
6. Tehke harjutust otseülekandega või omas tempos AhaSlides'i abil
Harjutust saab läbi viia töötoas või lasta retsensentidel see iseseisvalt läbi töötada. Näidake ettevalmistatud muudatust reaalajas sessioonil ja kasutage aruteluks interaktiivseid slaide:
- Valige vastus küsimusele „millise mure tõstataksite esimesena?“, kus valikutena on ära toodud külvatud mured. Enne oma edetabeli avaldamist näidake levikut.
- Avatud lõpetatud „kirjuta kommentaar, mille sa jätaksid“. Arvustajad saavad oma sõnastust teiste omaga võrrelda, mis näitabki selgitamisoskust.
- Hindamisskaala küsimusele „kui tõsine see on?“, et grupp saaks näha, kus hinnangud erinevad, ja arutada, miks.
Retsensendid, kes ei saa osaleda, saavad kasutada sama järjestust omas tempos, kuvades iga vastuse järel kommenteeritud eksperdihinnangu. Käsitlege kõiki väiteid koodi käivitamise, integratsioonide või tehisintellekti funktsioonide kohta kinnitamata väidetena enne, kui olete neid oma materjaliga proovinud.
Kui koolitate arvustajaid ka tehisintellekti abil kirjutatud koodi osas, vaadake meie kaasjuhendit aadressil Tehisintellekti loodud koodi ülevaatamise koolitusSee postitus räägib genereeritud väljundi auditeerimisest. See postitus räägib sellest, kuidas inimesed üksteise tööd üle vaatavad ja kuidas nad oma leide selgitavad.
Piirangud, mis võivad jääda
- Ülevaatamise aeg. Läbimõeldud kommentaar võtab kauem aega kui "LGTM" ja tähtajad suruvad lühema versiooni poole.
- Meeskonna normid. Kui tagasisidet tõlgendatakse isikliku kriitikana, siis retsensendid pehmendavad oma järeldusi või loobuvad neist.
- Juhtumi katvus. Üks harjutus näitab mitut tüüpi mureküsimusi. Skoor ei kirjelda retsensendi otsustusvõimet üldiselt.
- Ülekanne. Töötoas esinemine ei ole sama, mis tihedas järjekorras esinemine, seega kontrollige ka tegelikke arvustusi.
Nimetage need sponsoritele varakult ja planeerige eraldi parandused. Harjutused parandavad seda, mida arvustaja näeb ja selgitab. Need ei loo aega ega norme.
Korduma kippuvad küsimused
Mis on koodiülevaatuse harjutused?
Need on ettevalmistatud harjutusülesanded, mille käigus arendaja vaatab üle muudatuse, millel on teadaolevad probleemid, kirjutab kommentaarid, mida ta ise jätaks, ning saab tagasisidet täpsuse ja kasulikkuse kohta. Eesmärk on arendada ülevaataja oskusi, mitte muudatust ellu viia.
Kuidas hinnata, kas retsensendi otsustusvõime on paranenud?
Esitage uus muudatus, mida nad pole näinud, ja hinnake leide ning selgitust kokkulepitud kriteeriumide alusel. Seejärel kontrollige mõni nädal hiljem päris arvustuste valimit. Arvustusreeglite viktoriin kinnitab ainult eeltingimusi.
Kas vastastikuse koodi läbivaatamine on peamiselt vigade leidmine?
Vigade leidmine on endiselt peamine motivaator, kuid üks Microsofti uuring näitas, et arvustused keskendusid oodatust vähem vigadele ning soodustasid teadmiste jagamist ja meeskonna teadlikkust. Kujundage harjutusi, mis premeerivad selgitamist ja mõistmist lisaks vigade arvule.
Kust alustada
Vali üks muudatuse liik, mida su meeskond sageli üle vaatab. Kirjuta tulemuslikkuse aruanne, palu vaneminseneril ette valmistada üks muudatus kolme või nelja põhiprobleemiga ning koosta kolmekriteeriumiline rubriik 0-st 2-ni skaala ja kriitiliste vigade loeteluga. Testi seda väikeses rühmas ja võrdle seejärel nende järgmisi tegelikke ülevaatusi algtasemega.
Et näha, kuidas ülevaateharjutust saaks teie enda meeskonnaga otseülekandes läbi viia ja hiljem iseseisvalt uuesti kasutada, uurige AhaSlides'i.
