Refaktoring II (přínosy, rizika)

S přibývajícími úpravami kódu se pomalu vytrácí jeho struktura a klesá čitelnost. Kód se duplikuje a zamotává. S další takovouto změnou je na čase zvážit refaktoring.

Co nám to přinese?

  • Lepší srozumitelnost kódu - nejenže výsledný kód bude lépe srozumitelný, ale i během procesu refaktorování sami dobře pochopíme, co daný kus kódu dělá. Osobně je toto pro mě nejlepší způsob, jak se dobře seznámit s cizím kódem. Díky zavádění vlastních (zpočátku drobných) změn jsem schopen kód dobře pochopit.
  • Odhalení chyb - během refaktorování můžeme narazit na doposud skryté chyby.
  • Rychlejší a méně chybový vývoj - toto ovšem není pravda v první fázi, kdy naopak čas ztrácíme a můžeme zavést nové chyby. Je třeba dobře zvážit, zdali daný kus kódu stojí za to refaktorovat. Pokud se jedná o jednorázovou či dočasnou úpravu, pak bych se do větších akcí raději nepouštěl, ale pokud se jedná o běžně používanou komponentu, pak se nám refaktoring výhledově určitě vyplatí.

Kdy refaktorovat?

Refaktoring není pravidelný ani plánovaný proces. Refaktorovat bychom měli tehdy, když je to potřeba a výsledky refaktoringu bychom měli ihned využít. Klasickým případem je před přidáním nové funkcionality, ať už z důvodu, že po refaktoringu to bude snazší, nebo z důvodu, že prvně potřebuji daný kód pochopit. Dalšími případy jsou během code review či společně s opravou nějaké chyby. Nemá smysl refaktorovat “naprázdno”.

Kdy raději ne?

Refaktoring se nemusí vyplatit časově, je třeba zvážit, zdali má smysl tento kus přepisovat nebo zdali je zásah do něj ojedinělý. To samozřejmě není možné vždy dopředu říct a nezbývá nám než se spolehnout na náš odhad. Druhým (pro mě větším) rizikem je zavlečení nechtěné chyby. Opět je třeba zvážit, zdali jsme schopni změny náležitě otestovat a jaké škody může chyba napáchat (například zásahy do košíku na eshopu jsou vždy rizikové).

Příště se podíváme na typické (anti)vzory v kódu, které volají po refaktoringu.


Zdroj Martin Fowler - Refaktoring

Článek obsahuje 0 komentářů