Arhitectură 8 min de citit

De ce eșuează rescrierile totale și ce facem în loc

Din nouă proiecte de rescriere totală la care am fost chemați ca ajutor, șapte depășiseră deja bugetul cu peste 60%. Iată tiparul care se repetă și alternativa care funcționează.

Mihai Tudor Principal Engineer ·

Orice inginer care preia un sistem vechi trece prin același gând în prima săptămână: „ar fi mai rapid să rescriem tot de la zero”. Uneori este adevărat. De cele mai multe ori, nu.

Ce se întâmplă de fapt

Sistemul vechi conține zece ani de reguli de business, dintre care jumătate nu sunt documentate nicăieri. Ele au ajuns acolo în urma unor incidente reale, a unor cereri de la un client mare sau a unei modificări legislative uitate între timp.

Când rescrii de la zero, te angajezi implicit să redescoperi toate acele reguli. Iar termenul pe care l-ai promis nu include acest efort, pentru că nu ai cum să estimezi ceva ce nu știi că există.

Un sistem vechi nu este cod prost. Este cod care a supraviețuit realității.

Tiparul care se repetă

  1. Echipa estimează rescrierea la nouă luni.
  2. După șase luni, sistemul nou acoperă 60% din funcționalități, dar nu poate fi lansat pentru că restul de 40% conține exact cazurile care nu suportă întrerupere.
  3. Între timp, sistemul vechi trebuie întreținut în paralel, deci costul se dublează.
  4. La luna 14, cineva propune „o lansare parțială”, adică exact ce ar fi trebuit făcut de la început.

Alternativa: modernizare incrementală

Nu este spectaculoasă și nu arată bine într-o prezentare. Dar funcționează.

  • Pasul unu: centura de siguranță. Teste de caracterizare peste comportamentul actual, oricât de urât ar fi codul. Nu descriu ce *ar trebui* să facă sistemul, ci ce face acum.
  • Pasul doi: pipeline automat. Dacă lansarea durează o zi și necesită trei oameni, nu vei livra incremental, indiferent de intenții.
  • Pasul trei: izolarea unei componente. Alegi o zonă cu graniță clară și o muți în spatele unei interfețe. Sistemul vechi rămâne funcțional.
  • Pasul patru: înlocuirea. Scrii noua implementare, rulezi ambele în paralel și compari rezultatele pe trafic real, înainte de comutare.

Când rescrierea totală chiar este răspunsul

Există și cazuri clare: platforma pe care rulează sistemul nu mai primește actualizări de securitate, limbajul nu mai are furnizori pe piață sau domeniul de business s-a schimbat atât de mult încât regulile vechi sunt oricum irelevante.

În acele situații, rescrierea nu este o alegere estetică, ci una de risc. Diferența este că poți justifica decizia cu argumente, nu cu iritarea provocată de un cod pe care nu îl înțelegi încă.

#legacy#arhitectură#risc
Articole conexe

Ai un sistem de construit sau de salvat?

Programează o discuție de 30 de minute cu un arhitect, nu cu un agent de vânzări. Îți spunem sincer dacă putem ajuta, ce ar dura și cât ar costa.