În lumea software-ului, cinci ani pot însemna atât un sistem încă foarte bine pregătit pentru dezvoltare ulterioară, cât și o problemă tehnologică ce va costa din ce în ce mai mult cu fiecare lună care trece.
Vârsta aplicației în sine nu este însă un motiv pentru înlocuirea ei.
Acesta este unul dintre cele mai importante lucruri de spus la început.
Nu există o limită universală după care o aplicație trebuie rescrisă de la zero. Există sisteme care funcționează de peste zece ani și care încă au o arhitectură sensată, dependențe actuale, documentație bună și un proces de implementare verificat. Există și aplicații mult mai tinere, a căror dezvoltare a fost îngreunată de decizii arhitecturale greșite, lipsa testelor, dependențe necontrolate sau corecții rapide succesive.
Așadar, problema nu este numărul de ani.
Problema este capacitatea sistemului de a se schimba în continuare.
Întrebarea cea mai importantă nu este: "Aplicația este veche?"
O întrebare mai bună este: "Cât ne costă o schimbare în plus?"
Dacă adăugarea unei noi funcționalități necesită tot mai multe ore, implicarea mai multor echipe, teste manuale și ocolirea limitărilor arhitecturii vechi, sistemul începe să genereze un cost care nu se vede în codul propriu-zis.
Aceasta este una dintre manifestările practice ale acumulării technical debt.
Technical debt poate fi înțeles ca un cost al modificărilor viitoare care rezultă din decizii tehnice anterioare. Martin Fowler îl descrie ca efortul suplimentar care trebuie depus la modificarea sistemului, atunci când calitatea sa internă îngreunează dezvoltarea.
Și tocmai de aceea aplicația poate funcționa în continuare corect și, în același timp, poate deveni tot mai greu de dezvoltat.
10 funcționalități mai târziu, sistemul arată complet diferit
Începutul proiectului este adesea simplu.
Se creează un MVP.
Apoi apar cerințe noi:
- integrare cu CRM-ul,
- plăți online,
- panou administrativ,
- aplicație mobilă,
- roluri noi de utilizatori,
- raportare,
- automatizări,
- API,
- integrări cu servicii externe,
- noi versiuni lingvistice.
Fiecare schimbare, luată separat, poate fi justificată.
Problema apare atunci când arhitectura nu a fost proiectată având în vedere o astfel de direcție de dezvoltare.
Atunci noile funcționalități nu mai sunt adăugate unei construcții stabile.
Sunt adăugate peste excepțiile, ocolirile și compromisurile anterioare.
Cum îți dai seama că un sistem începe să se învechească?
Nu trebuie să aștepți o defecțiune totală.
Semnalele de avertizare apar mult mai devreme.
1. O funcționalitate nouă durează din ce în ce mai mult
Altădată o funcționalitate dura câteva zile. Azi o schimbare similară necesită câteva săptămâni.
Asta nu înseamnă neapărat o echipă mai lentă.
Poate însemna că tot mai mult timp este consumat de înțelegerea sistemului existent și de protejarea lui de efectele schimbării.
2. Fiecare schimbare declanșează un efect de domino
Modificarea unui modul provoacă probleme în mai multe alte locuri.
Acesta este un semn că modulele sunt prea puternic legate între ele sau că limitele de responsabilitate dintre ele au fost stabilite greșit.
3. Testele sunt în principal manuale
Dacă fiecare schimbare importantă necesită verificarea manuală a zeci de funcționalități, costul implementării crește.
Problema nu este lipsa automatizării în sine.
Problema este lipsa posibilității de a obține rapid o informație credibilă despre faptul că o schimbare a stricat ceva sau nu.
4. Echipa se teme să atingă anumite părți ale sistemului
Acesta este un indicator foarte practic.
Dacă există module pe care programatorii le evită pentru că "nimeni nu știe exact ce se va întâmpla după o modificare", riscul tehnic a devenit deja un cost de business real.
5. Sistemul depinde de tehnologii învechite
Un framework vechi în sine nu înseamnă o problemă.
Problema apare atunci când:
- nu mai este suportat,
- este greu să găsești specialiști,
- depedențele nu pot fi actualizate în siguranță,
- mediul de rulare este problematic,
- integrarea cu soluții noi este îngreunată.
Atunci tehnologia începe să limiteze posibilitățile de business.
Trebuie întotdeauna rescrisă aplicația de la zero?
Nu.
Aceasta este una dintre cele mai frecvente greșeli în abordarea legacy software.
Un rewrite complet poate fi justificat, dar este o inițiativă cu risc ridicat.
Un sistem vechi conține adesea zeci sau sute de reguli de business, excepții și comportamente care nu apar în documentație. Rescriindu-l de la zero, poți crea foarte ușor un sistem nou din punct de vedere tehnologic, dar incomplet din punct de vedere business.
De aceea, în multe cazuri, o soluție mai bună este modernizarea etapizată.
O parte a sistemului rămâne activă, iar alte zone sunt înlocuite treptat cu componente noi.
Această abordare este cunoscută, printre altele, ca modelul Strangler Fig. Permite modernizarea sistemului pas cu pas, livrarea valorii mai devreme și reducerea riscului unei migrări unice a întregii soluții.
Când are sens modernizarea?
Merită luată în considerare atunci când:
- sistemul realizează în continuare procese de business importante,
- arhitectura permite separarea cel puțin a unei părți din funcționalitate,
- datele pot fi migrate sau integrate în siguranță,
- problema vizează anumite zone, nu întreaga construcție,
- aplicația generează valoare și înlocuirea ei completă ar fi riscantă,
- sistemul poate fi modernizat etapizat.
Aceasta este o soluție deosebit de bună în cazul sistemelor care nu pot fi pur și simplu oprite pentru câteva luni.
Când modernizarea poate să nu aibă sens?
Există și situații în care salvarea în continuare a unui sistem vechi încetează să mai fie economică.
De exemplu, atunci când:
- arhitectura este fundamental incompatibilă cu cerințele actuale,
- tehnologiile-cheie nu mai sunt suportate,
- sistemul nu are teste sau documentație de încredere,
- securitatea necesită o reconstrucție profundă,
- fiecare schimbare importantă necesită intervenții în aproape întregul sistem,
- lipsesc oameni care îi înțeleg funcționarea,
- costurile de mentenanță și dezvoltare depășesc valoarea utilizării în continuare.
Atunci merită calculat nu doar costul modernizării.
Trebuie calculat și costul de a rămâne la soluția actuală.
Cea mai scumpă aplicație nu este întotdeauna cea mai scumpă de întreținut
Poți avea un sistem a cărui întreținere lunară costă relativ puțin.
Și, în același timp, fiecare funcționalitate nouă costă de multe ori mai mult decât ar trebui.
Tocmai de aceea simpla factură pentru hosting, server sau suport nu spune încă cât costă tehnologia.
Costul real al sistemului include și:
- timpul de dezvoltare,
- timpul de testare,
- costul erorilor,
- timpul de implementare,
- costul întreruperilor,
- dificultatea recrutării,
- riscul de securitate,
- costul pierderii cunoștințelor,
- întârzierea noilor funcționalități,
- limitările de business rezultate din tehnologie.
La un moment dat, tehnologia încetează să mai fie un instrument care susține businessul.
Începe să fie o limitare pentru business.
Cum să abordăm decizia?
Înainte să se ia decizia „rescriem de la zero”, merită realizat un audit tehnic.
Ar trebui să includă cel puțin:
Arhitectura - cum este împărțit sistemul și cum comunică elementele sale.
Codul - calitatea, complexitatea, repetitivitatea și zonele deosebit de greu de întreținut.
Dependențele - framework-uri, biblioteci, versiuni și suportul lor.
Securitatea - vulnerabilități, modul de gestionare a accesului și riscurile rezultate din componente învechite.
Testele - gradul de automatizare și posibilitatea de a introduce în siguranță modificări.
CI/CD - modul de construire, testare și implementare a aplicației.
Datele - structura bazei de date, migrațiile, integrările și dependențele.
Monitorizarea - dacă se știe ce se întâmplă cu sistemul după implementare.
Procesul de dezvoltare - cât costă, de fapt, livrarea unei funcționalități noi.
Doar pe baza acestor informații se pot analiza rațional trei scenarii:
- menținem și dezvoltăm,
- modernizăm în etape,
- construim un sistem nou.
Nu există un singur răspuns corect. Există însă o cale corectă de a ajunge la răspuns.
Tehnologia ar trebui să permită dezvoltarea, nu să o blocheze
O arhitectură bună nu înseamnă că sistemul arată modern.
Înseamnă că poate fi schimbat atunci când businessul cere acest lucru.
De aceea merită să privim aplicația nu doar prin prisma faptului dacă funcționează astăzi.
Trebuie, de asemenea, să verificăm, cât va costa adăugarea unor funcții noi peste un an, doi sau cinci ani.
Pentru că un sistem care funcționează, dar împiedică o dezvoltare eficientă, poate fi o problemă mult mai mare decât un sistem care pur și simplu necesită modernizare.
