Ref*ctoring a udržitelnost kódu

Posted on Posted in DevOps

Asi každý programátor se jednoho dne zamyslí nad smysluplností své práce 🙂 . A tak asi nikoho nepřekvapí, že každodenním chlebem programátorů je implementace nových funkčností nebo opravy problematických oblastí v kódu. Z toho snadno můžeme usoudit, že čistota a čitelnost kódu mají přímý vliv na duševní zdraví jednotlivých programátorů, ale i na efektivitu celého týmu. Jakým způsobem tedy zajistit jak duševní zdraví, tak udržitelnost celého projektu ?

Jak už to tak bývá v IT zvykem, tak nic nemůže být jednoduché, jak vypadá na první pohled. Dle mé osobní zkušenosti je nutné smeknout hlavně před projekty, které běží již roky a jsou pořád lehce udržitelné, dobře zdokumentované a pokryté testy. Pokud máte to štěstí a podílíte se na start up projektech nebo začínáte projekt na zelené louce, tak je pravděpodobné, že budete věnovat náležitou pozornost jak dokumentaci, tak i udržitelnosti kódu.

Nalijme si čistého vína. Realita IT je hlavně o správě dlouho bežících projektů. Firmy nechtějí každý rok vyvíjet nové systémy, protože je to poměrně drahé a hlavně firmy potřebují, aby všechny systémy fungovaly a raději se spokojí se starým systémem, než investovat do nového systému, kde je nejistý termín dodání. Na druhé straně je však trh a nároky uživatelů, které se mění každý den. Takže většina systému se musí s časem měnit a přizpůsobovat neustále novým požadavkům.

Pak už pro vykreslení celého obrázku o kvalitě softwaru stačí pouze přidat technický dluh, fluktuaci lidí, absenci testů a skomírající dokumentaci. Ano, i tak může vypadat dnešní realita informačních systémů a aplikací.

Co tedy dělat v případě, že jste postaveni před takový projekt. Prvním a asi i nejdůležitějším aspektem je zachovat klid a mít pevné nervy. Práce s takovým typem projektů od Vás bude vyžadovat velkou psychickou odolnost :). Jakým způsobem tedy vykročit ? Je několik možností. Refactoring celého projektu. Jedná se o dost radikální řešení, které Vám zřejmě nikdo neposvětí.

Další možnost je “refactoring as you go”. To znamená, že vždy když budete pracovat s kódem, tak ho necháte v trochu lepší konci, než byl před tím. To je z hlediska časové náročnosti mnohem schůdnější cesta, ale má taky své úskalí. Může se Vám stát, že při zlepšování kódu budete nahlížet pouze na detailní část řešení a výsledná změna z globálního pohledu nebude mít tížený efekt.

Výbornou přednášku na téma práce s legacy kódem měl Robert Haken v rámci Wug Days v Brně. Její záznam je možné nalézt zde. V přednášce uvidíte mnoho technik, bez kterých se při refactoringu neobejdete. Obecný princip však, lze shrnout do několika bodů. Pro efektivní a hlavně bezpečný refactoring potřebujete pokrýt co největší množství důležitých části kódu testy. Určitě můžete využívat nástroje pro statickou analýzu kódu, rozšíření pro měření cyklomatické nebo kognitivní složitosti nebo jakékoliv nástroje, které najdou code smell v projektu.

Dle mého názoru, čím striktnější a robustnější infrastrukturu si kolem projektu vystavíte, tím lepe.  Ale musíte si dát pozor, aby všechna pravidla, která chcete, aby se kontrolovala, byla opravdu smysluplná a byla pro Vás důležitá.

Při refactoringu záleží velmi na rozsahu projektu. Pokud se jedná o velký projekt, bude refactoring velmi obtížný. Určitě se nepouštějte do refactoringu při absenci verzovacího systému. Než se pustíte do jakýchkoliv zásahů, je nutné hlavně u větších projektů zmapovat vazby a vrstvy systému. Jde tak trochu o reverzní inženýrství pokud není systém dobře zdokumentovaný. Pokud používáte visual studio enterprise, tak se nebojte využít nástroj dependency diagram, který Vám ukáže vazby mezi jednotlivými částmi systému.

Z grafu je pak možné aspoň částečně usoudit, o jak moc heroický výkon půjde.

 

Osobně si myslím, že refactoring je obtížnější disciplína než programování projektů na zelené louce. Bohužel není však už tak zábavné. V současné době si myslím, že největší otázkou dnešního i budoucího software je a bude udržitelnost samotného kódu a jeho rozšiřitelnost. V případě, že Váš projekt nedosáhne na výkonnostní nebo jiné technické limity určité technologie, tak není nezbytně nutné vyvíjet celé řešení od začátku.

Pro udržitelnost kódu je nutné mít kolem projektu vybudovanou stejnou infrastrukturu jako při refactoringu. Jedena z nejdůležitějších činností a stále hodně opomíjená je code review. Bez code review bude kvalita kódu klesat a klesat, až se dostanete do bodu, kdy budete uvažovat jak udělat refactoring projektu 🙂

Každopádně na závěr jen doporučení, jaké technice se vyhnout a nepoužívat ji.

REFUCTORING… The process of taking a well-designed piece of code and, through a series of small, reversible changes, making it completely unmaintainable by anyone except yourself. Jason Gorman