Începeți modernizarea unei aplicații legacy scriind de ce trebuie să se schimbe, apoi evaluați împreună codul și producția. Stabilizați sistemul și puneți teste în jurul comportamentului de care depinde businessul înainte de a-i schimba structura. Cu această plasă de siguranță, înlocuiți sistemul bucată cu bucată, mutați datele în mod controlat și păstrați rescrierea completă pentru cazul rar în care nu prea merită păstrat nimic.
Numiți motivul de business înainte de a atinge codul
Modernizarea este scumpă, așa că începeți cu motivul. Cele frecvente sunt un runtime sau un framework ajuns la sfârșitul suportului, modificări care durează săptămâni pentru că fiecare lansare strică ceva, un sistem pe care îl înțelege o singură persoană sau o platformă care nu poate susține ce îi va trebui businessului în continuare. Fiecare motiv indică un alt prim pas.
Scrieți motivul împreună cu o măsură pe care o puteți verifica mai târziu, precum frecvența lansărilor, numărul de incidente sau cât durează până ajunge o modificare obișnuită la utilizatori. Fără ea, modernizarea devine un proiect tehnic fără sfârșit, greu de apărat la următoarea revizuire a bugetului.
Evaluați codul și producția înainte de a decide ceva
O evaluare vă spune ce aveți de fapt. Păstrați-o scurtă și încheiați-o cu un raport scris și un prim pas recomandat. Citiți codul, dar citiți și producția: jurnale, incidente, interogări lente și felul în care se fac lansările. Cele mai grave probleme se află adesea în jurul codului, nu în el.
- Versiunile de runtime, framework și biblioteci și care dintre ele nu mai primesc corecturi de securitate
- Ce părți se schimbă cel mai des și care se strică cel mai des, din istoricul versiunilor și registrul de incidente
- Acoperirea cu teste pe parcursurile de care depinde businessul
- Cum este construită, configurată și implementată aplicația și cine știe să o facă
- Modelul de date, dimensiunea lui și ce alte sisteme citesc sau scriu în aceeași bază de date
- Oamenii care cunosc sistemul și ce știu doar ei
Stabilizați mai întâi producția, ca munca să aibă o bază solidă
Dacă sistemul cade în fiecare săptămână, modernizarea va fi întreruptă în fiecare săptămână. Rezolvați mai întâi ce provoacă incidentele: adăugați monitorizare și alerte pe parcursurile critice, automatizați build-ul și deploy-ul ca lansările să fie repetabile și scoateți secretele și configurarea din cod.
Acești pași aduc beneficii imediate și fac fiecare pas ulterior mai sigur. Ei arată devreme și dacă echipa poate schimba sistemul fără să-l strice, ceea ce merită știut înainte de a vă angaja într-un plan mai mare.
Construiți o plasă de teste în jurul comportamentului pe care vă bazați
Codul legacy are de obicei puține teste, iar comportamentul lui documentat se potrivește rareori cu cel real. Înainte de a schimba structura, scrieți teste de caracterizare: teste care înregistrează ce face sistemul astăzi, inclusiv cazurile limită ciudate, astfel încât orice schimbare de comportament să apară ca un test eșuat.
Începeți de la margini, cu teste care apelează aplicația prin API sau prin interfața cu utilizatorul și verifică rezultatele, pentru că acestea supraviețuiesc schimbărilor interne. Pentru calcule și rapoarte, treceți intrări reale prin codul vechi și prin cel nou și comparați ieșirile. Adăugați teste mai fine fiecărei părți pe măsură ce o refactorizați. Articolul nostru despre actualizarea unei aplicații Java 8 critice arată aceeași plasă de siguranță aplicată unei actualizări de runtime.
Înlocuiți sistemul bucată cu bucată în loc să-l rescrieți
O rescriere completă arată curat pe hârtie, dar sistemul vechi continuă să ruleze și să se schimbe în timp ce cel nou încearcă să-l ajungă din urmă, iar fiecare comportament nedocumentat trebuie redescoperit pe parcurs. De aceea rescrierile durează atât de des mai mult decât era planificat, în timp ce businessul așteaptă.
Alternativa obișnuită este tiparul strangler fig. Puneți un strat de rutare, precum un reverse proxy sau un API gateway, în fața aplicației legacy. Construiți în codul nou câte o capabilitate pe rând și direcționați traficul pentru acea capabilitate către ea odată ce și-a dovedit funcționarea. Sistemul vechi se micșorează până poate fi oprit, iar businessul obține valoare la fiecare pas.
O rescriere poate fi totuși decizia corectă: când baza de cod este mică și comportamentul ei bine înțeles sau când platforma pe care rulează nu poate fi ținută în viață suficient de mult pentru o înlocuire treptată. Decideți pe baza unor criterii scrise, nu din frustrare.
Tratați datele ca pe o migrare de sine stătătoare
Codul poate fi înlocuit pe felii; datele sunt mai greu de împărțit. Cât timp codul legacy și cel nou au o bază de date comună, fiecare modificare de schemă trebuie coordonată. Decideți devreme care sistem este sursa de adevăr pentru fiecare tip de date și evitați ca două sisteme să scrie aceeași înregistrare fără o regulă care stabilește ce scriere câștigă.
Când o capabilitate se mută, mutați sau sincronizați datele ei în mod controlat: scripturi de migrare testate pe o copie a producției sau sincronizare continuă cât timp rulează ambele sisteme. Planificați cum le veți reconcilia pe cele două, de exemplu cu numărători zilnice și sume de control, și păstrați posibilitatea de a reveni până când cifrele se potrivesc.
Ordonați munca după risc și valoare și arătați devreme progresul
Ordonați munca astfel încât fiecare pas fie să reducă riscul, fie să livreze ceva ce businessul poate vedea. O succesiune frecventă: stabilizare și automatizare, adăugarea testelor, actualizarea runtime-ului, apoi extragerea capabilităților care se schimbă cel mai des. Părțile stabile și rar atinse pot aștepta, uneori la nesfârșit.
Păstrați planul scurt și revizuiți-l după fiecare pas, pentru că ce aflați va schimba ordinea. Inginerii noștri au lucrat așa pe sisteme critice. Prin Sopra Steria, au condus migrarea de la Java 8 la Java 16 a unei aplicații critice de tranzacționare zilnică (day-trading) de gaze, iar ca parte a echipei programului cloud Crédit Agricole am evaluat fiecare aplicație pe care am migrat-o, pentru a decide dacă o actualizăm sau o reconstruim. Dacă doriți o evaluare a propriului sistem sau o echipă care să execute planul, SDK Enterprises le face pe amândouă, sub un singur contract.
De reținut
- Scrieți motivul de business al modernizării, cu o măsură pe care o puteți verifica mai târziu.
- Evaluați codul și producția împreună înainte de a alege între actualizare, înlocuire treptată și rescriere.
- Stabilizați producția și puneți teste de caracterizare în jurul comportamentului critic înainte de a schimba structura.
- Înlocuiți sistemul bucată cu bucată, în spatele unui strat de rutare, dacă o rescriere nu este în mod clar mai mică și mai sigură.
- Planificați proprietatea asupra datelor, sincronizarea și reconcilierea ca pe o migrare de sine stătătoare.
Întrebări frecvente
Ar trebui să rescriem de la zero aplicația legacy?
De obicei, nu. O rescriere concurează cu un sistem care continuă să se schimbe și trebuie să redescopere comportamente pe care nu le-a documentat nimeni. Înlocuiți-l treptat, cu excepția cazului în care baza de cod este mică și bine înțeleasă sau este legată de o platformă care nu mai poate fi menținută în funcțiune.
Cât durează modernizarea unei aplicații legacy?
Depinde de dimensiunea sistemului, de acoperirea cu teste, de cât de încâlcite sunt datele și de cât de mult trebuie schimbat. O evaluare scurtă vă oferă un plan realist și un prim pas suficient de mic pentru a fi terminat și măsurat, în locul unei singure date pentru întregul efort.
Putem livra în continuare funcționalități în timpul modernizării?
Da, și chiar ar trebui. Înlocuirea treptată permite echipei să livreze funcționalități în codul nou în timp ce sistemul legacy continuă să ruleze. Conveniți ce parte din timpul echipei merge la modernizare, ca munca pe funcționalități să nu o absoarbă pe nesimțite.