Izstrādātājs atver pieprasījumu, kas pievieno atlaides aprēķinu norēķinu pakalpojumam. Testi ir veiksmīgi, un atšķirība ir neliela. Recenzents to apstiprina divās minūtēs ar "LGTM". Trīs mēnešus vēlāk komandas biedram ir jāmaina tā pati funkcija, un viņš atklāj, ka tā vienuviet sajauc cenu noteikšanas noteikumus, noapaļošanu un piekļuvi datubāzei. Neviens nevar droši pateikt, ko ir atļauts darīt.
Šis ir ilustratīvs scenārijs, nevis dokumentēts incidents. Tas parāda, ko vienaudžu koda pārskatīšanai ir jārada, kad tā darbojas kā mācību aktivitāte: recenzents, kurš var saskatīt ticamas izmaiņas, pamanīt problēmu, kas vēl nav kļūda, un izskaidrot to tādā veidā, lai autors varētu rīkoties.
Šī rokasgrāmata ir paredzēta inženiertehnisko iespēju vadītājiem un inženiertehniskajiem vadītājiem. Tajā parādīts, kā izstrādāt koda pārskatīšanas vingrinājumus , kas apzināti attīsta šo prasmi, nevis cerēt, ka recenzenti to paņems no rindas. Tajā ir aplūkota veiktspējas problēma, diagnosticējamie trūkumi, sagatavošanās un prakses strukturēšana, viens praktiski izstrādāts piemērs un tas, kā pārbaudīt, vai prasme tiek izmantota reālās pārskatīšanās. Pirms izmantojat vecākajiem inženieriem, lai viņi validētu katru gadījumu, defektu un kritēriju.
Kas ir koda pārskatīšanas vingrinājumi?
Koda pārskatīšanas vingrinājumi ir strukturēti praktiski uzdevumi, kuros izstrādātājs pārskata sagatavotu izmaiņu, paskaidro, ko viņš atrada un kāpēc tas ir svarīgi, un saņem atsauksmes par šī skaidrojuma kvalitāti. Tie atšķiras no pārskatiem, ko jūsu komanda veic katru dienu. Izmaiņa tiek izvēlēta iepriekš, tajā esošās problēmas ir zināmas, un mērķis ir uzlabot pārskatītāju, nevis nosūtīt izmaiņas.
Īsi fakti
| jautājums | Īsā atbilde |
|---|---|
| Kāds ir uzdevums? | Izskaidrojiet pārskata konstatējumus un sniedziet atsauksmes, uz kurām autors var reaģēt. |
| Kādu rezultātu tu iegūsti? | Secinājumu precizitāte un skaidrojuma lietderība. |
| Vai pietiek ar defektu skaitīšanu? | Nē. Atsauksmes ir kas vairāk par defektiem, tāpēc vingrinājums, kas atalgo tikai kļūdu skaitu, trenē nepareizu ieradumu. |
| Kāda ir kognitīvā prasība? | Analizējiet un novērtējiet dizainu un pēc tam izveidojiet labāku ieteikumu. |
| Kas apstiprina lietu? | Inženierzinātņu vadītājs vai vecākais inženieris, kuram pieder koda bāze. |
| Ko vingrinājumi nevar labot? | Pārskatīšanas laiks, neskaidras īpašumtiesības un spiediens uz ātru apvienošanos. |
| Kā tu zini, ka tas nostrādāja? | Jaunas, neredzamas izmaiņas, kas pārskatītas atbilstoši saskaņotiem kritērijiem, kā arī reālu pārskatu izpildes pārbaude. |
1. Aprakstiet veiktspējas problēmu
Sāciet ar uzdevumu vienā teikumā: ņemot vērā izmaiņas, recenzents paskaidro, ko viņš ir atradis, kāpēc tas ir svarīgi un ko autors varētu darīt lietas labā. Svarīgākais vārds ir “izskaidrot”. Problēmas pamanīšana ir puse no prasmes. Otra puse ir tās pateikšana tā, lai kolēģis ar atšķirīgu viedokli to varētu saprast, apsvērt un rīkoties.
Pētījumi par mūsdienu koda pārskatīšanu atbalsta centienus meklēt plašāk nekā tikai kļūdu meklēšanu. Pētījumā Microsoft Bakelli un Bērds novēroja, intervēja un aptaujāja izstrādātājus un vadītājus. Viņi atklāja, ka defektu atrašana joprojām bija galvenā pārskatīšanas motivācija, taču pārskatīšana bija mazāk vērsta uz defektiem, nekā cilvēki gaidīja. Tā sniedza arī citus ieguvumus, piemēram, zināšanu apmaiņu, komandas izpratni un alternatīvus risinājumus, un pētnieki raksturoja koda un izmaiņu izpratni kā galveno pārskatīšanas aspektu ( Bakeli un Bērds, ICSE 2013 ). Tas ir viena uzņēmuma komandu pētījums, tāpēc izmantojiet to kā iemeslu, lai izstrādātu izpratni, nevis kā likmi savām komandām.
Google publicētais pārskatīšanas standarts norāda uz to pašu. Tas liek recenzentiem dot priekšroku izmaiņu apstiprināšanai, ja tās noteikti uzlabo koda vispārējo stāvokli, pat ja tas nav perfekts, un tajā teikts, ka pārskatīšana var iemācīt izstrādātājiem kaut ko jaunu, tāpēc komentāri, kas palīdz kādam mācīties, ir laipni gaidīti ( Google Engineering Practices ). Abos avotos pārskatīšana tiek raksturota kā vieta, kur tiek izteikts un nodots spriedums. Tieši to jūsu vingrinājumiem vajadzētu atkārtot.
2. Diagnosticējiet mācīšanās un konteksta nepilnības
Salīdziniet uzdevumu ar to, ko jūsu pašreizējā programma praktizē un novērtē.
- Vai pašreizējā praksē tiek izmantots reālais uzdevums? Ja jauni recenzenti mācās, lasot stila rokasgrāmatu un pēc tam pārskatot tiešraides pieprasījumus, viņi praktizējas reālā darbā, kur nav drošas vietas, kur kļūdīties. Ja novērtēšana ir tests par recenzēšanas etiķeti, tā mēra noteikumu atcerēšanos, nevis spēju tos pielietot izmaiņām.
- Kāda ir kognitīvā prasība? Saskaņā ar pārskatīto Blūma taksonomiju, dizaina pamatotības novērtēšana un kompromisu izvērtēšana notiek analīzes un novērtēšanas līmenī, savukārt labākas struktūras ierosināšana sasniedz izveides līmeni. Ja jūsu vingrinājumos tiek jautāts tikai "ko šis kods dara?", tie apstājas pie izpratnes. Mūsu ceļvedis mācību aktivitāšu saskaņošana ar Blūma taksonomiju parāda, kā saskaņot aktivitāti ar līmeni.
- Vai kaut kas cits, nevis prasmes, traucē? Pārbaudiet pārskatīšanas laiku, rīkus, atbildību un komandas normas. Ja recenzentiem ir piecas minūtes katram pieprasījumam, neviens vingrinājums neradīs pārdomātu skaidrojumu. Ja autori uztvers katru komentāru kā kritiku, recenzenti mīkstinās savus secinājumus, līdz vairs neko neteiks. Ziņojiet par šiem cēloņiem cilvēkiem, kuri tos var novērst.
3. Dizaina sagatavošana, prakse un atgriezeniskā saite
Piešķiriet katram posmam atsevišķu uzdevumu.
Sagatavošanās. Pirms sākat darbu, pārbaudiet, kas recenzentiem ir nepieciešams: komandas pārskatīšanas kontrolsaraksts, projektēšanas principi, uz kuriem tā balstās, un kā nolasīt atšķirības jūsu instrumentos. Saglabājiet šo uzdevumu īsu un patstāvīgu. Atsaukumu pārbaude apstiprina tikai priekšnosacījumus, un tā nav pierādījums tam, ka kāds var veikt pārskatīšanu.
Prakse. Izmantojiet sagatavotas izmaiņas ar nelielu skaitu dažādu veidu iepriekšēju problēmu: pareizības kļūda, uzturēšanas problēma, piemēram, jauktā atbildība sākotnējā piemērā, neskaidrs nosaukums vai trūkstošs tests, un nedaudz laba koda. Palūdziet recenzentam uzrakstīt komentāru, ko viņš atstātu, sarindot problēmas un norādīt, kādu papildu informāciju viņš vēlētos. CodeRefinery praktiskajā nodarbībā ir parādīta forma: cilvēki atver pieprasījumu, kurā ir neliela drukas kļūda un lielāka kļūda, un pēc tam to pārskata kā kolēģis ( CodeRefinery, Koda pārskatīšanas praktizēšana ). Izveidojiet savu no savas koda bāzes, lai konvencijas un kompromisi būtu reāli.
Atsauksmes. Saistiet tās ar recenzenta lēmumiem. “Jūs pamanījāt noapaļošanas problēmu, bet jūsu komentārā bija teikts “tas izskatās nepareizi”, nenorādot, kāds ievades veids to pārkāpj” ir noderīgāks nekā “atrasti 2 no 4”.
Tiešraides ievade vai asinhrona pārskatīšana? Tiešraides ievade sniedz vislielāko vērtību, ja problēma ir neskaidra, un recenzenti mācās, dzirdot vecākā inženiera teikto, kāpēc viņi to izvirzītu vai atstātu novārtā. Asinhrona pārskatīšana ir pietiekama, lai salīdzinātu komentārus ar anotētu eksperta pārskatu.
4. Izstrādājiet reālistisku piemēru
Ilustratīvi. Inženiertehniskajam vadītājam pirms lietošanas ir jāapstiprina gadījums un atbildes kritēriji.
Gadījums. Izmaiņas pievieno atlaides aprēķinu norēķinu pakalpojumam. Tas iztur testus. Vienā funkcijā tas piemēro procentuālās un fiksētās atlaides, noapaļo rezultātu, ieraksta datubāzē un nosūta notikumu. Tam ir viens tests vienai procentuālajai atlaidei.
Uzdevums. Recenzents uzraksta komentārus, ko recenzents atstātu, sarindo recenzentu bažas un pasaka, kas viņam būtu jāzina pirms apstiprināšanas.
Pirmais mēģinājums. "Izskatās labi, tests sekmīgi nokārtots. Varbūt sadaliet to?" Recenzents ir kaut ko pamanījis, bet nav pateicis, ko, kāpēc tas ir svarīgi vai ko darīt. Autors nevar rīkoties.
Atsauksmes un atkārtots mēģinājums. Koordinators jautā: kādas izmaiņas šajā funkcijā nākotnē varētu radīt darbības traucējumus? Ko jūs lūgtu autoram pievienot pirms apstiprināšanas? Atkārtotā mēģinājuma laikā tiek lūgts sniegt konkrētu komentāru par katru problēmu, norādot iemeslu un ieteikumu.
Spēcīgāks mēģinājums. "Funkcija piemēro divu veidu atlaides: noapaļo, saglabā un publicē notikumu, tāpēc noapaļošanas izmaiņas varētu mainīt to, ko mēs vienlaikus glabājam un ko publicējam. Es lūgtu, lai cenu noteikšanas noteikumi tiktu pārvietoti uz tīru funkciju, ko mēs varētu pārbaudīt atsevišķi. Vienīgais tests aptver tikai procentuālo atlaidi. Es lūgtu fiksētu atlaidi un pasūtījumu, kas kopsummu samazina līdz nullei. Es neesmu pārliecināts, vai notikumam ir jāaktivizējas, kad kopsumma ir nulle, tāpēc es jautātu autoram." Ievērojiet, ka šajā komentārā ir nosaukta problēma, sniegts iemesls, sniegts konkrēts ieteikums un norādīts, ko recenzents nezina.
5. Novērtējiet spējas un plānojiet nodošanu
Spēju pierādījums ir sniegums, veicot jaunas izmaiņas, kuras recenzents vēl nav redzējis. Novērtējiet secinājumu precizitāti un skaidrojuma lietderību. Vienkāršā rubrikā katram kritērijam tiek izmantota skala no 0 līdz 2:
| Kritērijs | Novērojami pierādījumi |
|---|---|
| Uzdevuma izpilde | Atrod būtiskās bažas par izmaiņām un reģistrē pierādījumus katrai no tām. |
| Pamatojums | Izskaidro, kāpēc katra problēma ir svarīga, piedāvā alternatīvu un pasaka, kas joprojām nav skaidrs. |
| Robežas | Ievēro komandas pārskatīšanas noteikumus un lūdz palīdzību vai informāciju, ja trūkst autoritātes vai konteksta. |
Enkuri: 0 nozīmē, ka nav vai nav atbalstīti, 1 nozīmē, ka ir daļēji ar būtiskiem izlaidumiem, un 2 nozīmē, ka ir pilnīgi un pamatoti atbilstoši saskaņotajiem kritērijiem. Atsevišķi definējiet kritiskās kļūdas, piemēram, apstiprinot izmaiņas ar datu zuduma risku, lai labs kopējais vērtējums to nevarētu slēpt. Pielāgojiet kritērijus kopā ar inženiertehnisko vadītāju; šī rubrika ir sākuma priekšlikums, nevis apstiprināts gatavības standarts. Plašāku informāciju par vērtēšanas pamatojumu skatiet mūsu ceļvedī par interaktīvas prakses izstrādi ar noderīgu atgriezenisko saiti.
Plānojiet pārcelšanu. Pēc vingrinājuma dažas nedēļas vēlāk pārbaudiet recenzenta reālo atsauksmju izlasi, izmantojot tos pašus kritērijus. Salīdziniet ar sākotnējo līmeni, kas iegūts pirms apmācības, un iepriekš definējiet populāciju un laiku. Pirms vingrinājumu ieskaitīšanas apsveriet citas izmaiņas, kas notikušas tajā pašā periodā, piemēram, jauns pārskatīšanas rīks vai personāla izmaiņas.
6. Veiciet vingrinājumu tiešraidē vai savā tempā, izmantojot AhaSlides
Jūs varat vadīt vingrinājumu seminārā vai ļaut recenzentiem to paveikt patstāvīgi. Tiešraides sesijā parādiet sagatavotās izmaiņas un diskusijai izmantojiet interaktīvus slaidus:
- Izvēlieties atbildi uz jautājumu "kuru bažas jūs izvirzītu vispirms?", norādot sākotnējās bažas kā iespējas. Pirms atklājat savu rangu, parādiet izplatību.
- Atvērts beigas par "uzrakstiet komentāru, ko jūs atstātu". Recenzenti var salīdzināt savu formulējumu ar citu formulējumu, un tieši šeit izpaužas skaidrošanas prasmes.
- Reitinga skala par "cik nopietni tas ir?", lai grupa varētu redzēt, kur spriedumi atšķiras, un pārrunāt, kāpēc.
Recenzentiem, kuri nevar piedalīties, to pašu secību var izmantot patstāvīgi, pēc katras atbildes parādot anotētu eksperta atsauksmi. Jebkuru apgalvojumu par koda izpildi, integrācijām vai mākslīgā intelekta funkcijām uzskatiet par neapstiprinātu, kamēr neesat to izmēģinājis ar savu materiālu.
Ja apmācāt arī recenzentus darbam ar mākslīgā intelekta rakstītu kodu, skatiet mūsu pavadošo rokasgrāmatu par mākslīgā intelekta ģenerēta koda pārskatīšanas apmācību . Minētajā ierakstā ir runa par ģenerētās izvades auditu. Šajā ierakstā ir runa par to, kā cilvēki pārskata viens otra darbu un kā viņi paskaidro savus atklājumus.
Ierobežojumi, kas var palikt
- Pārskatīšanas laiks. Pārdomāts komentārs prasa ilgāku laiku nekā "LGTM", un termiņi stumj īsākas versijas virzienā.
- Komandas normas. Ja atsauksmes tiek uztvertas kā personiska kritika, recenzenti mīkstinās vai atteiksies no saviem secinājumiem.
- Lietas pārklājums. Viens vingrinājums parāda dažus bažu veidus. Vērtējums neraksturo recenzenta spriedumu kopumā.
- Pārskaitījums. Veiktspēja darbnīcā nav tas pats, kas veiktspēja noslogotā rindā, tāpēc pārbaudiet arī reālas atsauksmes.
Nosauciet tos sponsoriem jau laikus un ieplānojiet atsevišķus labojumus. Vingrinājumi uzlabo to, ko recenzents var redzēt un izskaidrot. Tie nerada laiku vai normas.
Biežāk uzdotie jautājumi
Kas ir koda pārskatīšanas vingrinājumi?
Tie ir sagatavoti praktiski uzdevumi, kuros izstrādātājs pārskata izmaiņas ar zināmām problēmām, raksta komentārus, ko viņš atstātu, un saņem atsauksmes par precizitāti un lietderību. Mērķis ir attīstīt recenzenta prasmes, nevis nosūtīt izmaiņas.
Kā jūs novērtējat, vai recenzenta spriestspēja ir uzlabojusies?
Sniedziet jaunas izmaiņas, ko viņi vēl nav redzējuši, un novērtējiet konstatējumus un skaidrojumu, izmantojot saskaņotos kritērijus. Pēc tam dažas nedēļas vēlāk pārbaudiet reālu atsauksmju izlasi. Viktorīna par atsauksmju noteikumiem apstiprina tikai priekšnosacījumus.
Vai vienaudžu koda pārskatīšana galvenokārt ir paredzēta kļūdu atrašanai?
Defektu atrašana joprojām ir galvenā motivācija, taču vienā Microsoft pētījumā atklājās, ka pārskati bija mazāk veltīti defektiem nekā gaidīts, un tie arī nodrošināja zināšanu apmaiņu un komandas izpratni. Izstrādājiet vingrinājumus, kas atalgo gan skaidrojumu un izpratni, gan defektu skaitu.
Kur sākt
Izvēlieties viena veida izmaiņas, kuras jūsu komanda bieži pārskata. Uzrakstiet snieguma pārskatu, palūdziet vecākajam inženierim sagatavot vienu izmaiņu ar trim vai četrām galvenajām bažām un izveidojiet trīs kritēriju rubriku ar skalu no 0 līdz 2 un kritisko kļūdu sarakstu. Izmēģiniet to nelielā grupā un pēc tam salīdziniet viņu nākamos reālos pārskatus ar sākotnējo līmeni.
Lai redzētu, kā pārskatīšanas vingrinājums varētu notikt tiešraidē ar jūsu komandu un pēc tam tikt atkārtoti izmantots patstāvīgi, izpētiet AhaSlides.
