Na co se soustředit při revizích kódu

Můj pohled na to, na co se soustředit při revizích kódu (angl. code review).

Když provádím revizi kódu, tak se soustředím především na následující čtyři body, seřazené sestupně podle důležitosti:

1. Dělá kód to, co má, nic nechybí, a nedělá něco, co nemá? Pokud se např. jedná o revizi kódu přidávajícího podporu pro nový výstupní formát, tak je potřeba ověřit, že program je schopen generovat kód v daném formátu (dělá, co má), že ve výstupu nechybí žádná informace (nic nechybí), a že je stále možné používat původní výstupní formáty (nedělá něco, co nemá), tj. že omylem nedošlo k odstranění podpory pro původní formáty. Mezi další body, které s tímto souvisí, patří:
   • Lze projekt přeložit (bez hlášených varování) a spustit?
   • Existují na nový či upravený kód testy? Pokud ne, je potřeba je napsat. Kódu bez testů se nedá věřit.
   • Prochází všechny testy?
   • Byla společně s kódem upravena externí dokumentace? Aby nezastarávala.
   • Byla zachována zpětná kompatibilita? Pokud ne, je potřeba se tomu přizpůsobit (např. zvýšením čísla verze).
2. Je kód bezpečný? Typické otázky začínají na "Co se stane, když..." Například:
   • Dochází ke korektnímu zpracování chyb a zotavení z nich (angl. error handling)?
   • Nemůže program spadnout? Např. přístupem přes nulový ukazatel, přístupem za hranici podle, neočekávaným vstupem.
   • Neobsahuje kód bezpečnostní díry? Např. code injection, chybějící autentizace/autorizace, zpřístupnění citlivých údajů.
   • Pokud kód spouští více vláken, je thread safe?
   • Nedochází k tzv. resource leaks? Např. neuvolňování paměti, nezavírání otevřených souborů a spojení.
3. Je kód čitelný, udržovatelný, a není zbytečně neefektivní? Zde patří rady týkající se použitého jazyka, standardní knihovny, a knihoven třetích stran. Například:
   • Zapadá kód do projektu z návrhového hlediska, nebo do něj byl doslova "dolepen", např. přes tzv. shotgun surgery?
   • Nelze nějaká konstrukce zapsat idiomatičtějším způsobem?
   • Nelze kód zkrátit využitím standardní knihovny či externích knihoven?
   • Nedošlo k duplikaci kódu (copy&paste)?
   • Neobsahuje kód zbytečnosti, které jej bezdůvodně zdržují?
4. Vyhovuje kód programovacím konvencím pro daný projekt? I když projekt nemá žádné explicitní směrnice, snažte se alespoň o to, aby kód v rámci jednoho souboru byl jednotný. Například:
   • Mezery vs tabulátory (nemixujte je, prosím).
   • Pojmenování proměnných (camelCase vs snake_case).
   • Obecně vše týkající se formátování kódu (pozice složených závorek, zalamování řádků, atd.).
   • Gramatika a překlepy v komentářích a dokumentaci.

Update 2020-04-28: Pokud by vás zajímalo víc detailů k revizím kódu, tak mrkněte na záznam mé přednášky Pull requesty, revize kódu a vysoce kvalitní kód.

Související články u mě na blogu:

• Vysoce kvalitní kód
• Čistý kód, který funguje
• Udržitelný vývoj
• Důvody, proč psát jednotkové testy
• Proč rozlišovat jednotkové a integrační testy