Vylepšu­jte. Neustále. Refak­tor­ing dává vývo­jářům křídla

Ve vývo­ji soft­waru jde o zásad­ní aktiv­i­tu, která pomáhá udržo­vat kód čistý, čitel­ný a efek­tivní. Jed­ná se o přepisování kódu, přičemž se jeho funkce nemění, ale zlepšu­je se struk­tu­ra a prove­dení. Uži­va­tel si těch­to změn obvyk­le nevšimne, pro vývo­jáře má však každý krok směřu­jící k lep­ší­mu kódu zásad­ní výz­nam. Refak­tor­ing můžeme přirov­nat k průběžné­mu úklidu kuchyně při vaření.

Pokud si kuchař uklízí nástro­je, nádo­by a suroviny průběžně, má lep­ší přehled a jeho práce je efek­tivnější. Jak­mile by úklid odklá­dal až na konec, risko­val by chaos, který by ho zpo­ma­lo­val a zvyšo­val pravděpodob­nost chyb. Podob­ně v soft­warovém vývo­ji platí, že průběžný refak­tor­ing zajišťu­je, že kód se snad­no udržu­je a je snad­no pochopitelný.

Ste­jně jako u metod spec­i­fi­ca­tion by exam­ple a trunk-based devel­op­ment jsou i tady stěže­jní auto­mat­ické testy. Slouží jako záchyt­ná síť, která odhalí chy­by způ­sobené změ­na­mi kódu. Bez nich by bylo těžké refak­tor­ing provádět průběžně – každá změ­na by zna­me­nala riziko chyb, jež se čas­to pro­jeví až mno­hem později. Bez testů se refak­tor­ing mění v jed­norá­zovou akci, která vyžadu­je velké množství času a zdro­jů – a to je něco, čemu se v agilním řízení snažíme vyhnout.

První z těch­to kroků spočívá v nap­sání kódu, který plní požadovanou funkci. Zkrát­ka aby fun­go­val bez ohle­du na čis­to­tu nebo efek­tiv­i­tu kódu. Jak­mile kód fun­gu­je, dalším krokem je odstraňování duplic­it, zjednodušování struk­tur a zlepšení jeho čitel­nos­ti. Ten­to krok zajišťu­je, že kód bude pocho­pitel­ný pro budoucí úpravy. V posled­ní fázi jde o zrych­lení, chcete-li o opti­mal­izaci výkonu: napřík­lad zrych­lení algo­rit­mů nebo odstranění zbytečných částí kódu.

Jak už jsem zmínil, klíčovou součástí refak­toringu jsou auto­mat­ické testy. Posky­tu­jí nástroj, který pomáhá odhalit chy­by způ­sobené změ­na­mi kódu. Bez nich by každá úpra­va před­stavo­vala riziko, že nově při­dané nebo upravené části kódu naruší funkčnost již exis­tu­jících částí. Umožňu­jí vývo­jářům okamžitě zjis­tit, zda změny kódu způ­so­bi­ly chy­by, a pomáha­jí udržet sta­bil­i­tu soft­waru i během větších změn. Pokud je kód pokry­tý testy, vývo­jáři se nebo­jí provádět průběžné úpravy. Jejich absence naopak vede k odkládání refak­toringu, což může pos­tu­pem času způ­so­bit hro­madění tech­nick­ého dluhu.

Posled­ním principem, který chci zmínit, je Make the change easy before mak­ing the easy change. O co jde? Předtím, než uděláme zamýšle­nou změnu, je tře­ba vytvořit pod­mínky, které tuto změnu usnad­ní. Opět zde můžeme sle­dovat tro­ji­ci nástro­jů či metod.

Refak­tor­ing by neměl být jed­norá­zovou aktiv­i­tou, kter­ou provádíme až tehdy, když je situ­ace kri­t­ická. Správně nas­tavený pro­ces zahrnu­je průběžné zlepšování kódu jako přirozenou součást kaž­do­den­ní práce. To nejen min­i­mal­izu­je riziko vzniku tech­nick­ého dluhu, ale také umožňu­je rych­le­jší reakce na změny požadavků.