Přejít na hlavní obsah
Proč v Kentico refaktorujeme

Proč v Kentico refaktorujeme

S pojmem refaktoring se ve své profesi setkal snad každý vývojář. Jakýkoliv kód, který napíšete, začne nevyhnutelně zastarávat. Asi každý, kdo se podíval na své dílo s odstupem času, ví, o čem mluvím. Historie naší code base v Kentico sahá do roku 2004, kdy Petr Palas začal psát iniciální verzi Kentico CMS. Tehdy na ní pracoval sám. O něco později přibral do týmu prvního vývojáře Martina Hejtmánka a postupně následovali další. Spolu s vývojáři přibývaly také řádky kódu, na které narážíme při své práci dodnes. 

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í.


Autorem článku je vývojář a Technical Leader v Kentico Marek Fešar

Chcete si číst dál?

Jak se žije Scrum Masterům v Kentico

Vlaďka Mašindová má za sebou první měsíce v Kentico na pozici Scrum Mastera. Proto jsme ji poprosili, aby sepsala svoje čerstvé postřehy. Tipnete si, co ji nejvíc překvapilo? 

V kategoriích Život v Kentico a Development

B2B marketing je pro mě větší výzva

Ačkoliv se Martina Hatoňová ucházela původně o pozici Junior UX Designera, osud tomu chtěl jinak. Kolegové si přeposlali její životopis a Martina nastoupila do marketingového oddělení, ve kterém pracu…

V kategoriích Rozhovory a Marketing

O čem mluvíme, když mluvíme o agilním přístupu k práci

To, jak si organizujeme práci dnes, není konečný stav. Věci měníme podle toho, jak se postupně rozrůstáme a zlepšujeme. Pár let zpátky u nás proběhl takový malý převrat. Agilní převrat.

V kategorii Development

Potkejte se s námi offline

  • Employer Branding Experience 2018

    Těšit se můžete na přednášku Gabriely Jakabové a Zuzky Flaškové. 

    Před 2 lety jsme se rozhodli, že na náš starý kariérní web se už nedá dívat a potřebujeme zbrusu novou prezentaci. Co ale dál? Otázky se vynořovaly rychlostí blesku. Naštěstí jsme potkali Pábení. Společně jsme propluli hlubokými vodami Employer Brandingu bez zbytečného topení. A co víc, my jsme se v něm naučili i sami plavat.