Vo svete softvéru môže päť rokov znamenať ako systém stále veľmi dobre pripravený na ďalší rozvoj, tak aj technologický problém, ktorý bude s každým ďalším mesiacom stáť čoraz viac.
Samotný vek aplikácie však nie je dôvodom na jej výmenu.
To je jedna z najdôležitejších vecí, ktoré sa oplatí povedať na začiatku.
Neexistuje univerzálna hranica, po ktorej treba aplikáciu prepísať odznova. Sú systémy fungujúce niekoľko desiatok rokov, ktoré stále majú zmysluplnú architektúru, aktuálne závislosti, dobrú dokumentáciu a overený proces nasadzovania. Sú aj oveľa mladšie aplikácie, ktorých rozvoj sťažili chybné architektonické rozhodnutia, chýbajúce testy, nekontrolované závislosti alebo ďalšie rýchle opravy.
Problémom teda nie je počet rokov.
Problémom je schopnosť systému ďalej sa meniť.
Najdôležitejšia otázka neznie: "Je aplikácia stará?"
Lepšia otázka znie: "Koľko nás stojí ďalšia zmena?"
Ak pridanie novej funkcie vyžaduje čoraz viac hodín, zapájanie viacerých tímov, manuálne testy a obchádzanie obmedzení starej architektúry, systém začína generovať náklady, ktoré nie sú viditeľné v samotnom kóde.
To je jeden z praktických prejavov narastajúceho technical debt.
Technical debt možno chápať ako náklad budúcich zmien vyplývajúci z predchádzajúcich technických rozhodnutí. Martin Fowler ho opisuje ako dodatočné úsilie, ktoré treba vynakladať pri úpravách systému, keď jeho vnútorná kvalita brzdí rozvoj.
A práve preto môže aplikácia stále fungovať správne a zároveň byť čoraz náročnejšia na rozvoj.
O 10 funkcií neskôr systém vyzerá úplne inak
Začiatok projektu býva často jednoduchý.
Vznikne MVP.
Potom pribúdajú ďalšie požiadavky:
- integrácia s CRM,
- online platby,
- administrátorský panel,
- mobilná aplikácia,
- nové roly používateľov,
- reporting,
- automatizácie,
- API,
- integrácie s externými službami,
- ďalšie jazykové mutácie.
Každá zmena sama osebe môže byť opodstatnená.
Problém nastáva vtedy, keď architektúra nebola navrhnutá s ohľadom na takýto smer rozvoja.
Potom sa ďalšie funkcie už nepridávajú do stabilnej konštrukcie.
Pridávajú sa k predchádzajúcim výnimkám, obchádzkam a kompromisom.
Podľa čoho spoznáte, že systém začína starnúť?
Netreba čakať na úplnú poruchu.
Varovné signály sa objavujú oveľa skôr.
1. Nová funkcia trvá čoraz dlhšie
Predtým funkcia trvala niekoľko dní. Dnes podobná zmena vyžaduje niekoľko týždňov.
Nemusí to znamenať pomalší tím.
Môže to znamenať, že čoraz viac času zaberá pochopenie existujúceho systému a jeho ochrana pred dôsledkami zmeny.
2. Každá zmena spúšťa domino efekt
Úprava jedného modulu spôsobuje problémy na viacerých ďalších miestach.
Je to signál, že komponenty sú príliš úzko prepojené alebo hranice zodpovednosti medzi nimi boli zle určené.
3. Testy sú prevažne manuálne
Ak si každá väčšia zmena vyžaduje manuálne preverenie desiatok funkcií, náklady na nasadenie rastú.
Problémom nie je samotná absencia automatizácie.
Problémom je nemožnosť rýchlo získať spoľahlivú informáciu, či zmena niečo nepokazila.
4. Tím sa bojí zasahovať do určitých častí systému
To je veľmi praktický ukazovateľ.
Ak existujú moduly, ktorých sa programátori vyhýbajú, pretože "nik presne nevie, čo sa stane po zmene", technické riziko je už reálnym biznisovým nákladom.
5. Systém závisí od zastaraných technológií
Starý framework sám osebe neznamená problém.
Problém nastáva vtedy, keď:
- už nie je podporovaný,
- je ťažké nájsť špecialistov,
- závislosti sa nedajú bezpečne aktualizovať,
- behové prostredie je problematické,
- integrácia s novými riešeniami je sťažená.
Vtedy technológia začína obmedzovať biznisové možnosti.
Treba aplikáciu vždy písať odznova?
Nie.
To je jedna z najčastejších chýb v prístupe k legacy software.
Úplný rewrite môže byť opodstatnený, ale je to vysoko rizikový projekt.
Starý systém často obsahuje desiatky alebo stovky biznisových pravidiel, výnimiek a správania, ktoré nie sú v dokumentácii. Pri prepise od nuly je veľmi ľahké vytvoriť technologicky nový, ale biznisovo neúplný systém.
Preto je v mnohých prípadoch lepším riešením postupná modernizácia.
Jedna časť systému zostáva aktívna a ďalšie oblasti sa postupne nahrádzajú novými komponentmi.
Takýto prístup je známy napríklad ako vzor Strangler Fig. Umožňuje modernizovať systém krok za krokom, doručovať hodnotu skôr a znižovať riziko jednorazovej migrácie celého riešenia.
Kedy má modernizácia zmysel?
Oplatí sa ju zvážiť, keď:
- systém stále realizuje dôležité biznisové procesy,
- architektúra umožňuje vyčleniť aspoň časť funkcionality,
- dáta sa dajú bezpečne migrovať alebo integrovať,
- problém sa týka konkrétnych oblastí, nie celej konštrukcie,
- aplikácia prináša hodnotu a jej úplná výmena by bola riziková,
- systém možno modernizovať po etapách.
Je to obzvlášť dobré riešenie pri systémoch, ktoré nemožno jednoducho vypnúť na niekoľko mesiacov.
Kedy modernizácia nemusí dávať zmysel?
Sú aj situácie, v ktorých ďalšie zachraňovanie starého systému prestáva byť ekonomické.
Napríklad keď:
- architektúra je fundamentálne nezlučiteľná so súčasnými požiadavkami,
- kľúčové technológie sú nepodporované,
- systém nemá spoľahlivé testy ani dokumentáciu,
- bezpečnosť si vyžaduje zásadnú prestavbu,
- každá väčšia zmena si vyžaduje zásah do takmer celého systému,
- chýbajú ľudia, ktorí rozumejú jeho fungovaniu,
- náklady na údržbu a rozvoj prevyšujú hodnotu ďalšieho používania.
Vtedy sa oplatí vypočítať nielen náklady na modernizáciu.
Treba vypočítať aj náklady na zotrvanie pri súčasnom riešení.
Najdrahšia aplikácia nie je vždy tá najdrahšia na údržbu
Môžete mať systém, ktorého mesačná údržba stojí relatívne málo.
A zároveň každá nová funkcia stojí mnohonásobne viac, než by mala.
Aj preto samotná faktúra za hosting, server alebo support ešte nehovorí, koľko technológia v skutočnosti stojí.
Skutočné náklady systému zahŕňajú aj:
- čas vývoja,
- čas testovania,
- náklady na chyby,
- čas nasadzovania,
- náklady na výpadky,
- ťažkosť náboru,
- bezpečnostné riziko,
- náklad straty znalostí,
- oneskorenie nových funkcií,
- obmedzenia biznisu vyplývajúce z technológie.
V určitom momente sa technológia prestáva byť nástrojom podporujúcim biznis.
Začína byť obmedzením biznisu.
Ako pristúpiť k rozhodnutiu?
Skôr než padne rozhodnutie „prepíšeme to odznova“, oplatí sa urobiť technický audit.
Mal by zahŕňať aspoň:
Architektúru - ako je systém rozdelený a ako medzi sebou komunikujú jeho prvky.
Kód - kvalitu, zložitosť, opakovateľnosť a miesta obzvlášť náročné na údržbu.
Závislosti - frameworky, knižnice, verzie a ich podporu.
Bezpečnosť - zraniteľnosti, spôsob správy prístupu a riziká vyplývajúce zo zastaraných komponentov.
Testy - rozsah automatizácie a možnosť bezpečne zavádzať zmeny.
CI/CD - spôsob budovania, testovania a nasadzovania aplikácie.
Dáta - štruktúru databázy, migrácie, integrácie a závislosti.
Monitoring - či je známe, čo sa so systémom deje po nasadení.
Proces vývoja - koľko skutočne stojí dodanie ďalšej funkcie.
Až na tomto základe možno racionálne zvážiť tri scenáre:
- udržiavame a rozvíjame,
- modernizujeme postupne,
- budujeme nový systém.
Neexistuje jedna správna odpoveď. Existuje však správny spôsob, ako sa k odpovedi dopracovať.
Technológia by mala umožňovať rozvoj, nie ho blokovať
Dobrá architektúra nespočíva v tom, že systém vyzerá moderne.
Spočíva v tom, že sa dá meniť vtedy, keď to vyžaduje biznis.
Preto sa oplatí pozerať na aplikáciu nielen cez prizmu toho, či dnes funguje.
Treba tiež skontrolovať, koľko bude stáť pridanie ďalších funkcií o rok, dva alebo päť rokov.
Pretože systém, ktorý funguje, ale znemožňuje plynulý rozvoj, môže byť oveľa väčším problémom než systém, ktorý jednoducho vyžaduje modernizáciu.
