De ce nu recomandăm rescrierea legacy de la zero

Big Bang — cel mai scump mod de a eșua un proiect

«Hai să rescriem totul de la zero. Cod curat, stack modern, fără mizeria aia veche.»

Sună tentant. Auzim asta de la clienți în mod regulat. De obicei, după ce un developer a spus că «e mai ușor să rescrii decât să înțelegi ce e acolo».

Abordarea Big Bang (rescrierea întregului sistem dintr-o dată) are trei probleme fatale:

1. Business-ul nu poate aștepta

În timp ce tu scrii un sistem nou jumătate de an, business-ul rulează pe cel vechi. Bug-urile nu se repară, funcționalități noi nu se adaugă — «de ce, oricum rescriem». Rezultatul: business-ul încetinește, concurența merge înainte, iar sistemul nou se livrează cu jumătate de an întârziere.

2. Pierzi logica de business

Codul legacy nu e doar «cod prost». Sunt 5-10 ani de reguli de business acumulate, cazuri particulare și nuanțe fiscale. Chiar dacă arată îngrozitor, funcționează corect în 99% din cazuri. Rescriind de la zero, vei reproduce sigur doar 70% din logică. Celelalte 30% vor apărea în producție după lansare.

3. Motivația echipei dispare

Big Bang e un maraton fără linii de sosire intermediare. Primele 3 luni sunt super. Apoi începe «când e gata?». La 6 luni echipa e epuizată. La 12 — jumătate a demisionat.

> Exemplu real: Un proiect de rescriere CRM pentru un distribuitor. Planificat pentru 8 luni. Livrat în 22 de luni. Bugetul s-a triplat. Primele șase luni după lansare s-au petrecut reparând bug-uri din logica de business ratată.

Strangler Fig Pattern — înlocuirea modulară

La AKDEV folosim o abordare numită Strangler Fig (smochinul strangulator). În natură, smochinul crește în jurul unui copac, înfășurându-l treptat până când copacul moare. La fel funcționează și cu sistemele legacy.

Ideea: nu rescrii întregul sistem dintr-o dată. Îl înlocuiești modul cu modul, unul câte unul, până când sistemul vechi nu mai e necesar.

Cum arată în practică

Punem un proxy (API gateway / reverse proxy) în fața sistemului legacy

2. Alegem un modul — cel mai critic sau cel mai simplu

3. Îl rescriem în paralel cu sistemul vechi

4. Redirecționăm traficul către noul modul prin proxy

5. Verificăm că funcționează

6. Repetăm pentru următorul modul

După N iterații, întregul sistem e înlocuit. Zero downtime. Zero tranzacții pierdute.

De ce funcționează

• Business-ul nu se oprește — fiecare modul e înlocuit independent

• Riscuri minime — dacă noul modul nu funcționează corect, proxy-ul redirecționează traficul înapoi la cel vechi

• Echipa vede progres — un rezultat gata la fiecare 2-4 săptămâni

• Buget controlabil — poți opri oricând, sistemul deja funcționează

• Logica de business se păstrează — modulul vechi e documentație vie

Studiu de caz: înlocuire modulară legacy

Unul dintre proiectele noastre — înlocuirea unui sistem contabil vechi care funcționa de peste 5 ani. Zeci de rapoarte, integrare cu instituții de stat, logică de business pe care nimeni n-a documentat-o pentru că «merge așa».

Am împărțit sistemul în 4 module și le-am înlocuit unul câte unul.

• Primul modul l-am făcut repede, dar nu s-a sincronizat înapoi cu sistemul vechi. Departamentul de achiziții a trebuit să lucreze în două sisteme în paralel până când am reparat integrarea.

• Un modul a rămas în versiunea veche mai mult decât era planificat — serviciul extern cu care se integra și-a schimbat API-ul și a trebuit să rescriem de două ori în șase luni.

• După trecerea gestiunii de stoc, soldurile s-au diferențiat în prima săptămână. Sistemul vechi avea un recalcul nocturn al costurilor de care toată lumea uitase.

Sistemul a fost înlocuit în 6 luni. Fără oprire totală a business-ului. Fără pierderi de date. Dar cu compromisuri: un modul a rămas în regim hibrid (vechi + nou), sincronizarea necesită întreținere, iar contabilitatea ne-a înjurat de câteva ori din cauza soldurilor divergente — până când am reparat.

Abordarea modulară n-a făcut proiectul perfect. L-a făcut controlabil. Am putut repara problemele una câte una, în loc să gestionăm haosul unui release unic.

> Concluzia principală: Înlocuirea legacy nu e un sprint — e o serie de compromisuri. Abordarea modulară nu promite că va fi ușor. Promite că va fi controlabil. Pentru un business, asta contează mai mult.

Roadmap pentru înlocuire modulară

Faza 1: Audit (1-2 săptămâni)

• Cartografiem toate modulele sistemului actual

• Identificăm dependențele între module

• Alegem primul candidat pentru înlocuire (independent și fie critic, fie simplu)

• Configurăm stratul de proxy

Faza 2: Primul modul (2-4 săptămâni)

• Construim noul modul cu aceleași contracte API

• Testăm în izolare

• Redirecționăm traficul prin proxy

• Monitorizăm o săptămână

Faza 3: Cascade (2-4 luni, în paralel)

• Înlocuim modulele rămase

• Fiecare modul — ciclu separat: develop → test → switch → monitorizare

Faza 4: Finalizare

• Eliminăm infrastructura legacy

• Documentăm noua arhitectură

• Predăm echipei clientului

Când e justificat Big Bang-ul?

Suntem onești: există situații când Big Bang funcționează mai bine:

Sistemul are sub 20.000 de linii de cod — e mai simplu să rescrii decât să construiești un proxy

2. Nu există un sistem funcțional — de exemplu, documentație de proiect sau un prototip

3. Schimbare completă a proceselor de business — dacă noul produs e atât de diferit încât migrarea incrementală nu are sens

Dar în 90% din cazuri, înlocuirea modulară câștigă.

Concluzie

Rescrierea legacy nu e o problemă tehnică. E o problemă de business. Scopul tău nu e «codul perfect» — e un sistem funcțional cu riscuri minime.

Înlocuirea modulară (Strangler Fig) îți oferă un sistem nou fără downtime, fără pierderi de date și fără epuizarea echipei. E plictisitor, e neeroic, dar funcționează.

La AKDEV am trecut prin asta pe zeci de proiecte. Dacă ai un sistem legacy care «cerșește să fie rescris» — nu te grăbi. Începe cu un audit și un singur modul.