Se întâmplă mai des decât ar trebui: freelancerul nu mai răspunde la telefon, firma care a făcut aplicația s-a închis sau angajatul care știa totul a plecat. Site-ul sau aplicația funcționează, deocamdată. Dar nimeni nu mai știe cum e construită, unde rulează sau ce se întâmplă dacă o atingi.

Vestea bună: aproape orice proiect abandonat poate fi preluat. Important e să faci pașii în ordinea corectă, iar primul nu are legătură cu codul.

Primul pas: recuperează accesul

Înainte de orice modificare, află ce ai și cine controlează fiecare piesă. De multe ori, conturile sunt pe numele dezvoltatorului, iar asta devine problema principală.

Ce Ce verifici De ce contează
Domeniul la ce registrar e, pe numele cui, când expiră dacă expiră, site-ul și emailul dispar
Găzduirea, serverul cine are acces, cine plătește fără acces, nu poți face nimic
Codul sursă unde e (un depozit Git, o arhivă, doar pe server) fără cod, orice modificare devine o reconstrucție
Baza de date unde e, dacă există copii de siguranță datele sunt adesea cel mai valoros lucru
Conturile de administrare cine le are, dacă poți reseta parolele ca să poți lucra, nu doar privi
Serviciile externe plăți, email, hărți, SMS, facturare: conturi și chei de acces o cheie expirată poate opri plățile sau emailurile
DNS și certificatul SSL cine le administrează, când se reînnoiesc un certificat expirat sperie clienții
Conturile din magazinele de aplicații pe numele cui sunt aplicațiile din App Store și Google Play fără ele, nu mai poți publica actualizări

Nu lăsa domeniul să expire

Dintre toate, domeniul e cel mai urgent. Dacă expiră și nu e reînnoit, cineva îl poate înregistra în locul tău. Află cât mai repede pe numele cui e și când expiră.

Cum evaluăm codul

După ce avem acces, facem o evaluare tehnică. Nu ca să criticăm munca altcuiva, ci ca să știm pe ce călcăm.

  1. Facem o copie completă. Codul, baza de date, fișierele încărcate, configurările. Nimic nu se modifică înainte să existe o copie din care putem reveni.
  2. Pornim proiectul pe un mediu separat. Dacă îl putem rula și pe alt server decât cel de producție, înțelegem ce îi trebuie ca să funcționeze și putem testa fără riscuri.
  3. Verificăm versiunile. Multe proiecte abandonate rulează pe versiuni care nu mai primesc actualizări de securitate. La PHP, de exemplu, versiunea minimă pe care o considerăm sigură azi este 8.3; un proiect pe o versiune mai veche trebuie actualizat1.
  4. Verificăm dependențele. Bibliotecile, modulele și temele folosite, cu vulnerabilitățile lor cunoscute.
  5. Citim codul și arhitectura. Cât de clar e organizat, cât e scris de mână și cât vine dintr-o platformă, unde sunt părțile fragile, dacă există teste și documentație.
  6. Scriem un raport. Ce am găsit, ce riscuri sunt, ce e urgent, ce poate aștepta și cât costă fiecare variantă.

Repari, refactorizezi sau rescrii?

Prima tentație, după ce vezi un cod dezordonat, e să-l arunci și să o iei de la capăt. Adesea e o greșeală. Joel Spolsky a numit rescrierea de la zero „cea mai proastă greșeală strategică” pe care o poate face o firmă de software, cu exemplul Netscape, care a pierdut ani întregi rescriindu-și browserul2. Codul vechi, oricât de urât, conține ani de corecturi și de cazuri speciale pe care nimeni nu le mai ține minte.

Pe de altă parte, uneori fundația chiar nu mai poate fi salvată: tehnologie abandonată, securitate imposibil de reparat sau o arhitectură care nu poate susține ce îți trebuie. Am scris despre asta și în articolul despre aplicațiile făcute prin vibe coding.

Situația Ce recomandăm de obicei
Codul e rezonabil, doar neîntreținut reparăm: actualizări, securitate, copii de siguranță, documentație
Codul merge, dar e greu de modificat refactorizăm: îl reorganizăm pe bucăți, fără să schimbăm ce face
Tehnologia e depășită sau fundația e greșită înlocuim treptat: părțile noi se construiesc alături, iar cele vechi se scot pe rând
Proiectul e mic sau aproape nefuncțional rescriem: mai ieftin decât să reparăm

Varianta din penultimul rând are și un nume: Martin Fowler o numește „strangler fig”, după smochinul care crește în jurul unui copac și îl înlocuiește treptat3. Aplicația continuă să funcționeze tot timpul, iar riscul e împărțit în pași mici.

Ce urmează după preluare

  1. Stabilizăm. Copii de siguranță automate, actualizări de securitate, monitorizare. Proiectul nu mai e în pericol.
  2. Documentăm. Cum se instalează, cum se publică o versiune nouă, unde sunt conturile și cheile. Ca să nu mai depinzi de memoria unui singur om.
  3. Dezvoltăm mai departe. Abia acum adăugăm funcții noi, pe o bază pe care o înțelegem.

Cum te protejezi data viitoare

  • domeniul, găzduirea și conturile serviciilor externe pe numele firmei tale;
  • acces la depozitul de cod, nu doar la server;
  • documentație tehnică predată odată cu proiectul;
  • un contract care spune clar ale cui sunt codul și datele.

Ai un proiect rămas fără dezvoltator? Facem întâi evaluarea, ca să știi exact ce ai, ce riscuri sunt și ce variante există, înainte să decizi ceva.

Cere o evaluare a proiectului

  1. PHP, Supported Versions. ↩

  2. Joel Spolsky, Things You Should Never Do, Part I, 2000. ↩

  3. Martin Fowler, Strangler Fig Application. ↩

Imaginea de copertă: I Am Svoboda, Wikimedia Commons (CC0)