Programer otvara zahtjev za povlačenjem (pull request) koji dodaje izračun popusta usluzi plaćanja. Testovi prolaze i razlika je kratka. Recenzent ga odobrava za dvije minute s "LGTM". Tri mjeseca kasnije, kolega iz tima treba promijeniti istu funkciju i otkriva da miješa pravila određivanja cijena, zaokruživanja i pristupa bazi podataka na jednom mjestu. Nitko ne može sa sigurnošću reći što smije raditi.
Ovo je ilustrativni scenarij, a ne dokumentirani incident. Pokazuje što recenzija koda od strane kolega mora proizvesti kada funkcionira kao aktivnost učenja: recenzenta koji može vidjeti uvjerljivu promjenu, uočiti problem koji još nije greška i objasniti ga na način na koji autor može reagirati.
Ovaj vodič je namijenjen voditeljima inženjerskih osposobljavanja i inženjerskim menadžerima. Pokazuje kako dizajnirati vježbe pregleda koda koji namjerno grade tu vještinu, umjesto da se nadaju da će je recenzenti preuzeti s liste čekanja. Obuhvaća problem izvedbe, nedostatke koje treba dijagnosticirati, kako strukturirati pripremu i praksu, jedan radni primjer i kako provjeriti prenosi li se vještina na stvarne recenzije. Neka viši inženjeri potvrde svaki slučaj, nedostatak i kriterij prije nego što ga upotrijebite.
Što su vježbe pregleda koda?
Vježbe pregleda koda su strukturirani praktični zadaci u kojima programer pregledava pripremljenu promjenu, objašnjava što je pronašao i zašto je to važno te dobiva povratne informacije o kvaliteti tog objašnjenja. Razlikuju se od pregleda koje vaš tim radi svaki dan. Promjena se odabire unaprijed, problemi u njoj su poznati, a cilj je poboljšati recenzenta, a ne poslati promjenu.
Brze činjenice
| Pitanje | Kratak odgovor |
|---|---|
| Koji je zadatak? | Objasnite nalaze recenzije i dajte povratne informacije na temelju kojih autor može djelovati. |
| Koji rezultat postižeš? | Točnost nalaza i koliko je objašnjenje korisno. |
| Je li brojanje nedostataka dovoljno? | Ne. Recenzije se odnose na više od samih nedostataka, pa vježba koja nagrađuje samo broj grešaka razvija pogrešnu naviku. |
| Što je kognitivna potražnja? | Analizirajte i procijenite dizajn, a zatim stvorite bolji prijedlog. |
| Tko potvrđuje slučaj? | Voditelj inženjerstva ili viši inženjer koji je vlasnik kodne baze. |
| Što vježbe ne mogu popraviti? | Vrijeme pregleda, nejasno vlasništvo i pritisak za brzo spajanje. |
| Kako znaš da je uspjelo? | Nova, neviđena promjena pregledana prema dogovorenim kriterijima, plus praćenje stvarnih recenzija. |
1. Opišite problem s performansama
Započnite sa zadatkom, u jednoj rečenici: ako se pojavi promjena, recenzent objašnjava što je pronašao, zašto je to važno i što autor može učiniti u vezi s tim. "Objašnjava" je važna riječ. Uočavanje problema je pola vještine. Izgovaranje tako da kolega s drugačijim gledištem može razumjeti, procijeniti i djelovati je druga polovica.
Istraživanje modernog pregleda koda podržava pogled izvan pukog traženja grešaka. U studiji provedenoj u Microsoftu, Bacchelli i Bird su promatrali, intervjuirali i anketirali razvojne programere i menadžere. Otkrili su da je pronalaženje nedostataka i dalje glavna motivacija za pregled, ali da su se pregledi manje odnosili na nedostatke nego što su ljudi očekivali. Također su pružili i druge prednosti, poput dijeljenja znanja, svijesti tima i alternativnih rješenja, a istraživači su opisali razumijevanje koda i promjena kao ključni aspekt pregleda (Bacchelli i Bird, ICSE 2013.). To je studija timova jedne tvrtke, stoga je koristite kao razlog za dizajniranje radi razumijevanja, a ne kao cijenu za svoj.
Googleov objavljeni standard za recenzije ukazuje na isto. Recenzentima se govori da favoriziraju odobravanje promjene kada ona definitivno poboljša cjelokupno stanje koda, čak i ako nije savršen, te se navodi da recenzija može naučiti programere nečemu novom, pa su komentari koji pomažu nekome da nauči dobrodošli (Googleove inženjerske prakse). Oba izvora opisuju pregled kao mjesto gdje se vrši i donosi sud. To je ono što bi vaše vježbe trebale uvježbavati.
2. Dijagnosticirajte nedostatke u učenju i kontekstu
Usporedite zadatak s onim što vaš trenutni program vježba i procjenjuje.
- Koristi li trenutna praksa stvarni zadatak? Ako novi recenzenti uče čitajući stilski vodič, a zatim pregledavajući zahtjeve za povlačenjem uživo, vježbaju na stvarnom radu bez sigurnog mjesta za pogrešku. Ako je procjena kviz o bontonu recenziranja, ona mjeri prisjećanje na pravila, a ne sposobnost njihove primjene na promjenu.
- Što je kognitivna potražnja? U revidiranoj Bloomovoj taksonomiji, procjena je li dizajn dobar i vaganje njegovih kompromisa nalazi se na razinama analize i evaluacije, a predlaganje bolje strukture doseže razinu stvaranja. Ako vaše vježbe samo pitaju "što ovaj kod radi?", one se zaustavljaju na razumijevanju. Naš vodič za usklađivanje aktivnosti učenja s Bloomovom taksonomijom pokazuje kako uskladiti aktivnost s razinom.
- Stoji li na putu nešto osim vještine? Provjerite vrijeme pregleda, alate, vlasništvo i norme tima. Ako recenzenti imaju pet minuta po zahtjevu za povlačenjem, nijedna vježba neće dati promišljeno objašnjenje. Ako autori svaki komentar shvate kao kritiku, recenzenti će ublažiti svoje nalaze sve dok ne kažu ništa. Prijavite ove uzroke ljudima koji ih mogu ispraviti.
3. Priprema dizajna, praksa i povratne informacije
Dajte svakoj fazi zaseban zadatak.
Priprema. Provjerite što recenzenti trebaju prije nego što počnu: kontrolnu listu tima za pregled, principe dizajna na koje se oslanja i kako pročitati razliku u vašim alatima. Neka ovo bude kratko i vlastitim tempom. Provjera opoziva potvrđuje samo preduvjete i nije dokaz da netko može pregledati.
Praksa. Koristite pripremljene promjene s malim brojem različitih vrsta početnih problema: greška u ispravnosti, problem s održavanjem poput pomiješanih odgovornosti u uvodnom primjeru, nejasan naziv ili nedostajući test i neki kod koji je u redu. Zamolite recenzenta da napiše komentar koji bi ostavio, rangira probleme i kaže koje bi dodatne informacije želio. CodeRefineryjeva praktična lekcija pokazuje oblik: ljudi otvaraju zahtjev za povlačenjem koji sadrži malu tipografsku grešku i veću grešku, a zatim ga pregledavaju kao ravnopravni suradnici (CodeRefinery, Vježbanje pregleda koda). Izgradite svoj iz vlastite kodne baze kako bi konvencije i kompromisi bili stvarni.
Povratne informacije. Povežite to s odlukama koje je recenzent donio. "Primijetili ste problem zaokruživanja, ali u vašem komentaru je navedeno 'ovo izgleda krivo' bez navođenja koji unos to pokvari" korisnije je od "pronađeno 2 od 4".
Unos uživo ili asinhroni pregled? Uživo doprinos najviše dodaje vrijednost kada je problem dvosmislen, a recenzenti uče slušajući starijeg inženjera kako objašnjava zašto bi ga pokrenuli ili ga odbacili. Asinkroni pregled dovoljan je za usporedbu komentara s komentiranim stručnim pregledom.
4. Razradite realističan primjer
Ilustracija. Voditelj inženjerstva trebao bi validirati slučaj i kriterije odgovora prije upotrebe.
Slučaj. Promjena dodaje izračun popusta usluzi plaćanja. Prolazi testove. U jednoj funkciji primjenjuje postotak i fiksne popuste, zaokružuje rezultat, zapisuje u bazu podataka i šalje događaj. Ima jedan test, za popust od jednog postotka.
Zadatak. Recenzent piše komentare koje bi ostavili, rangira njihove nedoumice i kaže što bi trebali znati prije odobrenja.
Prvi pokušaj. „Izgleda dobro, test prolazi. Možda ga podijeliti?“ Recenzent je nešto primijetio, ali nije rekao što, zašto je to važno ili što učiniti. Autor ne može djelovati po tom pitanju.
Povratne informacije i ponovni pokušaj. Facilitator pita: što bi buduća promjena ove funkcije mogla uzrokovati probleme? Što biste zamolili autora da doda prije nego što odobrite? Ponovni pokušaj traži konkretan komentar o svakoj zabrinutosti, s razlogom i prijedlogom.
Jači pokušaj. „Funkcija primjenjuje dvije vrste popusta, zaokružuje, sprema i objavljuje događaj, tako da bi promjena zaokruživanja mogla promijeniti ono što pohranjujemo i ono što objavljujemo istovremeno. Tražio bih da se pravila određivanja cijena premjeste u čistu funkciju koju možemo samostalno testirati. Pojedinačni test pokriva samo postotni popust. Tražio bih fiksni popust i narudžbu koja ukupan iznos dovodi do nule. Nisam siguran je li događaj namijenjen aktiviranju kada je ukupan iznos nula, pa bih pitao autora.“ Primijetite da ovaj komentar imenuje problem, daje razlog, daje konkretan prijedlog i navodi što recenzent ne zna.
5. Procijenite kapacitete i planirajte prijenos
Dokaz sposobnosti je izvedba na novoj promjeni koju recenzent nije vidio. Ocijenite točnost nalaza i korisnost objašnjenja. Jednostavna rubrika koristi ljestvicu od 0 do 2 po kriteriju:
| Kriterij | Vidljivi dokazi |
|---|---|
| Izvršenje zadatka | Pronalazi relevantne probleme u promjeni i bilježi dokaze za svaki od njih. |
| Rasuđivanje | Objašnjava zašto je svaka briga važna, nudi alternativu i navodi što je još uvijek neizvjesno. |
| Granice | Pridržava se pravila tima za pregled i traži pomoć ili informacije kada nedostaje autoritet ili kontekst. |
Sidra: 0 znači odsutno ili nepotkrijepljeno, 1 znači djelomično s relevantnim propustima, a 2 znači potpuno i opravdano prema dogovorenim kriterijima. Kritične pogreške definirajte zasebno, na primjer odobravanje promjene s rizikom od gubitka podataka, tako da dobra ukupna ocjena ne može sakriti jedan. Prilagodite kriterije s voditeljem inženjeringa; ova rubrika je početni prijedlog, a ne validirani standard spremnosti. Za više informacija o obrazloženju bodovanja pogledajte naš vodič za osmišljavanje interaktivne prakse s korisnim povratnim informacijama.
Planirajte prijenos. Nakon vježbe, provjerite uzorak stvarnih recenzija recenzenta nekoliko tjedana kasnije, koristeći iste kriterije. Usporedite s početnom vrijednosti uzetom prije obuke i unaprijed definirajte populaciju i vremenski okvir. Prije priznavanja bodova za vježbe, pogledajte i druge promjene koje su se dogodile u istom razdoblju, poput novog alata za recenziju ili promjene osoblja.
6. Izvedite vježbu uživo ili vlastitim tempom uz AhaSlides
Vježbu možete provesti na radionici ili pustiti recenzente da je sami obrade. U sesiji uživo prikažite pripremljenu promjenu i koristite interaktivne slajdove za raspravu:
- Odaberite odgovor za "koju biste zabrinutost prvo iznijeli?", s odabranim zabrinutostima kao opcijama. Prikažite raspon prije nego što otkrijete vlastiti rang.
- Otvorenog kraja za "napišite komentar koji biste ostavili". Recenzenti mogu usporediti svoje formulacije s drugima, što je ono gdje se pokazuje vještina objašnjavanja.
- Skala ocjenjivanja za "koliko je ovo ozbiljno?", kako bi grupa mogla vidjeti gdje se procjene razlikuju i razgovarati o tome zašto.
Za recenzente koji ne mogu prisustvovati, isti slijed može se koristiti vlastitim tempom, s komentiranom stručnom recenzijom prikazanom nakon svakog odgovora. Svaku tvrdnju o izvršavanju koda, integracijama ili značajkama umjetne inteligencije tretirajte kao nepotvrđenu dok je ne isprobate s vlastitim materijalom.
Ako također obučavate recenzente za rad s kodom napisanim umjetnom inteligencijom, pogledajte naš prateći vodič o Obuka za pregled koda generiran umjetnom inteligencijomTaj post je o reviziji generiranih rezultata. Ovaj je o tome kako ljudi međusobno pregledavaju rad i kako objašnjavaju što pronađu.
Ograničenja koja mogu ostati
- Vrijeme pregleda. Promišljen komentar traje dulje od "LGTM-a", a rokovi se približavaju kraćoj verziji.
- Timske norme. Ako se povratne informacije protumače kao osobna kritika, recenzenti će ublažiti ili odustati od svojih nalaza.
- Pokrivenost slučaja. Jedna vježba pokazuje nekoliko vrsta zabrinutosti. Ocjena ne opisuje općenitu procjenu recenzenta.
- Prijenos. Uspješnost u radionici nije ista kao i uspješnost u zauzetom redu, stoga provjerite i stvarne recenzije.
Na vrijeme ih imenujte sponzorima i planirajte odvojene popravke. Vježbe poboljšavaju ono što recenzent može vidjeti i objasniti. One ne stvaraju vrijeme ili norme.
Često postavljana pitanja
Što su vježbe pregleda koda?
To su pripremljeni praktični zadaci u kojima programer pregledava promjenu s poznatim nedoumicama, piše komentare koje bi ostavio i dobiva povratne informacije o točnosti i korisnosti. Cilj je izgraditi vještinu recenzenta, a ne poslati promjenu.
Kako procjenjujete je li se poboljšala procjena recenzenta?
Navedite novu promjenu koju nisu vidjeli i ocijenite nalaze i objašnjenje prema dogovorenim kriterijima. Zatim provjerite uzorak stvarnih recenzija nekoliko tjedana kasnije. Kviz o pravilima recenzije potvrđuje samo preduvjete.
Je li pregled koda od strane kolega uglavnom usmjeren na pronalaženje grešaka?
Pronalaženje nedostataka i dalje je glavna motivacija, ali jedna studija u Microsoftu otkrila je da su recenzije bile manje usmjerene na nedostatke nego što se očekivalo, a također su dovele do dijeljenja znanja i svijesti tima. Dizajnirajte vježbe koje nagrađuju objašnjenje i razumijevanje, kao i broj nedostataka.
Gdje započeti
Odaberite jednu vrstu promjene koju vaš tim često pregledava. Napišite izjavu o učinku, zamolite višeg inženjera da pripremi jednu promjenu s tri ili četiri osnovna problema i izradite rubriku s tri kriterija s ljestvicom od 0 do 2 i popisom kritičnih pogrešaka. Isprobajte je s malom grupom, a zatim usporedite njihove sljedeće stvarne preglede s početnom vrijednosti.
Da biste vidjeli kako bi se vježba pregleda mogla izvoditi uživo s vašim timom i ponovno koristiti vlastitim tempom nakon toga, istražite AhaSlides.
