Ve světě softwaru může pět let znamenat jak systém, který je stále velmi dobře připravený na další rozvoj, tak technologický problém, který bude s každým dalším měsícem stát víc a víc.
Samotné stáří aplikace však není důvodem k její výměně.
To je jedna z nejdůležitějších věcí, které je dobré říct hned na začátku.
Neexistuje univerzální hranice, po které by se aplikace měla přepsat od nuly. Existují systémy fungující i desítky let, které mají stále smysluplnou architekturu, aktuální závislosti, dobrou dokumentaci a ověřený proces nasazování. Existují také mnohem mladší aplikace, jejichž rozvoj zkomplikovala chybná architektonická rozhodnutí, absence testů, nekontrolované závislosti nebo další rychlé opravy.
Problémem tedy není počet let.
Problémem je schopnost systému dál se měnit.
Nejdůležitější otázka nezní: "Je aplikace stará?"
Lepší otázka zní: "Kolik nás stojí další změna?"
Pokud přidání nové funkce vyžaduje stále více hodin, zapojení několika týmů, ruční testy a obcházení omezení staré architektury, začne systém generovat náklad, který v samotném kódu není vidět.
To je právě jeden z praktických projevů narůstajícího technical debt.
Technical debt lze chápat jako náklad budoucích změn vyplývající z předchozích technických rozhodnutí. Martin Fowler ho popisuje jako dodatečné úsilí, které je nutné vynakládat při úpravách systému, když jeho vnitřní kvalita ztěžuje rozvoj.
A právě proto může aplikace stále fungovat správně a zároveň být čím dál obtížnější ji rozvíjet.
Po 10 funkcích vypadá systém úplně jinak
Začátek projektu bývá často jednoduchý.
Vzniká MVP.
Pak přicházejí další požadavky:
- integrace s CRM,
- online platby,
- administrátorský panel,
- mobilní aplikace,
- nové uživatelské role,
- reporting,
- automatizace,
- API,
- integrace s externími službami,
- další jazykové verze.
Každá změna sama o sobě může být odůvodněná.
Problém nastává ve chvíli, kdy architektura nebyla navržená s ohledem na takový směr vývoje.
Pak už další funkce nejsou přidávány do stabilní konstrukce.
Jsou přidávány k předchozím výjimkám, obezličkám a kompromisům.
Podle čeho poznat, že systém začíná stárnout?
Nemusíte čekat na úplný výpadek.
Varovné signály se objevují mnohem dřív.
1. Nová funkce trvá čím dál déle
Dříve funkce zabrala pár dní. Dnes podobná změna vyžaduje několik týdnů.
Nemusí to znamenat pomalejší tým.
Může to znamenat, že stále více času zabírá pochopení stávajícího systému a jeho ochrana před důsledky změny.
2. Každá změna spouští dominový efekt
Úprava jednoho modulu způsobuje problémy na několika dalších místech.
To je signál, že komponenty jsou příliš silně provázané nebo že hranice odpovědnosti mezi nimi byly špatně určeny.
3. Testy jsou převážně ruční
Pokud každá větší změna vyžaduje ruční kontrolu desítek funkcí, náklady na nasazení rostou.
Problémem není samotný nedostatek automatizace.
Problémem je nemožnost rychle získat spolehlivou informaci, zda změna něco nezkazila.
4. Tým se bojí zasahovat do určitých částí systému
To je velmi praktický ukazatel.
Pokud existují moduly, kterých se vývojáři vyhýbají, protože "nikdo přesně neví, co se po změně stane", technické riziko je už reálným obchodním nákladem.
5. Systém závisí na zastaralých technologiích
Starý framework sám o sobě problém neznamená.
Problém nastává, když:
- už není podporovaný,
- těžko se hledají specialisté,
- závislosti nelze bezpečně aktualizovat,
- běhové prostředí je problematické,
- integrace s novými řešeními je obtížná.
Pak technologie začíná omezovat obchodní možnosti.
Je vždy nutné psát aplikaci znovu?
Ne.
To je jedna z nejčastějších chyb v přístupu k legacy software.
Úplný rewrite může být odůvodněný, ale je to vysoce rizikový podnik.
Starý systém často obsahuje desítky nebo stovky obchodních pravidel, výjimek a chování, která v dokumentaci nejsou. Když ho přepíšete od nuly, můžete velmi snadno vytvořit systém technologicky nový, ale z hlediska byznysu neúplný.
Proto je v mnoha případech lepším řešením postupná modernizace.
Jedna část systému zůstává aktivní a další oblasti jsou postupně nahrazovány novými komponentami.
Tento přístup je známý mimo jiné jako vzor Strangler Fig. Umožňuje modernizovat systém krok za krokem, dodávat hodnotu dříve a omezit riziko jednorázové migrace celého řešení.
Kdy má modernizace smysl?
Stojí za to ji zvážit, když:
- systém stále realizuje důležité obchodní procesy,
- architektura umožňuje oddělit alespoň část funkcionality,
- data lze bezpečně migrovat nebo integrovat,
- problém se týká konkrétních oblastí, nikoli celé konstrukce,
- aplikace generuje hodnotu a její úplná výměna by byla riskantní,
- systém lze modernizovat po etapách.
To je zvlášť dobré řešení u systémů, které nelze prostě na několik měsíců vypnout.
Kdy modernizace nemusí dávat smysl?
Existují také situace, kdy další zachraňování starého systému přestává být ekonomické.
Například když:
- architektura je zásadně nekompatibilní se současnými požadavky,
- klíčové technologie nejsou podporované,
- systém nemá spolehlivé testy ani dokumentaci,
- bezpečnost vyžaduje zásadní přestavbu,
- každá větší změna vyžaduje zásah do téměř celého systému,
- chybí lidé, kteří rozumějí jeho fungování,
- náklady na údržbu a rozvoj převyšují hodnotu dalšího využívání.
Pak stojí za to spočítat nejen náklady modernizace.
Je třeba spočítat také náklady na setrvání u současného řešení.
Nejdražší aplikace není vždy ta nejnákladnější na údržbu
Můžete mít systém, jehož měsíční údržba stojí relativně málo.
A zároveň každá nová funkce stojí mnohonásobně víc, než by měla.
Právě proto samotná faktura za hosting, server nebo support ještě neříká, kolik technologie skutečně stojí.
Skutečné náklady systému zahrnují také:
- čas vývoje,
- čas testování,
- náklady na chyby,
- čas nasazování,
- náklady na výpadky,
- obtížnost náboru,
- bezpečnostní riziko,
- náklady na ztrátu znalostí,
- zpoždění nových funkcí,
- obchodní omezení vyplývající z technologie.
V určitém okamžiku se technologie přestává stávat nástrojem podporujícím byznys.
Začíná být omezením byznysu.
Jak k rozhodnutí přistoupit?
Než padne rozhodnutí „přepsat od nuly“, vyplatí se provést technický audit.
Měl by zahrnovat alespoň:
Architekturu - jak je systém rozdělen a jak spolu komunikují jeho části.
Kód - kvalitu, složitost, opakování a místa, která se obzvlášť obtížně udržují.
Závislosti - frameworky, knihovny, verze a jejich podporu.
Bezpečnost - zranitelnosti, způsob správy přístupu a rizika vyplývající ze zastaralých komponent.
Testy - rozsah automatizace a možnost bezpečně zavádět změny.
CI/CD - způsob sestavování, testování a nasazování aplikace.
Data - strukturu databáze, migrace, integrace a závislosti.
Monitoring - zda je známo, co se se systémem děje po nasazení.
Proces vývoje - kolik ve skutečnosti stojí dodání další funkce.
Teprve na tomto základě lze racionálně zvážit tři scénáře:
- udržujeme a rozvíjíme,
- modernizujeme po etapách,
- budujeme nový systém.
Neexistuje jedna správná odpověď. Existuje však správný způsob, jak k odpovědi dojít.
Technologie by měla umožňovat rozvoj, a ne ho blokovat
Dobrá architektura nespočívá v tom, že systém vypadá moderně.
Spočívá v tom, že ho lze měnit tehdy, když to byznys vyžaduje.
Proto se vyplatí dívat se na aplikaci nejen optikou toho, zda dnes funguje.
Je také nutné ověřit, kolik bude stát přidání dalších funkcí za rok, za dva nebo za pět let.
Protože systém, který funguje, ale znemožňuje efektivní rozvoj, může být mnohem větším problémem než systém, který prostě vyžaduje modernizaci.
