Reparare sau rescriere: cum decideți pentru o aplicație existentă

Rescrierea este o concluzie, nu un punct de plecare. Cele mai multe sisteme propuse pentru rescriere nu au nevoie de ea. Au nevoie de un responsabil, de un plan de reparare și de câteva luni de muncă răbdătoare. Câteva chiar trebuie rescrise, iar singura cale de a le deosebi este să înțelegeți mai întâi sistemul.

De ce se propune rescrierea

Rescrierea se propune rareori pentru că sistemul nu mai poate fi reparat din punct de vedere tehnic. Se propune pentru că nimeni din echipa actuală nu înțelege sistemul, iar reconstruirea pare singura cale de a recăpăta această înțelegere.

Motivația este sinceră. Este însă și cea mai costisitoare cale spre acest scop. O rescriere recreează cunoașterea recreând aplicația, iar tot ce a învățat sistemul vechi din ani de producție, fiecare caz-limită și fiecare corecție, trebuie învățat din nou.

Al doilea motiv frecvent este frustrarea. Modificările lente, incidentele repetate și o tehnologie necunoscută fac un nou început atrăgător. Frustrarea este reală. Remediul este, de obicei, un responsabil pentru sistem, nu înlocuirea lui.

Ce analizăm înainte să decidem

Nu răspundem la întrebarea „reparăm sau rescriem?” la prima întâlnire. Răspundem după o analiză care acoperă cinci aspecte.

Ce face sistemul. Nu ce spune documentația sau ce își amintește fondatorul. Ce face în producție, pentru ce utilizatori și cât de des. Multe rescrieri sunt dimensionate pe o utilizare imaginară.

Unde este riscul. Ce părți se strică, la ce părți nu se atinge nimeni și care păstrează date ce nu pot fi pierdute. De obicei, riscul este concentrat într-o parte mică a codului.

Dacă poate fi modificat în siguranță. Există o cale de a publica o modificare și de a ști că a funcționat? Există teste, medii de probă, copii de siguranță și posibilitatea de a reveni la versiunea anterioară? Dacă nu, acestea vin primele indiferent de decizia finală, pentru că o rescriere fără ele este o versiune mai mare a aceleiași probleme.

Cât costă menținerea tehnologiei. Framework-urile și mediile de execuție ajung la sfârșitul suportului. Facturile de găzduire cresc. Pentru unele tehnologii este greu de găsit specialiști. Sunt costuri reale, dar pot fi măsurate și sunt adesea mai mici decât costul unei rescrieri.

De ce are nevoie firma în continuare. Un sistem care are nevoie de trei funcționalități mici pe an are cerințe diferite de unul care trebuie să-și dubleze capacitățile. Decizia de rescriere depinde de destinație, nu doar de starea actuală.

Când reparația este răspunsul

Reparația este răspunsul mai des decât se așteaptă echipele. Semnele:

• Modelul de date de bază este solid, chiar dacă codul din jurul lui este încâlcit.
• Problemele sunt concentrate. Două-trei module cauzează cele mai multe incidente.
• Sistemul funcționează în producție cu utilizatori reali, iar comportamentul de care depind aceștia este în mare parte nedocumentat.
• Tehnologia este veche, dar încă susținută, sau poate fi actualizată în pași.

Reparația înseamnă să stabiliți cine răspunde de sistem, să adăugați măsurile de siguranță (teste în jurul părților riscante, monitorizare, publicări fiabile) și apoi să îmbunătățiți sistemul pe loc, o modificare delimitată pe rând. Utilizatorii văd mai întâi stabilitatea și abia apoi îmbunătățirile. Nimic nu se aruncă până când înlocuitorul nu s-a dovedit.

Când rescrierea este răspunsul

Unele sisteme chiar trebuie înlocuite. Semnele sunt precise:

• Platforma nu mai este susținută și nu poate fi actualizată. Un framework fără corecții de securitate este un termen-limită.
• Modelul de date nu mai corespunde cu ceea ce face firma, iar fiecare funcționalitate se lovește de el.
• Sistemul a fost construit pentru un volum de utilizare sau un caz de utilizare care nu mai există, iar cea mai mare parte din el este balast.
• Costul înțelegerii depășește costul specificării, ceea ce se întâmplă cu codul generat sau copiat în mare măsură, fără un design coerent.

Chiar și atunci rescriem pe bucăți, acolo unde se poate. Un sistem nou care preia pe rând câte o responsabilitate de la cel vechi păstrează firma în funcțiune și decizia reversibilă.

O matrice de decizie

Cele cinci arii de analiză de mai sus se reduc la un tabel mic. Evaluați fiecare rând pentru sistemul pe care îl aveți în față; coloana cu cele mai multe bife este recomandarea, iar un singur „înlocuire” pe rândul platformei le anulează pe celelalte.

Întrebare	Indică reparare	Indică modernizare pe loc	Indică rescriere sau înlocuire
Platforma este susținută?	Da, versiuni actuale	Da, dar cu mai mulți pași de actualizare în urmă	Nu, și nu poate fi actualizată
Modelul de date se potrivește cu activitatea firmei?	Da	În mare parte; câteva structuri se opun funcționalităților noi	Nu; fiecare funcționalitate îl ocolește
Există o cale sigură de modificare?	Da	Parțial; există teste și revenire la versiunea anterioară pentru unele părți	Nu, iar adăugarea lor costă mai mult decât valorează părțile respective
Unde este riscul?	Concentrat în două-trei module	Răspândit într-un strat care poate fi înlocuit separat	Peste tot; nu există un design coerent de păstrat
Cât din el mai este folosit?	Cea mai mare parte	Cea mai mare parte, cu cod mort de eliminat	O minoritate; restul servește cazuri care nu mai există
Ce are nevoie firma în continuare?	Funcționalități mici și stabilitate	Funcționalități noi importante, pe aceeași fundație	Un alt produs

Repararea este mentenanță cu un plan. Modernizarea pe loc este serviciul nostru de modernizare. O rescriere se face tot pe bucăți, acolo unde se poate, cu sistemul vechi în funcțiune până când fiecare bucată nouă s-a dovedit.

Poziția noastră

Înțelegeți sistemul, asigurați-vă că poate fi modificat în siguranță, apoi decideți. Echipele care sar direct la rescriere sar peste partea în care învață ce înlocuiesc, iar această cunoaștere este lucrul cel mai costisitor de reconstruit.