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ājumi kas apzināti attīsta šo prasmi, nevis cer, ka recenzenti to paņems no rindas. Tajā ir aplūkota veiktspējas problēma, diagnosticējamās nepilnības, sagatavošanās un prakses strukturēšana, viens praktiski izstrādāts piemērs un tas, kā pārbaudīt, vai prasme tiek piemērota reālām recenzijām. Pirms izmantojat vecākos inženierus, lai tie validē 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 meklēšanu tālāk par 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 (Bačelli 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 dizainu izpratnes veicināšanai, nevis kā likmi savai komandai.
Google publicētais pārskatīšanas standarts norāda to pašu. Tas norāda recenzentiem atbalstīt izmaiņu apstiprināšanu, 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 inženierprakses). Abos avotos pārskatīšana tiek raksturota kā vieta, kur tiek izteikts un nodots spriedums. Tieši to jūsu vingrinājumos 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šana. Pirms darba sākšanas pārbaudiet, kas recenzentiem ir nepieciešams: komandas pārskatīšanas kontrolsaraksts, projektēšanas principi, uz kuriem tā balstās, un tas, kā nolasīt atšķirības jūsu instrumentos. Saglabājiet šo uzdevumu īsu un patstāvīgu. Atsaukuma 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 sākotnējiem jautājumiem: 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 ar nelielu drukas kļūdu un lielāku kļūdu, un pēc tam to pārskata kā kolēģis (CodeRefinery, Koda pārskatīšanas praktizēšana). Veidojiet savējo no savas koda bāzes, lai konvencijas un kompromisi būtu reāli.
Atsauksmes. Saistiet to 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 sniegtā informācija 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 bez ievērības. 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.
Lieta. 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 viņu bažas un pasaka, kas viņam būtu jāzina pirms apstiprināšanas.
Pirmais mēģinājums. "Izskatās labi, tests izturēja. 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 mēģinājums vēlreiz. Koordinators jautā: kādas izmaiņas šajā funkcijā nākotnē varētu apdraudēt tās darbību? 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ē daļējus ar būtiskiem izlaidumiem, un 2 nozīmē pilnīgus un pamatotus atbilstoši saskaņotajiem kritērijiem. Definējiet kritiskas kļūdas atsevišķi, 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āde 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 mākslīgā intelekta rakstītā kodā, skatiet mūsu pavadošo rokasgrāmatu vietnē Mākslīgā intelekta ģenerēta koda pārskatīšanas apmācībaŠī ziņa ir par ģenerētās produkcijas auditu. Šī ziņa ir 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.
