Jako juniorský softwarový inženýr jsem vždy prohlížel komentáře, které jsem dostal, abych se dozvěděl, jak se stát lepším kodérem. Když ale přišel čas, abych se pokusil o první kontrolu kódu, uvědomil jsem si, že moje zkušenost mě nepřipravila na druhou stranu.
Vyvinul jsem závažný případ syndromu podvodníka, spirály dolů s otázkami: Měl bych komentovat tento řádek kódu nebo to nestojí za to? Měl bych najít články na podporu každého komentáře? Schválím to na webu? Nenávidí mě? Dobře, přiznávám, že jsem spirálu docela rychle. Ale po rozhovoru s některými spolupracovníky jsem věděl, že nejsem sám v obavách.
Junior softwaroví inženýři mohou být hodeni do revize kódu s předpokladem analogickým „víte, jak číst knihu, takže víte, jak napsat knihu, což není pravda, “ říká Jessica Rudder, zkušená inženýrka v GitHubu.
Existují očekávání, která přicházejí s kontrolou kódu, a tento proces může být nervózní. Takže jsem vedl pohovor se sedmi dalšími softwarovými inženýry, abych získal tipy, jak vybudovat revizi myšlení.
1. Přemýšlejte o celkovém dopadu
Obecně platí, že žádost o dobrý tah (PR) by měla ovlivnit pouze omezenou část kódové základny. Omezený rozsah by vám však neměl bránit v přemýšlení o změně kódu v kontextu větší kódové základny.
Nigel Munoz, bývalý technik s plným stackem v Museu a současný nezávislý softwarový inženýr, vybízí recenzenta, aby přemýšlel o tom, „jak tato změna ovlivní větší a menší obrázek.“ Vzhledem k tomu, že větší obrázek zahrnuje nalezení jakéhokoli technického dluhu - hledejte kód to je opakované, nemodulární nebo se neřídí nejnovějšími standardními konvencemi - a také analyzuje úpravy architektury kódové základny.
Sam Donow, hlavní vývojář společnosti Hudson River Trading, věří, že „není nic příliš velkého nebo příliš malého, aby se k němu mohl vyjádřit. Návrhy na malá vylepšení by mohly vést k větším vylepšením ve více částech kodebasu. “
Pomocí komentáře PR k GitHub můžete poskytnout pozitivní zpětnou vazbu a také poukázat na to, kde se kód může lišit od standardních konvencí rámce React.
Například při jednom z mých vlastních kontrol kódu jsem obdržel poznámku, že určité vlastnosti komponenty React byly matoucí, což vyvolalo širší otázky o tom, jak byla komponenta používána. Nakonec jsem odstranil vlastnosti z původní komponenty a vytvořil samostatnou komponentu, abychom objasnili chování každého z nich a zajistili, že oba budou moci být použity na více místech.
2. Zvažte zabezpečení
Nezapomeňte, že některé změny mohou mít dopad více než jen na kódovou základnu. Rudder doporučuje vyhodnotit, zda uživatel „mohl tuto funkci použít k obtěžování nebo zneužití systému“. Například, pokud nová funkce v požadavku vyžádání zahrnuje zadání uživatele, hledejte vstřikování SQL, přístup k datům, skriptování mezi weby a další bezpečnostní chyby.
3. Zaměřte se na chyby
Tvůrci vašich kolegů - bez ohledu na to, jak roboticky se mohou zdát - jsou lidé a lidé mohou narušit nebo zapomenout na funkce. Ujistěte se tedy, že „přezkoumáváte testy se stejnou důležitost jako zbytek kódu“, doporučuje Abhishek Pillai, technologický vedoucí u Učitelů placených učitelů. "Zabrání novým chybám a bude sloužit jako forma dokumentace pro kohokoli jiného, kdo na tom v budoucnu pracuje."
Čtení testů vám může pomoci pochopit funkčnost nové funkce a vidět různé případy, které představí, zatímco analýza testů vám může pomoci upozornit na chybějící případy a najít funkce, které nejsou obsaženy v tomto PR. Pokud do změny kódu nejsou zahrnuty žádné testy a jeví se jako relevantní, je vhodné si je vyžádat v rámci přezkumu.
Testy však nejsou všechno. "Nevěřte v systém příliš mnoho víry, " varuje Donow. "Jen proto, že testy proběhly neznamená, že neexistují žádné chyby."
Můžete také chtít „spustit aplikaci lokálně, aby ji funkčně otestovali a ujistili se, že funguje. Pokud to nefunguje, pak nemá smysl další revizi, “říká Ryan Verner, vývojář softwaru v 8. Light. Ačkoli si někteří recenzenti nemyslí, že by ruční testování mělo být součástí procesu kontroly kódu - zčásti kvůli době, kterou to vyžaduje - Verner věří, že je to rychlý způsob, jak zjistit, zda byste měli investovat více času, a také strategii, která pomůže omezit růst počtu nevyřízených chyb.
4. Staňte se týmovým hráčem
Klišé nabývá nového významu, pokud jde o revizi kódu. „Udělejte si čas na přezkoumání, protože je to kódová základna každého, “ říká Verner, který se zasazuje o pocit „kolektivního vlastnictví“. Jako recenzent byste se měli snažit chránit počet nevyřízených chyb před tím, než se zvětšují, s cílem poskytnout vašim tým méně práce po lince.
Pillai používá gify k oslavě schválených PR a připravených k sloučení PR svých kolegů.
Zároveň Charles Luxton, technologický vedoucí v Museu, vybízí recenzenta, aby pochopil a vzpomněl si na priority týmu. S rychlými blížícími se lhůtami a neshodami překonávajícími někdy je vytvoření pomocné položky pro nevyřízené položky, které zajistí vylepšení v budoucnu, a mezitím přidáním komentáře k dotyčnému kódu, je Band-Aid, kterou potřebujete, abyste mohli udržujte svůj tým šťastný.
Nakonec se zeptáte sami sebe, zda by kód měl smysl někomu, kdo se právě připojil k týmu a četl jej během prvních několika týdnů, pomůže udržet váš kód čitelný a srozumitelný.
5. Použijte proces pro učení a sdílení znalostí
Proces přezkumu poskytuje všem zúčastněným místo, aby získali lepší přehled o kódové základně, jazycích, rámcích a osvědčených postupech.
Matt Jeffery, technický vedoucí v Museu, radí recenzentovi, aby „architektonicky porozuměl změnám. Jedním ze způsobů je číst názvy souborů, protože pomáhají dávat kontext. Například, pokud se díváte na změnu ve vrstvě přístupu k datům víte, že se nezabýváte obchodní logikou nebo uživatelským rozhraním. “
Ke sdílení dokumentace můžete použít komentář PR na GitHubu.
Když se poučíte ze změn kódu, máte také příležitost sdílet znalosti. "Nejlepší je vysvětlit svůj názor a podpořit jej dokumentací, " říká Luxton. Odkazy, které poskytujete na podpůrné důkazy a důvěryhodné články, pomáhají nejen recenzentovi a tvůrci kódu prozkoumat různé přístupy při konečném rozhodnutí, ale také posilují jejich znalosti programování.
Pamatujte, že při prohlížení je čas na procvičení dovedností vašich lidí. "Dejte lidem výhodu z pochybností, že přemýšleli o svém přístupu, a poukazujte na různé možnosti a pokuste se rozptýlit obranyschopnost, " říká Rudder. "Zanechávám komentáře po celou dobu a zabalený komentář - tady je to, co je skvělé, tady je to, co lze zlepšit, tady je to, co je třeba změnit před sloučením."
S tímto přístupem nejen ochráníte svoji kódovou základnu před technickými dluhy, bezpečnostními hrozbami a chybami, ale také budujete svůj tým.
