Staré systémy majú dve spoločné veci: fungujú a robia všetkých nervóznymi. Fungujú, pretože roky reálneho používania ich vytvarovali okolo skutočného podniku. Robia ľudí nervóznymi, pretože sa ich nikto nechce dotknúť, dokumentácia je chabá a jeden z pôvodných vývojárov odišiel pred tromi zamestnaniami.
Čo sa skutočne počíta ako "legacy"
Nie každý starý systém je legacy. 10-ročná aplikácia bežiaca na podporovanom stacku, dobre otestovaná, s aktívnou údržbou, je jednoducho zrelá. Legacy zvyčajne znamená:
- Verzie platformy alebo frameworku, ktoré už nedostávajú bezpečnostné aktualizácie.
- Znalosti sústredené v jednej alebo dvoch osobách.
- Strach zo zmeny vecí, pretože malé zmeny rozbíjajú vzdialené funkcie.
- Manuálne nasadenia, manuálne testy, manuálne všetko.
- Rozširujúca sa medzera medzi tým, čo podnik potrebuje, a tým, čo systém dokáže.
Dva zlyhávajúce prístupy
- Nerobiť nič. Riziko sa skladá. Nakoniec sa niečo kritické pokazí v zlej chvíli.
- Prepísať od nuly. Veľký jednorazový prepis takmer vždy trvá dlhšie, než sa plánovalo, objaví skryté požiadavky príliš neskoro a beží paralelne so starým systémom tak dlho, že to tím vzdá.
Prístupy, ktoré skutočne fungujú, sedia medzi týmito dvoma extrémami.
Stratégia 1: Uškrtiť starý systém
Nechajte legacy systém bežať, ale postupne smerujte novú funkcionalitu cez novú vrstvu. Časom žije v novom systéme stále viac funkcií; starý sa zmenšuje, kým sa nakoniec nevypne.
Toto funguje pre weby (presun stránku po stránke), interné nástroje (presun modul po module) a integrácie (zaveďte novú API bránu, potom presmerujte volajúcich na ňu).
Stratégia 2: Modernizovať na mieste
Niekedy je architektúra v poriadku, ale stack je príliš starý. V tom prípade aktualizujte jednu vrstvu po druhej: jazyk/runtime, potom knižnice, potom framework, potom nasadenie. Pridávajte automatizované testy postupne, aby bol každý krok overiteľný. Nie je to okázalé, ale veľmi účinné.
Stratégia 3: Rozdeliť, potom modernizovať
Veľké monolitické systémy sa často ľahšie modernizujú kúsok po kúsku, keď sú švy jasné. To znamená najprv definovať hranice vnútri existujúceho systému (moduly, ohraničené kontexty), potom nahrádzať moduly nezávisle. Na hraniciach záleží viac než na voľbe technológie.
Čo robiť pred napísaním akéhokoľvek kódu
- Zapíšte si, čo systém dnes skutočne robí, nie čo mal robiť.
- Identifikujte funkcie, na ktoré sa ľudia denne spoliehajú, tie musia počas prechodu naďalej fungovať.
- Identifikujte mŕtve funkcie, často sú významným podielom kódu a mali by byť ticho vyradené.
- Urobte inventúru údajov, integrácií, oprávnení a exportov. Tu sa modernizačné projekty zvyčajne dostávajú do problémov.
- Rozhodnite, čo znamená "hotovo" v merateľných pojmoch.
Kontroly rizika, ktoré skutočne robia rozdiel
- Zálohy a otestované obnovenia, pred akoukoľvek zmenou.
- Automatizované testy pre správanie, na ktorom vám záleží, zavádzané postupne.
- Feature flagy, aby sa zmeny dali vrátiť v produkcii bez nasadenia.
- Pozorovateľnosť, logy, sledovanie chýb, kľúčové podnikové metriky, aby ste rýchlo zistili, či sa niečo zhoršilo.
- Postupné zavádzanie: nový kód beží najprv pre interných používateľov, potom pre malé percento reálnych používateľov, potom pre všetkých.
Vzor strangler fig. Namiesto rizikového veľkého jednorazového prepisu smerujete prevádzku cez tenkú fasádu, ktorá postupne preposiela stále viac požiadaviek do nových služieb, zatiaľ čo legacy systém spracúva zvyšok, kým nie je prázdny.
Príklad: minimálna trasa fasády
Malá brána môže per trasu rozhodnúť, či požiadavka ide do legacy monolitu alebo do novej služby. Napísané spôsobom nezávislým od frameworku:
app.use((req, res, next) => {
if (req.path.startsWith('/api/v2/invoices')) {
return proxy(req, res, NEW_SERVICE_URL);
}
return proxy(req, res, LEGACY_URL);
});Každý migrovaný modul presunie jednu predponu z LEGACY_URL na NEW_SERVICE_URL. Používatelia nikdy nevidia jednorazové prepnutie; tím vydáva malé, vratné kroky.
Bežná pasca: písanie nového systému a starého tak, akoby museli byť funkčne ekvivalentné v prvý deň. Nemusia. Začnite najmenším kúskom, ktorý má skutočnú podnikovú hodnotu, dokážte migračnú cestu, potom opakujte.
Bežné chyby
- Robiť z modernizácie záležitosť voľby technológie. Honosné nové stacky nepomôžu, ak sú dátový model a integrácie stále záhadou.
- Čakanie na kompletný redizajn pred opravou viditeľných problémov. Cenu platia používatelia; nadšenie umiera.
- Vypnutie starého systému príliš skoro. Nechajte oba bežať paralelne dostatočne dlho, aby ste novému dôverovali.
- Strata inštitucionálnych znalostí. Spolupracujte s ľuďmi, ktorí systém poznajú. Ich znalosti sú skutočným aktívom.
Realistický časový plán
- Stabilizujte: zálohy, monitoring, bezpečnostné záplaty, minimum testov.
- Zmapujte: zdokumentujte, čo existuje a čo sa skutočne používa.
- Prioritizujte: vyberte kúsok, ktorý je bolestivý teraz a hodnotný modernizovať najprv.
- Nahraďte: postavte novú verziu toho kúsku popri starej.
- Prepnite: smerujte prevádzku, monitorujte, opravujte problémy.
- Vyraďte: vyraďte starý kúsok až potom, čo bol chvíľu ticho.
- Opakujte pre ďalší kúsok.
