Refaktorování: Porovnání verzí

{{Pracuje se}}

 

 

Refaktoring se začal používat mezi programátory ve smalltalku, což je čistě objektový programovací jazyk, kde existoval první nástroj na refaktoring, později, když již refaktoring byl v povědomí některých programátorů a metody refaktorování jimi byly dostatečně prověřeny, napsal Martin Fowler za velké pomoci těchto zkušených programátorů knihu Refactoring: Improving the Design of Existing Code, která je dodnes využívána jako základní příručka k poznání a naučení se správného refaktorování, což je dnes neodmyslitelná metoda moderního programování a tím se mohl refaktoring rozšířit do povědomí všech programátorů.

 

Pokud refaktoring zcela neovládáme, může být velice riskantní, jelikož upravujeme funkční kód a touto úpravou si do kódu můžeme zavést velice záludné chyby a program již nemusí být funkční. Proto mezi hlavní zásadu patří mít před samotným refaktorováním připravenou dobrou sadu testů, kterou spustíme po každé změně.

 

 

Martin Fowler ve své knize Refaktoring uvádí 22 takzvaných pachů v kódu, které jsou zvěstí toho, že bychom kód měli začít refaktorovat a zároveň uvádí, jaké techniky jsou pro který pach třeba. To ale neznamená, že to tak vždy musí být, samozdřejmě vždy závisí na konkrétní situaci. Já zde nastíním pouze některé pachy v kódu, ty nejzákladnější a většinou i nejčastější, ale pokud se o nich chcete dozvědět více, vřele doporučuji knihu Refaktoring.

Další důvody, kdy začít s refaktoringem: pokud máme v programu složité struktury podmínek, měli bychom refaktorovat, stejně tak jako bychom měli refaktorovat vždy před přidáním nějaké nové funkcionality. Pokud nemůžeme najít chybu v kódu, je to další důvod, proč bychom měli refaktorovat. A v neposlední řadě je tu zásada tří - refaktorovat místo třetího opakovaní - pravidlo Dona Robertsa.

 

Při refaktorování nikdy nesmíme zapomenout na metaforu dvou klobouků od Kenta Becka: v jednom klobouku přidáváme funkcionalitu a neměníme strukturu, v druhém klobouku měníme strukturu a nepřidáváme funkcionalitu. Můžeme je měnit klidně každých 5 minut, ale vždy musíme vědět, co děláme, tedy jaký klobouk máme na hlavě a nemíchat přidávání funkcionality s refaktoringem.

 

Obecně refaktoring nemají rádi vedoucí projektů, protože může trvat velice dlouho, projekt zbrzdit a nepřinést na první pohled žádný viditelný výsledek. Pokud je i váš vedoucí projektu proti refaktoringu, je třeba vyzdvihnout především jeho pozitiva mimo jiné i to, že náklady na budoucí provoz se sníží, stejně tak jako doba potřebná k přidání nové funkčnosti a těmito argumenty se ho snažit přesvědčit. Myslím ale, že v dnešní době, kdy refaktoring je již hodně populární a především známý s ním nebude u vedoucích projektů problém.

 

Zde uvádím výčet technik refaktoringu, které jsou detailně popsané v knize Refaktoring.

 

*nahradit algoritmus

*nahradit dočasnou proměnnou dotazem

*vyjmout metodu – z dlouhé metody vyjmeme část kódu, který dáme do nové metody

*zavést vysvětlující proměnnou

*odstranit prostředníka

*přesunout metodu a přesunout položku – přesun do vhodné třídy

*zavést místní rozšíření

 

*nahradit datovou položku objektem

*nahradit pole objektem

*zavést předpoklad

 

*nahradit dědičnost delegováním

*nahradit delegování dědičností

*vytvořit šablonovou metodu

*zrušit hierarchii

'''Zjednodušení volání metod'''

*nahradit chybový kód výjimkou

*zavést objekt pro parametry

 

*roztrhnout dědičnost

*převést procedurální návrh do objektů

*oddělit datový model od prezentace

 

*duplikovat sledovaná data

*nahradit kód typu podtřídami

 

 

Existuje zde vazba mezi refaktoringem a návrhovými vzory a to taková, že vzory vlastně popisují definovaný cíl a naopak refaktorování popisuje způsob jak se k tomuto cíli dostat. Pokud se podíváte na jednotlivé techniky, poznáte již z jejich jména, že mají co dočinění s návrhovými vzory, viz vytvořit šablonovou metodu, zavést objekt null, nahradit konstruktor tovární metodou nebo nahradit kód typu stavem nebo strategií.

 

 

Některé postupy při refaktorování je možné přesně definovat a zcela automatizovat a dnes je již v moderních vývojových prostředích jako je Eclipse a další nabízena podpora při refaktoringu. Technika vyjmout metodu z dlouhé metody již tedy není vůbec složitý a prakticky u něj nemusíte ani moc přemýšlet, udělá jej za vás program. Někteří si při psaná kódu ani neuvědomují, že např. změna názvu proměnné je také refaktoring, který za nás provede program, avšak dříve tato změna byla velmi náročná.