Nagbukas ang isang developer ng pull request na nagdaragdag ng kalkulasyon ng diskwento sa isang serbisyo ng checkout. Nakapasa ang mga pagsubok at maikli lang ang pagkakaiba. Inaprubahan ito ng isang tagasuri sa loob ng dalawang minuto gamit ang "LGTM". Pagkalipas ng tatlong buwan, kinailangan ng isang kasamahan sa koponan na baguhin ang parehong function at natuklasan na pinagsasama nito ang mga panuntunan sa pagpepresyo, pag-round, at pag-access sa database sa isang lugar. Walang sinuman ang makapagsabi nang may kumpiyansa kung ano ang pinapayagan nitong gawin.
Ito ay isang naglalarawang senaryo, hindi isang dokumentadong insidente. Ipinapakita nito kung ano ang maaaring idulot ng peer code review kapag ito ay gumagana bilang isang aktibidad sa pagkatuto: isang tagasuri na makakakita ng isang posibleng pagbabago, matukoy ang alalahanin na hindi pa isang bug, at maipapaliwanag ito sa paraang maaaring aksyonan ng may-akda.
Ang gabay na ito ay para sa mga engineering enablement lead at engineering manager. Ipinapakita nito kung paano magdisenyo mga pagsasanay sa pagsusuri ng code na sadyang binubuo ang kasanayang iyon, sa halip na umasa na makukuha ito ng mga tagasuri mula sa pila. Sinasaklaw nito ang problema sa pagganap, ang mga kakulangan na dapat i-diagnose, kung paano istruktura ang paghahanda at pagsasanay, isang halimbawang ginamit, at kung paano suriin kung ang kasanayan ay maihahatid sa mga totoong pagsusuri. Ipa-validate sa mga senior engineer ang bawat kaso, depekto, at pamantayan bago mo ito gamitin.
Ano ang mga pagsasanay sa pagsusuri ng code?
Ang mga pagsasanay sa pagsusuri ng code ay mga nakabalangkas na gawain sa pagsasanay kung saan sinusuri ng isang developer ang isang inihandang pagbabago, ipinapaliwanag kung ano ang kanilang natuklasan at kung bakit ito mahalaga, at kumukuha ng feedback sa kalidad ng paliwanag na iyon. Iba ang mga ito sa mga pagsusuring ginagawa ng iyong koponan araw-araw. Ang pagbabago ay pinipili nang maaga, ang mga alalahanin dito ay alam, at ang layunin ay upang mapabuti ang tagasuri sa halip na ipadala ang pagbabago.
Mabilis na katotohanan
| Tanong | Maikling sagot |
|---|---|
| Ano ang gawain? | Ipaliwanag ang mga natuklasan sa pagsusuri at magbigay ng feedback na maaaring aksyonan ng may-akda. |
| Ano ang iyong iskor? | Katumpakan ng mga natuklasan at kung gaano kapaki-pakinabang ang paliwanag. |
| Sapat na ba ang pagbibilang ng mga depekto? | Hindi. Ang mga pagsusuri ay hindi lamang tungkol sa mga depekto, kaya ang isang ehersisyo na nagbibigay lamang ng gantimpala sa bilang ng mga bug ay nagsasanay sa maling gawi. |
| Ano ang pangangailangang kognitibo? | Suriin at suriin ang isang disenyo, pagkatapos ay lumikha ng isang mas mahusay na mungkahi. |
| Sino ang nagpapatunay sa kaso? | Isang engineering manager o senior engineer na nagmamay-ari ng codebase. |
| Ano ang hindi kayang ayusin ng mga ehersisyo? | Oras ng pagsusuri, hindi malinaw na pagmamay-ari, at presyon na mabilis na magsanib. |
| Paano mo nalaman na gumana ito? | Isang bago at hindi pa nakikitang pagbabago na sinuri batay sa napagkasunduang pamantayan, kasama ang isang kasunod na pagsusuri sa mga totoong pagsusuri. |
1. Ilarawan ang problema sa pagganap
Magsimula sa gawain, sa isang pangungusap: kung may pagbabago, ipapaliwanag ng tagasuri ang kanilang natuklasan, kung bakit ito mahalaga, at kung ano ang maaaring gawin ng may-akda tungkol dito. "Nagpapaliwanag" ang mahalagang salita. Ang pagtukoy sa isang isyu ay kalahati ng kasanayan. Ang pagsasabi nito upang maunawaan ito ng isang kasamahan na may ibang pananaw, timbangin ito, at kumilos ay ang kabilang kalahati.
Sinusuportahan ng pananaliksik sa modernong pagsusuri ng code ang pagtingin nang higit pa sa paghahanap ng mga bug. Sa isang pag-aaral sa Microsoft, naobserbahan, nakapanayam, at sinurbey nina Bacchelli at Bird ang mga developer at manager. Natuklasan nila na ang paghahanap ng mga depekto pa rin ang pangunahing motibasyon para sa pagsusuri, ngunit ang mga pagsusuri ay hindi gaanong tungkol sa mga depekto kaysa sa inaasahan ng mga tao. Naghatid din sila ng iba pang mga benepisyo, tulad ng pagbabahagi ng kaalaman, kamalayan ng koponan, at mga alternatibong solusyon, at inilarawan ng mga mananaliksik ang pag-unawa sa code at pagbabago bilang pangunahing aspeto ng pagsusuri (Bacchelli at Bird, ICSE 2013). Ito ay isang pag-aaral ng mga koponan ng isang kumpanya, kaya gamitin ito bilang dahilan upang magdisenyo para sa pag-unawa, hindi bilang isang rate para sa iyo.
Ganito rin ang punto ng inilathalang pamantayan ng pagsusuri ng Google. Sinasabi nito sa mga tagasuri na paboran ang pag-apruba ng isang pagbabago kapag tiyak na napapabuti nito ang pangkalahatang kalusugan ng code, kahit na hindi ito perpekto, at sinasabi nito na ang pagsusuri ay maaaring magturo ng mga bagong bagay sa mga developer, kaya ang mga komentong makakatulong sa isang tao na matuto ay malugod na tinatanggap (Mga Kasanayan sa Inhinyeriya ng Google). Inilalarawan ng parehong sanggunian ang pagsusuri bilang isang lugar kung saan isinasagawa at ipinapasa ang paghatol. Iyan ang dapat na pag-ensayohin ng iyong mga pagsasanay.
2. Suriin ang mga kakulangan sa pagkatuto at konteksto
Ihambing ang gawain sa kung ano ang ginagawa at tinatasa ng iyong kasalukuyang programa.
- Ginagamit ba ng kasalukuyang kasanayan ang totoong gawain? Kung ang mga bagong tagasuri ay natututo sa pamamagitan ng pagbabasa ng isang style guide at pagkatapos ay pagrerepaso ng mga live pull request, nagsasanay sila sa totoong trabaho nang walang ligtas na lugar para magkamali. Kung ang pagtatasa ay isang pagsusulit sa etiketa sa pagsusuri, sinusukat nito ang pag-alala sa mga patakaran, hindi ang kakayahang ilapat ang mga ito sa isang pagbabago.
- Ano ang pangangailangang kognitibo? Sa binagong taxonomy ni Bloom, ang paghusga kung ang isang disenyo ay maayos at pagtimbang sa mga kompromiso nito ay nasa antas ng pagsusuri at pagsusuri, at ang pagmumungkahi ng mas mahusay na istruktura ay umaabot sa antas ng paglikha. Kung ang iyong mga pagsasanay ay nagtatanong lamang ng "ano ang ginagawa ng code na ito?", hihinto ang mga ito sa pag-unawa. Ang aming gabay sa pagtutugma ng mga aktibidad sa pagkatuto sa Bloom's Taxonomy nagpapakita kung paano itugma ang aktibidad sa antas.
- May iba pa bang nakaharang bukod sa kasanayan? Suriin ang oras ng pagsusuri, mga kagamitan, pagmamay-ari, at mga pamantayan ng pangkat. Kung ang mga tagasuri ay may limang minuto bawat kahilingan sa paghila, walang ehersisyo ang makakabuo ng isang maalalahaning paliwanag. Kung ituturing ng mga may-akda ang bawat komento bilang kritisismo, palalambotin ng mga tagasuri ang kanilang mga natuklasan hanggang sa wala na silang sasabihin. Iulat ang mga sanhing ito sa mga taong maaaring mag-ayos ng mga ito.
3. Paghahanda, pagsasanay, at feedback sa disenyo
Bigyan ang bawat yugto ng hiwalay na gawain.
Paghahanda Suriin kung ano ang kailangan ng mga tagasuri bago sila magsimula: ang checklist ng pagsusuri ng koponan, ang mga prinsipyo ng disenyo na pinagbabatayan nito, at kung paano basahin ang pagkakaiba sa iyong mga kagamitan. Panatilihin itong maikli at kusang-loob. Kinukumpirma lamang ng recall check ang mga kinakailangan, at hindi ito ebidensya na maaaring magsuri ang isang tao.
Practice. Gumamit ng mga inihandang pagbabago na may kaunting bilang ng mga naka-seed na alalahanin na may iba't ibang uri: isang bug sa kawastuhan, isang problema sa pagpapanatili tulad ng magkahalong responsibilidad sa pambungad na halimbawa, isang hindi malinaw na pangalan o nawawalang pagsubok, at ilang code na ayos lang. Hilingin sa tagasuri na isulat ang komentong iiwan nila, i-ranggo ang mga alalahanin at sabihin kung anong karagdagang impormasyon ang gusto nila. Ipinapakita ng praktikal na aralin ng CodeRefinery ang hugis: binubuksan ng mga tao ang isang pull request na naglalaman ng isang maliit na typo at isang mas malaking pagkakamali, pagkatapos ay sinusuri ito bilang isang peer (CodeRefinery, Pagsusuri ng code sa pagsasanayBuuin ang sa iyo mula sa sarili mong codebase upang maging makatotohanan ang mga kumbensyon at mga kompromiso.
Feedback. Iugnay ito sa mga desisyong ginawa ng tagasuri. Mas kapaki-pakinabang ang "Napansin mo ang problema sa pag-round off ngunit sinabi ng iyong komento na 'mukhang mali ito' nang hindi sinasabi kung anong input ang nagpapatunay nito" kaysa sa "nahanap ang 2 sa 4".
Live na input o asynchronous na pagsusuri? Ang live input ay nagdaragdag ng pinakamalaking halaga kapag ang isang alalahanin ay hindi malinaw at natututo ang mga tagasuri mula sa pakikinig sa isang senior engineer na nagsasabi kung bakit nila ito ihahain, o kung bakit nila ito hahayaan. Ang asynchronous na pagsusuri ay sapat na para sa paghahambing ng mga komento sa isang may anotasyong pagsusuri ng eksperto.
4. Gumawa ng isang makatotohanang halimbawa
Paglalarawan. Dapat patunayan ng isang engineering manager ang kaso at ang pamantayan ng sagot bago gamitin.
Ang kaso. Ang isang pagbabago ay nagdaragdag ng kalkulasyon ng diskwento sa isang serbisyo ng pag-checkout. Nakapasa ito sa mga pagsubok nito. Sa isang function, inilalapat nito ang porsyento at mga nakapirming diskwento, niroronda ang resulta, nagsusulat sa database at nagpapadala ng isang kaganapan. Mayroon itong isang pagsubok, para sa isang porsyentong diskwento.
Ang gawain. Isinusulat ng tagasuri ang mga komentong iiwan nila, iniraranggo ang kanilang mga alalahanin, at sinasabi kung ano ang kailangan nilang malaman bago aprubahan.
Isang unang pagsubok. "Mukhang maayos naman, pasado ang pagsusulit. Baka puwedeng hatiin?" May napansin ang tagasuri pero hindi pa sinasabi kung ano, bakit ito mahalaga, o kung ano ang gagawin. Hindi maaaring kumilos ang may-akda batay dito.
Magbigay ng feedback at subukan muli. Itatanong ng tagapagpadaloy: ano ang maaaring makasama sa pagbabago sa tungkuling ito sa hinaharap? Ano ang hihilingin mong idagdag sa may-akda bago mo aprubahan? Ang muling pagsubok ay hihingi ng isang partikular na komento sa bawat alalahanin, kasama ang dahilan at isang mungkahi.
Isang mas malakas na pagtatangka. "Ang function ay naglalapat ng dalawang uri ng diskwento, ang pag-ikot, pag-save, at pag-publish ng isang kaganapan, kaya ang pagbabago sa pag-round ay maaaring magpabago sa kung ano ang iniimbak natin at kung ano ang inilalathala natin nang sabay. Hihilingin ko na ang mga patakaran sa pagpepresyo ay lumipat sa isang purong function na maaari nating subukan nang mag-isa. Ang nag-iisang pagsubok ay sumasaklaw lamang sa porsyento ng diskwento. Hihilingin ko ang isang nakapirming diskwento at isang order na magdadala sa kabuuan sa zero. Hindi ako sigurado kung ang kaganapan ay nilalayong gumana kapag ang kabuuan ay zero, kaya hihilingin ko sa may-akda." Pansinin na ang komentong ito ay binanggit ang alalahanin, nagbibigay ng dahilan, nagbibigay ng isang konkretong mungkahi, at nagsasaad ng hindi alam ng tagasuri.
5. Suriin ang kakayahan at planuhin ang paglipat
Ang ebidensya ng kakayahan ay ang pagganap sa isang bagong pagbabago na hindi pa nakikita ng tagasuri. Lagyan ng marka ang katumpakan ng mga natuklasan at ang kapakinabangan ng paliwanag. Ang isang simpleng rubric ay gumagamit ng 0 hanggang 2 na iskala bawat pamantayan:
| Saligan | Napapansing ebidensya |
|---|---|
| Pagpapatupad ng gawain | Hinahanap ang mga kaugnay na alalahanin sa pagbabago at itinatala ang ebidensya para sa bawat isa. |
| pangangatwiran | Ipinapaliwanag kung bakit mahalaga ang bawat alalahanin, nag-aalok ng alternatibo, at sinasabi kung ano ang nananatiling hindi tiyak. |
| Mga Hangganan | Sumusunod sa mga tuntunin ng pangkat sa pagsusuri at humihingi ng tulong o impormasyon kapag kulang ang awtoridad o konteksto. |
Mga Anchor: Ang 0 ay nangangahulugang wala o hindi sinusuportahan, ang 1 ay nangangahulugang bahagyang may mga kaugnay na kakulangan, at ang 2 ay nangangahulugang kumpleto at makatwiran batay sa napagkasunduang pamantayan. Hiwalay na tukuyin ang mga kritikal na error, halimbawa ang pag-apruba ng isang pagbabago na may panganib ng pagkawala ng data, upang ang isang mahusay na pangkalahatang marka ay hindi maitago ito. Iangkop ang pamantayan kasama ang engineering manager; ang rubric na ito ay isang panimulang panukala, hindi isang napatunayang pamantayan ng kahandaan. Para sa higit pa tungkol sa pangangatwiran sa pagmamarka, tingnan ang aming gabay sa pagdidisenyo ng interaktibong pagsasanay na may kapaki-pakinabang na feedback.
Magplano para sa paglipat. Pagkatapos ng ehersisyo, suriin ang isang sample ng mga totoong pagsusuri ng tagasuri pagkalipas ng ilang linggo, gamit ang parehong pamantayan. Ihambing sa isang baseline na kinuha bago ang pagsasanay at tukuyin ang populasyon at tiyempo nang maaga. Tingnan ang iba pang mga pagbabagong nangyari sa parehong panahon, tulad ng isang bagong tool sa pagsusuri o isang pagbabago ng tauhan, bago i-credit ang mga pagsasanay.
6. Patakbuhin ang ehersisyo nang live o self-paced gamit ang AhaSlides
Maaari mong patakbuhin ang pagsasanay sa isang workshop o hayaan ang mga tagasuri na gawin ito nang mag-isa. Sa isang live na sesyon, ipakita ang inihandang pagbabago at gumamit ng mga interactive na slide para sa talakayan:
- Piliin ang Sagot para sa "aling alalahanin ang una mong itataas?", kasama ang mga naka-seed na alalahanin bilang mga opsyon. Ipakita ang spread bago mo ibunyag ang sarili mong ranggo.
- Open Ended para sa "isulat ang komentong iiwan mo". Maaaring ihambing ng mga tagasuri ang kanilang mga salita sa iba, kung saan ipinapakita ang kasanayan sa pagpapaliwanag.
- Rating Scale para sa "gaano ito kalala?", para makita ng grupo kung saan nagkakaiba ang mga paghatol at mapag-usapan kung bakit.
Para sa mga tagasuri na hindi makakadalo, maaaring gamitin ang parehong pagkakasunod-sunod ayon sa sarili mong bilis, kung saan ipinapakita ang may anotasyong pagsusuri ng eksperto pagkatapos ng bawat tugon. Ituring na hindi pa nakumpirma ang anumang pahayag tungkol sa pagpapatupad ng code, mga integrasyon, o mga tampok ng AI hangga't hindi mo pa ito nasusubukan gamit ang sarili mong materyal.
Kung sinasanay mo rin ang mga tagasuri sa AI-written code, tingnan ang aming kasamang gabay sa Pagsasanay sa pagsusuri ng code na binuo ng AIAng post na iyan ay tungkol sa pag-awdit ng nabuong output. Ito ay tungkol sa kung paano sinusuri ng mga tao ang gawa ng isa't isa, at kung paano nila ipinapaliwanag ang kanilang natuklasan.
Mga limitasyon na maaaring manatili
- Oras ng pagsusuri. Ang isang maalalahaning komento ay mas matagal kaysa sa "LGTM", at ang mga deadline ay mas mabilis na maikli.
- Mga pamantayan ng koponan. Kung ang feedback ay ituturing na personal na kritisismo, lalambot o babawasan ng mga tagasuri ang kanilang mga natuklasan.
- Saklaw ng kaso. Isang pagsasanay ang nagpapakita ng ilang uri ng pag-aalala. Hindi inilalarawan ng iskor ang pangkalahatang paghatol ng isang tagasuri.
- Paglilipat. Ang pagganap sa isang workshop ay hindi katulad ng pagganap sa isang abalang pila, kaya tingnan din ang mga totoong review.
Banggitin ang mga ito sa mga sponsor nang maaga at magplano ng magkakahiwalay na mga pag-aayos. Pinapabuti ng mga pagsasanay ang nakikita at naipapaliwanag ng isang tagasuri. Hindi nito nililikha ang oras o ang mga pamantayan.
Mga madalas itanong
Ano ang mga pagsasanay sa pagsusuri ng code?
Ang mga ito ay mga inihandang gawain sa pagsasanay kung saan sinusuri ng isang developer ang isang pagbabago na may mga kilalang alalahanin, isinusulat ang mga komentong iiwan nila, at kumukuha ng feedback sa katumpakan at kapakinabangan. Ang layunin ay upang mabuo ang kasanayan ng tagasuri, hindi upang ipadala ang pagbabago.
Paano mo masusuri kung bumuti ang paghatol ng isang tagasuri?
Magbigay ng bagong pagbabago na hindi pa nila nakikita at bigyan ng marka ang mga natuklasan at ang paliwanag batay sa napagkasunduang pamantayan. Pagkatapos, suriin ang isang halimbawa ng mga totoong pagsusuri pagkalipas ng ilang linggo. Ang isang pagsusulit tungkol sa mga tuntunin sa pagsusuri ay magpapatunay lamang sa mga kinakailangan.
Ang peer code review ba ay pangunahing tungkol sa paghahanap ng mga bug?
Ang paghahanap ng mga depekto ay isa pa ring pangunahing motibasyon, ngunit natuklasan ng isang pag-aaral sa Microsoft na ang mga pagsusuri ay hindi gaanong tungkol sa mga depekto kaysa sa inaasahan at naghatid din ng pagbabahagi ng kaalaman at kamalayan sa pangkat. Mga pagsasanay sa disenyo na nagbibigay-gantimpala sa paliwanag at pag-unawa pati na rin sa bilang ng mga depekto.
Saan magsisimula
Pumili ng isang uri ng pagbabago na madalas nirerepaso ng iyong koponan. Isulat ang pahayag ng pagganap, hilingin sa isang senior engineer na maghanda ng isang pagbabago na may tatlo o apat na pangunahing alalahanin, at bumuo ng isang rubric na may tatlong pamantayan na may iskala mula 0 hanggang 2 at isang listahan ng mga kritikal na pagkakamali. Subukan ito kasama ang isang maliit na grupo, pagkatapos ay ihambing ang kanilang susunod na mga totoong pagsusuri sa isang baseline.
Para makita kung paano maaaring gumana nang live ang isang ehersisyo sa pagsusuri kasama ang sarili mong koponan, at magamit muli nang mag-isa pagkatapos, tuklasin ang AhaSlides.
