Když dostanete žádost o kontrolu kódu od kolegy, na co se zaměříte? Co se dostává na hranici toho, co považujete za něco, co stojí za komentář? A dáváte jasně najevo, když k něčemu přidáváte komentář, vs. zvažujete něco tak důležitého, co by se mělo změnit, že bez toho by kontrola kódu neměla být sloučena?
Kontrola kódu je těžká. Viděl jsem lidi, kteří to dělají opravdu dobře a lidé to dělají opravdu špatně, ale většina z nás je někde uprostřed. Poskytování zpětné vazby lidem je těžké a vyžaduje to praxi, abyste byli schopni přijímat zpětnou vazbu k tomu velkému kusu kódu, o kterém jste posledních pár dní přemýšleli. Recenze kódu jsou tak zásadní pro tempo týmu, ale také pro jeho štěstí. Viděl jsem, že špatné recenze kódu se staly téměř nechvalně známé a poškodily týmovou kulturu, protože lidé se začnou cítit nebezpečně sdílet svůj kód ke kontrole. Dobrý proces kontroly kódu vám zajistí lepší kód v kódové základně a zároveň budete představovat váš tým, zvýšíte sdílení znalostí a poskytnete členům týmu skvělou příležitost učit se jeden od druhého.
S ohledem na to zde je několik věcí, které jsem se naučil a které mi pomohly zlepšit kontrolu kódu – recenze, které dostávám od ostatních, i recenze, které dávám ostatním:
-
Automatizujte kontrolu kódu, jak jen můžete . Kontrola kódu není pro komentáře k syntaxi nebo použití jednoduchých uvozovek nad dvojitými uvozovkami nebo pro rozpoznání proměnných, které se nepoužívají. Použijte ESLint nebo jiné podobné nástroje důsledně k prosazení stylů kódování vašeho týmu a sáhněte po formátovači kódu, jako je Prettier, který automaticky formátuje kód na styl. Ne každý nemusí milovat každou volbu formátování, ale to nevadí. Čas strávený dohadováním množství mezer k odsazení za to nestojí.
-
Jako tvůrce kódu zanechejte komentáře nebo odkazy na kontext, kde to dává smysl . Všichni jsme provedli změnu, která obsahuje kus kódu, který se na první pohled zdá divný. Možná budete muset implementovat nějakou opravdu zvláštní logiku, která nedává smysl, dokud se do toho pořádně nezahrabete, nebo jste museli obejít chybu prohlížeče a použít podivný trik CSS, aby to vypadalo tak, jak má. Někdo, kdo kontroluje váš kód, uvidí ty zvláštnosti a zeptá se na ně. Rád proaktivně komentuji své vlastní recenze kódu pomocí odkazů na dokumentaci/screenshoty/atd., které vysvětlují, proč je kód takový, jaký je (často to dělám ve skutečných komentářích ke kódu spíše než v komentářích na GitHubu). To neznamená, že kód nelze vylepšit, ale ušetří to část vysvětlování věcí recenzentovi tam a zpět. Pokud má recenzent více kontextu, může strávit méně času tím, že to zjistí, a více času přemýšlením o vašem přístupu a případných problémech, které by to mohlo způsobit.
-
Předpokládejte dobrý úmysl . Pokud recenzujete nějaký kód a nedokážete pochopit, proč to autor udělal tak, jak to udělal, platí jedna ze dvou věcí:buď je autor hrozný vývojář, nebo má nějaký kontext, který vy ne. A doufejme, že je neuvěřitelně nepravděpodobné, že by to byl první! Možná to zkusili třemi jinými způsoby, než se rozhodli pro tuto možnost, nebo může existovat požadavek na změnu, který jste špatně pochopili. Nikdy se nebojte zeptat se na srozumitelnost nebo si ověřit, že něčemu rozumíte. Ze změn kódu mého kolegy, které kontrolujem, se o kódové základně dozvím téměř tolik, jako když provádím změny sám.
-
Ujasněte si, zda požadujete změnu nebo navrhujete . Většina komentářů ke kontrole kódu spadá do jedné ze dvou kategorií:něco, čeho jste si všimli, ale necítíte se tak silně, nebo komentáře, které by podle vás měly být před sloučením změny absolutně opraveny. Pokud můžete v každém komentáři dát jasně najevo, jak silně to cítíte, a pokud je to návrh, měl by autor klidně ignorovat, pokud nesouhlasí, nebo pokud je to něco, co je třeba opravit. Tímto způsobem jako osoba, která prochází vaší recenzí na můj kód, snadno uvidím nejdůležitější komentáře a zaměřím se na ně a vím, kdy zahájit diskusi, pokud nesouhlasím s vaším návrhem, nebo když zanecháte komentář, který může se rozhodnout ignorovat nebo ne.
Určitě se k tématu kontroly kódu vrátíme v budoucích příspěvcích na blogu; jsou skvělým způsobem, jak přemýšlet o kódu, který píšete, a jeho potenciálních záměnách (v mé hlavě rád přemýšlím „co by o tom řekl recenzent?“ nebo „co není zřejmé osobě, která tento kód reviduje ?"), aby mi pomohl vylepšit můj kód.
Mezitím bych rád slyšel o postupech vašeho týmu, pokud jde o kontrolu kódu; neváhejte a dejte mi vědět na Twitteru.