Ako pomocný softvérový inžinier som vždy prezeral komentáre, ktoré som dostal, aby som sa naučil, ako sa stať lepším kódovacím programom. Ale keď prišiel čas, aby som sa pokúsil o moju prvú kontrolu kódu, uvedomil som si, že moje skúsenosti ma nepripravili na druhú stranu.
Vyvinul som závažný prípad syndrómu podvodníka, ktorý sa špirálovite znižoval otázkami: Mal by som sa vyjadriť k tomuto riadku kódu alebo to nestojí za to? Mal by som nájsť články na podporu každého komentára? Schválim to na webe? Budú ma nenávidieť? Dobre, pripúšťam, že som točil veľmi rýchlo. Ale po rozhovore s niektorými spolupracovníkmi som vedel, že v mojich obavách nie som sám.
Softwaroví inžinieri z juniorov môžu byť hodení do preskúmania kódu s predpokladom analogickým „viete, ako čítať knihu, takže viete, ako napísať knihu, čo nie je pravda, “ hovorí Jessica Rudder, skúsená inžinierka v spoločnosti GitHub.
Existujú očakávania, ktoré prichádzajú s kontrolou kódu a tento proces môže byť nervózny. Takže som robil rozhovor so siedmimi ďalšími softvérovými inžiniermi, aby som zhromaždil tipy, ako vybudovať kontrolný prístup.
1. Zamyslite sa nad celkovým dosahom
Všeobecne platí, že žiadosť o dobrý výber (PR) by sa mala týkať iba obmedzenej časti kódovej základne. Obmedzený rozsah by vám však nemal brániť v premýšľaní o zmene kódu v kontexte väčšej kódovej základne.
Nigel Munoz, bývalý komplexný inžinier v spoločnosti Muse a súčasný nezávislý softvérový inžinier, povzbudzuje recenzenta, aby premýšľal o tom, „ako táto zmena ovplyvní väčší a menší obraz.“ Vzhľadom na to, že väčší obrázok zahŕňa nájdenie akéhokoľvek technického dlhu, hľadajte kód. to je opakované, nemodulárne alebo nedodržiava najaktuálnejšie štandardné konvencie - ako aj analyzuje úpravy architektúry kódovej základne.
Sam Donow, hlavný vývojár v spoločnosti Hudson River Trading, sa domnieva, že „nie je nič príliš veľké alebo príliš malé, aby sa k nemu mohli vyjadriť. Návrhy na malé vylepšenia by mohli viesť k väčším zlepšeniam vo viacerých častiach kódovej základne. “
Môžete použiť komentár PR pre GitHub na poskytnutie pozitívnej spätnej väzby, ako aj na upozornenie, kde sa kód môže líšiť od štandardných konvencií rámca React.
Napríklad počas jedného z mojich vlastných prehľadov kódu som dostal komentár, že určité vlastnosti komponenty React boli mätúce, čo vyvolalo širšie otázky o tom, ako sa komponent používa. Nakoniec som odstránil vlastnosti z pôvodného komponentu a vytvoril som samostatný komponent, aby som objasnil správanie každého z nich a ubezpečil sa, že by sa dali použiť na viacerých miestach.
2. Zvážte bezpečnosť
Nezabudnite, že niektoré zmeny by mohli ovplyvniť viac ako len kódovú základňu. Rudder odporúča vyhodnotiť, či používateľ „mohol použiť túto funkciu na obťažovanie niekoho alebo na zneužitie systému“. Napríklad, ak nová funkcia v požiadavke na stiahnutie obsahuje vstup používateľa, vyhľadajte injekciu SQL, prístup k údajom, skriptovanie medzi lokalitami a ďalšie bezpečnostné chyby.
3. Zamerajte sa na chyby
Vaši spolupracovníci - bez ohľadu na to, ako roboticky sa môžu zdať - sú ľudia a ľudia môžu prerušiť alebo zabudnúť na funkcie. Uistite sa teda, že „preskúmate testy s rovnakou dôležitosťou ako zvyšok kódu“, odporúča Abhishek Pillai, technický vedúci v Teachers Pay Teachers. "Budú predchádzať novým chybám a budú slúžiť ako forma dokumentácie pre kohokoľvek iného, kto na tom pracuje v budúcnosti."
Čítanie testov vám môže pomôcť pochopiť funkčnosť novej funkcie a vidieť rôzne prípady, ktoré prinesie, zatiaľ čo analýza testov vám môže pomôcť poukázať na chýbajúce prípady a nájsť funkcie, ktoré nie sú obsiahnuté v tomto PR. Ak nie sú súčasťou zmeny kódu žiadne testy a zdá sa, že sú relevantné, je vhodné si ich vyžiadať v rámci preskúmania.
Testy však nie sú všetko. "Nevkladajte do systému príliš veľa viery, " varuje Donow. "Len preto, že testy prebiehajú neznamená, že tu nie sú žiadne chyby."
Môžete tiež chcieť „spustiť aplikáciu lokálne, aby ste ju funkčne otestovali a ubezpečili sa, že funguje. Ak to nebude fungovať, potom nemá zmysel ďalšie preskúmanie, “hovorí Ryan Verner, vývojár softvéru v spoločnosti 8. Light. Niektorí recenzenti si nemyslia, že by ručné testovanie malo byť súčasťou procesu kontroly kódu - čiastočne kvôli času, ktorý zaberie - Verner verí, že je to rýchly spôsob, ako určiť, či by ste mali investovať viac času na preskúmanie, ako aj stratégiu, ktorá pomôže obmedziť rast počtu nevybavených chýb.
4. Byť tímovým hráčom
Klišé nadobúda nový význam, pokiaľ ide o kontrolu kódu. „Urobte si čas na preskúmanie, pretože je to Codebase všetkých, “ hovorí Verner, ktorý sa zasadzuje za pocit „kolektívneho vlastníctva“. Vy, ako recenzent, by ste sa mali snažiť chrániť počet nevybavených chýb pred tým, ako sa budú zväčšovať, s cieľom poskytnúť vašim tím menej práce po línii.
Pillai používa gify na oslavu svojich spoluhráčov schválených a pripravených na zlúčenie.
Zároveň Charles Luxton, vedúci tímu v oblasti Muse, povzbudzuje recenzenta, aby pochopil a zapamätal si priority tímu. Vďaka rýchlo sa blížiacim sa termínom a nezhodám je niekedy potrebné vytvoriť pomocnú položku pre nevybavené položky, ktorá zabezpečí zlepšenie v budúcnosti, a medzitým vložiť komentár k príslušnému kódu. udržujte svoj tím šťastný.
Nakoniec otázka, či má tento kód zmysel pre niekoho, kto sa práve pripojil k tímu a čítal ho počas prvých niekoľkých týždňov, pomôže udržať čitateľnosť a zrozumiteľnosť kódu.
5. Použite proces na učenie a zdieľanie znalostí
Proces preskúmania poskytuje všetkým zúčastneným priestor na lepšie pochopenie kódovej základne, jazykov, rámcov a osvedčených postupov.
Matt Jeffery, vedúci tímu v oblasti Muse, radí recenzentovi, aby „architektonicky porozumel zmenám. Jedným zo spôsobov je prečítať názvy súborov, pretože pomáhajú dať kontext. Napríklad, ak sa pozeráte na zmenu vo vrstve prístupu k údajom. viete, že sa nezaoberáte obchodnou logikou alebo používateľským rozhraním. “
Na zdieľanie dokumentácie môžete použiť komentár PR na serveri GitHub.
Keď sa dozviete zo zmien kódu, máte tiež možnosť zdieľať vedomosti. „Najlepšie je vysvetliť svoj názor a zálohovať ho dokumentáciou, “ hovorí Luxton. Odkazy, ktoré poskytujete na podporné dôkazy a dôveryhodné články, pomáhajú recenzentovi a autorovi kódu nielen preskúmať konečné prístupy pri konečnom rozhodnutí, ale tiež posilňujú ich znalosti programovania.
Aj keď si tieto tipy pamätáte, nezabudnite, že preskúmanie je čas na precvičenie zručností vašich ľudí. "Dajte ľuďom výhodu z pochybností, ktoré premýšľali o svojom prístupe a poukazujú na rôzne možnosti, zatiaľ čo sa snažia rozptýliť defenzívnosť, " hovorí Rudder. "Ponechávam poznámky v celom texte a zabalený komentár - tu je to, čo je skvelé, tu je to, čo je možné vylepšiť, tu je to, čo treba zmeniť pred zlúčením."
Pri takomto prístupe budete chrániť nielen svoju kódovú základňu pred technickými dlhmi, bezpečnostnými hrozbami a bugmi, ale budete budovať aj svoj tím.
