Modernizarea software-ului vechi fără o rescriere totală

Aproape orice afacere bine înrădăcinată are unul: un software pe care toți îl detestă în tăcere. Este lent, este urât, jumătate din echipă știe o soluție de avarie pentru bug-ul pe care nu l-a reparat nimeni niciodată, iar singura persoană care îl înțelegea a plecat în 2019. Instinctul este mereu același — să-l ardem din temelii și să construim unul nou. Și acel instinct, cel mai adesea, este exact felul în care companii bune pierd un an și o mică avere degeaba.

Am văzut marea rescriere mergând prost de destule ori încât să am un reflex față de ea. Un fondator îmi arată sistemul lui de comenzi care scârțâie sau străvechiul instrument de programare, oftează și spune o variantă a frazei „pur și simplu trebuie să înlocuim totul.” Și poate că, într-o zi, chiar o veți face. Dar rescrierea completă — smulgi sistemul vechi, construiești unul nou și lucios în paralel, apoi apeși pe buton — este una dintre cele mai riscante mișcări din tot software-ul. Este costisitoare, durează mult mai mult decât s-a promis, iar pe toată durata mergeți orbește, sperând că noul lucru acoperă fiecare caz-limită ciudat pe care vechiul l-a gestionat discret timp de cincisprezece ani.

Vestea bună este că rescrierea totală nu este aproape niciodată singura opțiune și rareori cea mai bună. Există o cale mai liniștită de a moderniza — incrementală, reversibilă și blândă cu afacerea care tot trebuie să facă bani cât timp lucrați. Acesta este un ghid către acea cale: cum recunoașteți ce are nevoie cu adevărat de reparat, cum înlocuiți părțile dureroase fără a opri întregul sistem și cum vă dați seama când o rescriere completă chiar este decizia corectă.

De ce marea rescriere este atât de tentantă — și atât de periculoasă

Rescrierea completă este seducătoare fiindcă promite o foaie albă. Gata cu harababura moștenită, gata cu compromisurile, o bază de cod proaspătă, construită cum trebuie cu unelte moderne. Pe o tablă albă pare evidentă. În realitate, vă angajați să reconstruiți ani de logică de business acumulată — mare parte nedocumentată, o parte trăind doar în mintea unor oameni care au plecat — în timp ce ceasul ticăie și facturile vin.

Capcana mai adâncă este problema universului paralel. Pe parcursul lunilor sau anilor cât durează construirea înlocuitorului, aveți două sisteme: cel vechi, care tot trebuie să țină afacerea în funcțiune, și cel nou, care încă nu este gata. Fiecare schimbare de care are nevoie afacerea trebuie făcută de două ori, altfel noul sistem rămâne în urma realității înainte măcar să fie lansat. Echipele se epuizează ținându-le pe ambele în viață. Și fiindcă nimănui nu i se permite să treacă până când noul sistem nu face totul, nu există nicio victorie timpurie, niciun feedback, nicio dovadă că funcționează — doar o așteptare lungă și anxioasă pentru o singură zi de lansare enormă, totul-sau-nimic.

Există aici un adevăr binecunoscut din folclorul industriei, și este pe merit: al doilea sistem, marea rescriere, are obiceiul de a dura de trei ori mai mult decât s-a estimat și de a ajunge cu mai puține funcții decât lucrul pe care îl înlocuiește. Estimarea nu e greșită fiindcă oamenii sunt neglijenți. E greșită fiindcă nimeni nu poate vedea, la început, toate lucrurile mărunte pe care vechiul sistem le face corect, în tăcere.

Ce înseamnă de fapt „legacy” (nu e despre vârstă)

Aruncăm cuvântul legacy de parcă ar însemna doar vechi. Nu înseamnă. O mulțime de software care rulează de un deceniu este perfect în regulă — plictisitor, stabil, plătit, făcându-și treaba. Vârsta singură nu este un motiv să atingeți ceva. Cea mai costisitoare greșeală din tot acest domeniu este modernizarea a ceva ce funcționa discret, doar fiindcă arăta demodat.

Software-ul își câștigă eticheta de legacy atunci când vă stă activ în cale. Când nu îl puteți schimba în siguranță fiindcă nimeni nu îl înțelege pe deplin. Când nu se poate conecta la uneltele de care depindeți acum. Când o singură persoană este singura care îl poate menține în viață. Când este atât de lent sau de fragil încât echipa a clădit în jurul lui un întreg folclor de soluții de avarie. Aceasta este definiția reală — nu anul în care a fost scris, ci costul pe care vi-l impune astăzi și riscul pe care îl poartă spre mâine.

Diagnosticați înainte să atingeți ceva

Înainte să fie rescrisă o singură linie, aveți nevoie de o hartă sinceră a locului unde trăiește de fapt durerea. De cele mai multe ori, sistemul pe care toți îl urăsc este 80% în regulă. Necazul e concentrat în câteva locuri anume — un ecran lent, o integrare ruptă, un flux de lucru care obligă la introducere dublă a datelor — iar acele câteva locuri generează aproape toate plângerile. Găsiți-le și v-ați găsit întregul proiect.

Modul de a le găsi nu este, mai întâi, un audit tehnic — este o conversație. Stați alături de oamenii care folosesc lucrul în fiecare zi și întrebați-i unde îi doare. Unde așteaptă? Ce retastează? Ce evită fiindcă e dureros? Unde țin o foaie de calcul privată ca să ocolească sistemul oficial? Acele soluții de avarie sunt aur curat: fiecare este o radiografie precisă a unei probleme care merită reparată.

• Ecranele și pașii de care oamenii se plâng cel mai mult — nu în teorie, ci în munca lor zilnică reală.
• Fiecare loc unde datele se introduc de două ori fiindcă două sisteme nu vorbesc între ele.
• Integrările care s-au stricat, sau care n-au existat niciodată, forțând copy-paste manual între unelte.
• Orice știe să opereze sau să repare o singură persoană — punctele voastre unice de eșec.
• Părțile care chiar sunt în regulă, ca să le protejați și să le lăsați așa cum sunt.
• Ce va avea nevoie afacerea anul viitor și în care sistemul actual pur și simplu nu poate crește.

Când faceți asta sincer, proiectul de obicei se micșorează. Proprietarul care a intrat spunând „înlocuiți tot” iese realizând că trebuie să repare trei lucruri. Asta nu e o dezamăgire — e o ușurare. Trei lucruri reparabile sunt un proiect pe care îl puteți încheia în acest trimestru. O înlocuire completă este un an pe care s-ar putea să nu-l supraviețuiți.

Abordarea strangulatoare: înlocuiți-l bucată cu bucată

Există un tipar pentru a face asta în siguranță, și are un nume ușor sumbru, dar memorabil: abordarea strangulatoare, după smochinul strangulator — o liană care crește în jurul unui copac, preluându-i treptat structura până când, în cele din urmă, noua creștere stă pe picioarele ei și trunchiul vechi dispare. Aplicată software-ului, ideea este minunat de practică: nu înlocuiți sistemul vechi printr-o singură schimbare eroică. Îl creșteți pe cel nou în jurul lui, bucată cu bucată, până când nu mai rămâne nimic din cel vechi de care să aibă cineva nevoie.

În practică funcționează așa. Alegeți o singură bucată dureroasă — să zicem, modulul de facturare pe care toți îl urăsc. Construiți un înlocuitor modern doar pentru acea bucată. Direcționați facturarea către noul modul, în timp ce tot restul rulează mai departe pe sistemul vechi, neatins. Îl urmăriți o vreme. Când e solid, acea parte a sistemului vechi amuțește, iar voi treceți la bucata următoare. Sistemul vechi se micșorează treptat, ca o lumânare, în loc să fie doborât dintr-o dată.

Ceea ce face acest lucru mult mai sigur decât o rescriere este faptul că fiecare pas este mic, viu și reversibil. Nu mergeți niciodată orbește. Fiecare bucată nouă intră repede în uz real, așa că aflați rapid dacă funcționează cu adevărat. Dacă ceva merge prost, ați riscat doar un modul, nu întreaga afacere — și de obicei puteți reveni la calea veche cât timp îl reparați. Obțineți victorii pe parcurs, în loc de o singură lansare terifiantă la final. Iar afacerea continuă să funcționeze, normal, tot timpul.

Cum arată de fapt ritmul

1. 1
   Alegeți bucata cea mai dureroasă și cea mai de sine stătătoare

   Vreți durere mare și margini curate — un modul care doare mult și care nu-și are degetele în tot restul. Acela este prima voastră țintă.
2. 2
   Puneți un strat subțire în fața sistemului vechi

   Un mic strat de rutare decide ce cereri merg la sistemul vechi și ce cereri merg la bucata nouă. Aceasta este îmbinarea care face posibil tot restul.
3. 3
   Construiți și lansați doar acea singură bucată

   Înlocuiți un modul, puneți-l în mâini reale și direcționați spre el doar acea felie de muncă. Săptămâni, nu ani — iar restul sistemului nu s-a clintit.
4. 4
   Stabilizați, apoi treceți la bucata următoare

   Odată ce noul modul e de încredere, partea corespunzătoare din sistemul vechi adoarme. Repetați cu bucata dureroasă următoare, învățând pe parcurs.
5. 5
   Scoateți din uz sistemul vechi când e gol

   În cele din urmă, sistemul legacy nu mai face nimic pe care să se bazeze cineva. Abia atunci îl opriți — discret, fără dramă, fiindcă tot ce era important s-a mutat deja.

Observați ce e diferit față de rescriere: nu există o singură zi de lansare de temut. Nu există un univers paralel de întreținut. Noul sistem este în producție din a treia săptămână, își câștigă pâinea și vă învață lucruri, în loc să aștepte într-un laborator o lansare care tot alunecă.

Uneori nici măcar nu trebuie să-l înlocuiți

Înainte să înlocuiți orice, merită să vă întrebați dacă sistemul vechi are nevoie de înlocuire sau doar trebuie să înceteze să fie o insulă. Un număr surprinzător de probleme de tip „ne trebuie un sistem nou” sunt de fapt probleme de tip „sistemele noastre nu vorbesc între ele”. Software-ul vechi e bun la treaba lui — doar că stă într-un siloz, obligând oamenii să care datele înăuntru și afară de mână.

În acele cazuri, soluția cea mai ieftină și mai rapidă nu este un sistem nou. Este o punte. Înfășurați software-ul vechi cu o conexiune — o integrare care îi permite să schimbe date automat cu celelalte unelte — și un strat modern deasupra pentru părțile pe care oamenii chiar le ating. Motorul demodat continuă să toarcă dedesubt; echipa primește o suprafață curată și sfârșitul lui copy-paste. Nu e spectaculos, dar e adesea cel mai mare randament per euro din tot efortul.

Când o rescriere completă chiar este decizia corectă

Am petrecut tot acest ghid convingându-vă să renunțați la marea rescriere, așa că, să fiu corect: uneori chiar este răspunsul. Există fundații atât de putrede încât niciun fel de petice, punți sau înlocuiri bucată cu bucată nu le va salva, iar a pretinde altceva doar amână inevitabilul cât timp cheltuiți bani sprijinind un cadavru.

Semnele sincere sunt precise. Tehnologia pe care este construit sistemul este moartă sau pe moarte — fără suport, fără actualizări de securitate, fără nimeni rămas care să poată lucra la ea. Afacerea s-a schimbat atât de fundamental încât modelul vechi nu mai corespunde deloc realității. Sau sistemul este atât de încâlcit încât chiar și schimbări mici strică în mod regulat lucruri în locuri fără legătură, ceea ce de obicei înseamnă că nu există îmbinări curate în care să faceți, în primul rând, o abordare strangulatoare. Când două sau trei dintre acestea sunt adevărate simultan, munca incrementală încetează să mai fie alegerea mai sigură.

Și iată răsplata discretă a faptului că faceți întâi munca incrementală, chiar dacă până la urmă reconstruiți: când ajungeți acolo, veți înțelege sistemul mult mai bine decât la început. Fiecare modul pe care l-ați înlocuit v-a învățat ceva ce autorii originali n-au scris niciodată. O rescriere informată de acea cunoaștere este un animal complet diferit, mult mai sigur, decât cel lansat pe optimismul primei zile.

Partea pe care n-o pomenește nimeni: e mai ales despre oameni

Iată ceva ce ghidurile tehnice sar. Cea mai grea parte a modernizării software-ului vechi nu este de obicei codul — ci oamenii care și-au petrecut ani adaptându-se la el. Îi cunosc ciudățeniile. Au memorie musculară pentru scurtăturile lui bizare. Un modul nou, obiectiv mai bun, poate părea totuși mai prost în primele două săptămâni, pur și simplu fiindcă este nefamiliar. Dacă ignorați asta, chiar și o migrare tehnică perfectă poate eșua.

Abordarea incrementală ajută și aici, aproape din întâmplare. Fiindcă schimbarea sosește câte o bucățică mică pe rând, oamenii o absorb treptat în loc să li se ceară să reînvețe totul într-o singură luni dimineața. Aduceți devreme utilizatorii zilnici. Lăsați-i să modeleze înlocuitorul înainte să fie gata. Echipa care a ajutat la proiectarea noului ecran de facturare îl va susține; echipa peste care a fost aruncat îl va detesta, chiar dacă e identic. Modernizarea este un proiect de management al schimbării deghizat în software.

Întrebări frecvente