Būdams jaunākais programmatūras inženieris, es vienmēr izskatīju saņemtos kodu pārskatīšanas komentārus, lai uzzinātu, kā kļūt par labāku kodētāju. Bet, kad pienāca laiks man izmēģināt savu pirmo koda pārskatīšanu, es sapratu, ka mana pieredze nav sagatavojusi mani būt otrā pusē.
Es izstrādāju smagu krāpšanās sindroma gadījumu, spirālveidīgi virzoties uz leju ar jautājumiem: Vai man vajadzētu komentēt šo koda rindu, vai tas nav tā vērts? Vai man vajadzētu atrast rakstus, kas atbalsta katru komentāru? Vai es to iznīcināšu, apstiprinot šo problēmu? Vai viņi mani ienīdīs? Labi, es atzīstu, ka spirāle notiek diezgan ātri. Bet pēc sarunas ar dažiem kolēģiem es zināju, ka neesmu viena savās rūpēs.
Jaunākie programmatūras inženieri var tikt iesaistīti koda pārskatīšanā ar pieņēmumu, kas ir analogs “jūs zināt, kā lasīt grāmatu, lai jūs zināt, kā rakstīt grāmatu, kas nav taisnība, ” saka Džesika Rūdrere, GitHub pieredzes inženiere.
Ir cerības, kas saistītas ar koda pārskatīšanu, un process var būt nervozs. Tāpēc es intervēju vēl septiņus programmatūras inženierus, lai apkopotu padomus, kā izveidot pārskatīšanas domāšanas veidu.
1. Padomājiet par kopējo ietekmi
Parasti laba pieprasījuma pieprasījumam (PR) būtu jāattiecas tikai uz ierobežotu kodeksa bāzes daļu. Tomēr ierobežotajai darbības jomai nevajadzētu kavēt domāt par koda maiņu lielākas kodu bāzes kontekstā.
Nigels Munozs, bijušais “The Muse” pilnas slodzes inženieris un pašreizējais ārštata programmatūras inženieris, mudina recenzentu padomāt par “kā šīs izmaiņas ietekmē lielāku un mazāku attēlu”. Ņemot vērā lielāku attēlu, ir jāatrod arī jebkāds tehniskais parāds - meklējiet kodu tas ir atkārtots, nemodulārs vai neatbilst pēdējām standarta konvencijām, kā arī analizē kodeksa bāzes arhitektūras modifikācijas.
Sems Donovs, Hudson River Trading galvenais izstrādātājs, uzskata, ka “nav kaut kas pārāk liels vai pārāk mazs, lai to komentētu. Nelielu uzlabojumu ieteikumi varētu izraisīt lielākus uzlabojumus vairākās kodeksa bāzes daļās. ”
Varat izmantot PR komentāru vietnē GitHub, lai sniegtu pozitīvas atsauksmes, kā arī norādītu, kur kods var atšķirties no React ietvara standarta noteikumiem.
Piemēram, vienā no mana koda pārskatiem es saņēmu komentāru, ka daži React komponenta rekvizīti ir mulsinoši, kas izraisīja plašākus jautājumus par komponenta izmantošanu. Galu galā es noņēmu sākotnējā komponenta rekvizītus un izveidoju atsevišķu komponentu, lai precizētu katra uzvedību un nodrošinātu, ka abus var izmantot vairākās vietās.
2. Apsveriet drošību
Neaizmirstiet, ka dažas izmaiņas var ietekmēt ne tikai kodu bāzi. Rūdrs iesaka novērtēt, vai lietotājs “varētu izmantot šo funkcionalitāti, lai kādu uzmāktu, vai varētu ļaunprātīgi izmantot sistēmu.” Piemēram, ja jaunajā ievilkšanas pieprasījuma funkcijā ir iekļauta lietotāja ieeja, meklējiet SQL ievadīšanu, piekļuvi datiem, starpvietņu skriptus un citas drošības ievainojamības.
3. Koncentrējieties uz kļūdām
Jūsu citi līdzautori - neatkarīgi no tā, cik roboti tie var šķist - ir cilvēki, un cilvēki var sabojāt vai aizmirst funkcijas. Tāpēc pārliecinieties, ka “pārskatāt testus ar tādu pašu nozīmi kā pārējam kodam”, iesaka Abhishek Pillai, Skolotāju maksas skolotāju tehnoloģiju vadītājs. "Tie novērsīs jaunu kļūdu rašanos un kalpos kā dokumentācijas forma ikvienam citam, kurš nākotnē pie tā strādās."
Pārbaužu lasīšana var palīdzēt izprast jaunas funkcijas funkcionalitāti un redzēt dažādus gadījumus, ko tā ieviesīs, savukārt testu analīze var palīdzēt norādīt uz pazudušajiem gadījumiem un atrast funkcijas, kas šajā PR nav ietvertas. Ja koda maiņā nav iekļauti testi un tie šķiet atbilstoši, ir lietderīgi tos pieprasīt pārskatīšanas laikā.
Bet testi nav viss. “Nelietojiet pārāk lielu ticību sistēmai, ” brīdina Donovs. "Tikai tāpēc, ka veiktie testi nenozīmē, ka nav kļūdu."
Jūs varētu arī vēlēties “palaist lietotni lokāli, lai to funkcionāli pārbaudītu un pārliecinātos, ka tā darbojas. Ja tas nedarbojas, tad nav jēgas turpināt pārskatīšanu, ”saka Raiens Verners, 8th Light programmatūras izstrādātājs. Lai gan daži recenzenti neuzskata, ka manuālai pārbaudei vajadzētu būt daļai no koda pārskatīšanas procesa - daļēji tāpēc, ka tas prasa laiku - Verners uzskata, ka tas ir ātrs veids, kā noteikt, vai jums vajadzētu ieguldīt vairāk laika pārskatīšanai, kā arī stratēģija, kas palīdzētu samazināt kļūdu trūkuma palielināšanās.
4. Esi komandas spēlētājs
Klišete iegūst jaunu nozīmi, kad runa ir par koda pārskatīšanu. “Nepieciešams laiks pārskatīšanai, jo tā ir ikviena kodolbāze, ” saka Verners, kurš iestājas par “kolektīvās īpašumtiesības” izjūtu. Jums kā recenzentam vajadzētu censties aizsargāt kļūdu krājumus, lai tie nepalielinās, ar mērķi dot savu komanda mazāk strādā pie līnijas.
Pillai izmanto gifus, lai atzīmētu savu komandas biedru apstiprinātos un apvienošanās gatavos PR.
Tajā pašā laikā Čārlzs Lukstons, The Muse tehnoloģiju vadītājs, mudina recenzentu izprast un atcerēties komandas prioritātes. Ātri tuvojoties termiņiem un nesaskaņām, dažkārt izveidojot neizpildāmo lietu, kas nodrošina uzlabojumus nākotnē, un pa to laiku komentējot attiecīgo kodu, ir nepieciešama joslas palīdzība. lai jūsu komanda būtu laimīga.
Visbeidzot, pajautājot sev, vai kodam ir jēga kādam, kurš tikko pievienojās komandai un to lasīja dažu pirmo nedēļu laikā, tas palīdzēs jūsu kodu lasīt un saprast.
5. Izmantojiet mācību un zināšanu apmaiņas procesu
Pārskatīšanas process ikvienam iesaistītajam dod iespēju gūt plašāku ieskatu kodu bāzē, valodās, ietvaros un paraugpraksē.
Metjū Džefrijs, The Muse vadošais vadītājs, iesaka recenzentam "izprast izmaiņas arhitektoniski. Viens no veidiem ir lasīt failu nosaukumus, jo tie palīdz sniegt kontekstu. Piemēram, ja jūs meklējat izmaiņas datu piekļuves slānī. jūs zināt, ka nenodarbojaties ar biznesa loģiku vai lietotāja saskarni. "
Lai koplietotu dokumentāciju, varat izmantot PR komentāru vietnē GitHub.
Kad jūs mācāties no koda maiņas, jums ir arī iespēja dalīties zināšanās. “Vislabāk ir izskaidrot savu viedokli un papildināt to ar dokumentāciju, ” saka Luxtons. Jūsu sniegtās saites uz pierādījumiem un uzticamiem rakstiem ne tikai palīdz recenzentam un kodu rakstītājam izpētīt dažādas pieejas, pieņemot galīgo lēmumu, bet arī papildina viņu zināšanas par programmēšanu.
Paturot prātā šos padomus, atcerieties arī to, ka pārskatīšana ir laiks, kad izmantot savas prasmes. “Dodiet cilvēkiem labumu no šaubām, ka viņi domāja par savu pieeju, un norādiet uz dažādām iespējām, mēģinot kliedēt aizsardzības spējas, ” saka Rūdrs. “Es atstāju komentārus un iesaiņojumu - šeit ir kas lieliski, lūk, ko var uzlabot, lūk, kas jāmaina pirms apvienošanas.”
Izmantojot šādu pieeju, jūs ne tikai aizsargāsit savu kodu bāzi no tehnoloģiju parādiem, drošības draudiem un kļūdām, bet arī veidosit savu komandu.
