Když se řekne "legacy code", asi se vám vybaví dost netechnické pojmy: Hnůj, špagety, případně roztoky proměnlivé hustoty vyúsťující z různých tělesných otvorů. Starý kód je po technické stránce téměř vždy problém, protože je těžké mu rozumět a změny mohou mít nezamýšlené vedlejší efekty. Jenže je tu i jiný pohled: Starý kód je užitečný, má klienty a vydělává peníze. Už jen fakt, že přežil tak dlouho, je známka toho, že ho někdo potřebuje. Ať se nám to líbí nebo ne, ten starý hnusný kód bez testů je úspěšný kód. A o tom byl track "Legacy & Big Systems" na konferenci GOTO 2013 Amsterdam, kam jsem se podíval díky Vendavu.
Předchozí díl: Big Data a NoSQL
Se stim smiř
Psát aplikaci "na zelené louce" by chtěl každý. Proto se i u zkušených programátorů setkáme s názorem, že by bylo nejlepší starý kód zahodit a aplikaci napsat znovu a (tentokrát) dobře. My co jsme už takový přepis zažili víme, že to sice jde, ale je to daleko náročnější, než se na začátku zdá. Starý kód v sobě akumuluje letitou zkušenost, hlavně nezdokumentované use casy a hraniční situace, které už dávno nikdo nezná a nedokáže popsat, takže vám nikdo neřekne, jestli je musíte v nové aplikaci zpětně podporovat nebo ne (respektive řekne vám to až zákazník formou kritické chyby a rollbacku systému, což může být dost nepříjemné). Ostatně je tu slavný precedens, kdy přepis programu vedl k zániku kdysi nejoblíbenějšího webového prohlížeče a s ním celé firmy.
Legacy code je prostě realita, kterou je potřeba přijmout jako fakt a se kterou je potřeba se naučit zacházet.
Pojem legacy code, doslova "zděděný kód", byl původně používán pro kód, který jsme převzali od někoho jiného. Jeho autoři buď už opustili firmu, nebo pracují na něčem jiném, nebo byl zakoupen od jiné firmy. Časem se význam rozšířil na obtížně čitelný kód s nekonzistentní strukturou, vysokým počtem vazeb a zbytečnou komplexitou, který je těžké měnit bez nechtěných vedlejších efektů. Jednodušší definici nabídl Michael Feathers v knize Working Effectively with Legacy Code: Legacy code je jednodušše kód bez testů. Nezáleží na tom, jak dobře je napsaný, jak je hezký ani jestli respektuje principy OOP. Kód bez testů je špatný, protože neumožňuje dělat změny rychle a verifikovatelně.
Legacy je výzva
To ovšem neznamená že, máme hodit flintu do žita a patlat kód stejným způsobem, jako to dělali naši předchůdci. Legacy je výzva: Dokážete starý kód zkrotit pomocí testů? Dokážete refaktorovat staré kousky tak, abyste přitom nic nerozbili? Dokážete starý systém inovovat? A dokážete přitom zůstat pragmatičtí a produktivní? A bez psychického poškození?
A o tom byla přednáška Dave Thomase Legacy Evolution - The Innovation Opportunity. Jako programátoři si musíme uvědomit, že každá změna do legacy systému musí přinést nějakou hodnotu pro zákazníky/uživatele, jinak nemá smysl. Samotné čištění kódu a splácení technického dluhu nemůže být cílem samo o sobě, spíše by se mělo dít v rámci změn, které hodnotu přinášejí. Jaké to tedy jsou? Třeba přidání nové funkcionality (thank you mister obvious), zjednodušení přístupu k datům (přes standardní rozhraní jako ODBC, REST nebo SOAP), zlevnění či zrychlení nějakého workflow. Soustřeďte se na data a jejich toky, protože data jsou to nejcennější co organizace má a hlavní funkcí informačních systémů je transformace a zpřístupnění dat.
Čistý refaktoring přitom má smysl, pokud se zaměříte na nějakou problematickou část kódu s omezeným rozsahem. Cílem by mělo být něco s praktickým dopadem, třeba zrychlení zpracování dat, nebo předělání třídy, která se často musí měnit, nebo ve které je často nalezena chyba. Najít takový kus kódu můžete pomocí nějaké smysluplné metriky, třeba File Churn vs. Complexity.
Podle Thomase je i v legacy systémech je dost příležitostí pro zavádění nových technologií, namátkou:
- Nové jazyky (ruby, clojure, nodejs) pro skriptování testů a deploymentu
- NoSQL databáze jako rychlá cache v rozhraní nad starým systémem
- Cloud pro deployment a testování aplikace
- "Use F# or Scala for algorithms, C# and Java for muddleware"
S metrikami opatrně
Staré systémy bývají dost rozsáhlé a pracuje na nich spousta lidí a tak je užitečné sledovat nějaké metriky kódu, abychom měli základní představu o směru, kterým se ubíráme. Že jsou metriky dvousečná zbraň a že můžou v rukou necitlivého profesionálního manažera zlikvidovat motivaci lidí i kvalitu kódu je známá věc, a Michael Feathers ve své přednášce The Metrics Trap nastínil pár způsobů jak se bránit.
Produktivitu softwarového vývoje nelze měřit, nicméně stále jsou manažeři, kteří se zaklínají populární formulkou "co neměříš, neřídíš", přesto že už ji odvolal i její autor. Stejné je to s kvalitou. Když se zaměříte na jednu věc a nastavíte kvantitativní hranice, které nelze překročit, ostatní věci budou trpět. Například podle Featherse vede vynucování vysoké code coverage k hůře čitelným testům. Proto je lepší používat "tiché alarmy" (silent alarms), které mají za úkol vyvolat diskusi. Například je dobré měřit komplexitu kódu, ale místo aby build server automaticky zamítnul commit, když se komplexita zvýší nad nějakou hodnotu, je lepší poslat mail a upozornit ostatní, že se tak stalo. Jsou totiž rozumné případy, kdy je dobré pravidlo porušit. Srozumitelnost je důležitější než metriky.
A co dělat když narazíte na manažera staré školy, kterého nelze přesvědčit o riziku přeceňování metrik? Zavalte ho metrikami! Tuto strategii Feathers nazývá "metrics deluge" a spočívá v měření velkého množství parametrů. Čím více je metrik, tím těžší je brát jednu z nich vážně. Je také dobré používat metriky které jdou proti sobě, např. LOC versus duplicita kódu. Výsledky měření neukládejte, aby někoho nenapadlo stanovit cíle v duchu socialistických hesel "zvýšit code coverage o 10 procent".
No a když to nezabere? Pak je ve vaší firmě špatně nastavená firemní kultura. A to je špatná zpráva. Firemní kultura je největší bariérou zavádění agilních technik, a změna kultury je ten nejtěžší a nejdelší boj, do kterého se můžete pustit. Když vás někdo začne hodnotit podle LOC nebo code coverage, je načase zvážit přestup. Protože jen ve svobodném prostředí je práce s legacy systémem výzva; v legacy prostředí je legacy code jen opruz.
Příště se podíváme na to, jak chce Erik Meijer změnit svět databází.
Kolik z toho je z Amsterdamu a kolik tvych vlastnich nazoru? Ne, ze bych s nimi nesouhlasil.
@Boris Většina vychází z těch dvou přednášek a té knížky od Featherse, převyprávěno vlastními slovy;) To o firemní kultuře je z keynote od Fowlera (přiznávám, bez uvedení zdroje). Jestli to vypadá jako moje vlastní názory, tak je to proto, že jsem souhlasil s tím co jsem tam slyšel:)
ázvy tříd