Proč v Kentico refaktorujeme

O kód je třeba pečovat

Jak možná víte, nepíšeme zakázkový software – takový, který vznikne na základě požadavků zákazníka, následně se mu předá a dál se o něj vývojáři nemusí starat. Děláme přesný opak, kód si s sebou neseme po celá léta. Každá další verze našeho produktu je postavená na té předchozí – se vším všudy. Psát kód, se kterým se vývojáři potkají i o dekádu později, je velká zodpovědnost. Úplně běžně se ale stává, že daleko dříve na něm uvidíme nedostatky, kterých jsme si v době psaní nebyli vědomi. Proto se k částem programu s odstupem vracíme a refaktorujeme je.

Refaktoring je přepisování programu beze změny jeho funkčnosti. Když se nad tím zamyslíme, trávíme čas něčím, co nepřináší nic nového, ale pochopitelně stojí vývojáře jejich čas. Nebo je to jinak?

Cílem refaktoringu je snižovat složitost kódu

Je to proto, aby se v něm ostatní lépe vyznali. Dalším zásadním důvodem je zlepšování rozšiřitelnosti, aby se budoucí funkčnost snáze přidávala. Přínos refaktoringu tedy není okamžitý, o to zásadnější je ale pro budoucnost.

S každou iterací 14denního vývojového cyklu přinášíme novou funkčnost. Jednou z možností je ji vždy přilepit k té existující. Podobně, jako když vyrábíte sněhovou kouli – přidáváte sníh, dokud nejste s velikostí spokojeni. Náš software se ale na rozdíl od sněhové koule nechystáme zahodit. Neustálým přidáváním kódu bez zásahu do existujícího se zvyšuje jeho složitost. Po pár letech tak vývojáři zápasí s tím, jak zapojit prvky do existujícího celku. A to nás ve výsledku může stát více a více času.

Před přidáním nové funkčnosti se proto vždycky zamýšlíme, jak jsou na tom příbuzné části kódu. Díváme se, jestli by nebylo lepší je nejprve upravit tak, aby byly na nové požadavky lépe připraveny.

O nutnosti refaktorovat rozhodují vývojáři

Vývojáři dobře znají strukturu kódu a vědí nejlépe, které pasáže jsou obtížně pochopitelné a zaslouží si přepsání. Product Owner (PO), osoba zodpovědná za udávání směru vývoje produktu, rozhoduje o refaktorování nepřímo. Při vytváření nové funkčnosti dodá vývojový tým PO odhad pracnosti, který zahrnuje i čas pro případný refaktoring. PO pak rozhoduje, jestli se nová funkčnost bude implementovat, nebo se čas raději investuje do něčeho jiného.

Při přidávání nové funkčnosti se snažíme refaktoring neoddělovat. Chceme se vyhnout tomu, že na něj nezbyde dostatek prostoru a časem se bude technologicky dluh zvyšovat. A žít na dluh se dlouhodobě nedá.

Jak jsme implementovali Azure Search

Nedávno jsme například implementovali integraci Azure Search – indexovací služby poskytované Microsoftem jako cloudové řešení. Náš produkt už indexování vytvářeného obsahu zahrnoval, nicméně původní implementace nesplňovala požadavky některých zákazníků. Implementace byla zastaralá a z dnešního pohledu měli vývojáři o její podobě svoji vlastní představu. Azure Search pak měl doplnit existující možnosti indexování.

Na začátku jsme tak stáli před rozhodnutím, zda podporu pro Azure Search vytvořit od základu znovu, nebo do ní zahrnout prvky původního vyhledávání. I starý kód totiž obsahoval spoustu užitečné logiky a řešil problémy, na které bychom časem znovu narazili. 

I když se řešení na zelené louce může zdát atraktivnější, přineslo by nám částečnou duplicitu kódu. To představuje do budoucna další komplikace, například při opravě chyb. Původní kód však nebyl psán pro využití dalším indexovacím modulem, a proto musel nejprve nastoupit vydatný refaktoring. 

Ve výsledku jsme strávili mnoho času přepisem starého kódu. Odměnou nám však bylo následné snazší a rychlejší začlenění Azure Search do produktu.

Refaktorováním ke spokojenosti vývojářů

Z vlastní zkušenosti můžu říci, že refaktoring také příznivě ovlivňuje spokojenost samotných vývojářů. Rádi věci v produktu vylepšujeme, ale neradi přesvědčujeme management, jak moc je to potřeba. Procházením původního kódu má člověk možnost se poučit z dřívějších chyb a do budoucna se jich vyvarovat. A i ve starém kódu se najdou části, které jsou hezké. Těmi se člověk zase může inspirovat.

Každý, kdo někdy psal software, ví, že úplně se chybám vyhnout nejde. V čitelném a dobře strukturovaném kódu se ale dá opravovat rychleji. A v důsledku tak máme více času na refaktoring a implementaci nových funkčností.

Autor