Ce este codul spaghete

Codul spaghete (spaghetti code) — este o metaforă pentru descrierea codului a cărui structură seamănă cu un farfurie de spaghete: firele individuale (blocurile logice) sunt încâlcite, lipite și inseparabile una de alta. În astfel de cod, nu se pot distinge straturi, module sau componente — totul este amestecat într-o singură masă mare.

Spre deosebire de codul prost, care poate fi doar neglijent, codul spaghete este o problemă arhitecturală fundamentală. Chiar și un cod perfect formatat cu nume bune de variabile poate fi cod spaghete dacă arhitectura sa este haotică. Problema se află la nivelul structurii programului, nu al stilului de scriere.

Conform datelor IEEE (2022), aproximativ 35% din toate erorile din proiectele mari sunt cauzate tocmai de structura încâlcită a codului, nu de greșelile logice ale dezvoltatorului. Dezvoltatorul greșește nu pentru că a înțeles greșit sarcina, ci pentru că nu a putut urmări fluxul de execuție în codul spaghete.

Diferența cheie față de alte anti-pattern-uri

Dacă codul prost este cod prost la scara unei singure funcții sau fișier, atunci codul spaghete este o arhitectură proastă la scara întregii aplicații. Tăiețeii pot consta din funcții individuale bine scrise, dar interacțiunea lor este haotică și imprevizibilă.

Istoria termenului și era goto

Termenul „spaghetti code“ a apărut în anii 1970 odată cu critica operatorului goto. În limbajele de programare timpurii (BASIC, FORTRAN, COBOL), goto era principala modalitate de control al fluxului de execuție. Programul reprezenta o secvență de linii numerotate, iar goto permitea saltul la oricare dintre ele. Aceasta crea un „ghem“ de salturi care nu putea fi descurcat.

În 1968, Edsger Dijkstra a publicat celebra scrisoare „Go To Statement Considered Harmful“, care a marcat începutul erei programării structurate. Dijkstra a demonstrat că orice algoritm poate fi implementat fără goto, folosind doar trei construcții: secvență, ramificare (if) și buclă (while). Aceasta a devenit fundamentul programării moderne.

Programarea structurată nu a eliminat complet problema. Codul spaghete a trecut la un nou nivel — în loc de goto fizice, dezvoltatorii au început să creeze „goto“ logice: variabile globale, callback hell în JavaScript, lanțuri complexe de apeluri și dependențe implicite între componente. Problema a rămas, doar forma s-a schimbat.

Forme moderne ale goto

Callback hell în JavaScript, Promise-uri profund imbricate, async/await fără gestionarea erorilor, evenimente care nu se știe cine și când le declanșează — toate acestea sunt variante moderne ale codului spaghete. Anti-pattern-ul trăiește și înflorește, doar că acum nu mai folosește operatorul goto.

Semne ale codului spaghete în proiect

Lipsa straturilor — primul și principalul semn. În codul spaghete, logica de afaceri, lucrul cu baza de date, șablonul HTML și comunicarea în rețea sunt amestecate într-un singur fișier sau chiar într-o singură metodă. Modificarea unei interogări la bază de date poate strica afișarea UI-ului, deoarece codul acestor straturi nu este separat.

Variabilele globale și singleton-urile — al doilea semn evident. Când starea aplicației este stocată în obiecte globale, fluxul de execuție devine imprevizibil. Orice funcție poate modifica starea globală, iar urmărirea unde și când s-a întâmplat este practic imposibilă.

Clasele zeu (God-classes) și funcțiile zeu — al treilea semn. O clasă de 2000+ de linii care răspunde atât de logica de afaceri, cât și de afișare și de lucrul cu datele — este un cod spaghete tipic. O funcție care primește 10 parametri și face 5 lucruri diferite — de asemenea.

Diagnosticare prin teste

Dacă nu poți scrie un test unitar pentru o funcție fără a crea 15 obiecte mock — acesta este cod spaghete. Dacă testarea unui modul necesită pornirea întregii infrastructuri a aplicației — acesta este cod spaghete. Netestabilitatea — un indicator obiectiv al arhitecturii încâlcite.

De ce apare codul spaghete

Lipsa proiectării arhitecturale — cea mai frecventă cauză. Când echipa începe să scrie cod fără un plan, alegând arhitectura „pe parcurs“, rezultatul se transformă inevitabil în spaghete. Fiecare funcție nouă este adăugată acolo unde „este convenabil acum“, nu acolo unde îi este locul conform logicii.

Dezvoltarea evolutivă — a doua cauză. Proiectul începe ca un script mic, apoi se umple de funcții, apoi devine o aplicație, iar apoi — un monolit. Între timp, arhitectura nu este revizuită. Ceea ce funcționa pentru 100 de linii de cod devine un dezastru pentru 100 000 de linii.

Încălcarea principiilor SOLID — a treia cauză. În special a principiului responsabilității unice (S) și al inversiunii dependențelor (D). Când o clasă răspunde de tot, dependențele sunt rigide, iar modulele sunt legate strâns — rezultă cod spaghete.

Factorul timp

Termenele limită și cultura hotfix — catalizatori ai codului spaghete. Când „trebuia ieri“, dezvoltatorii inserează codul în primul loc disponibil, fără să se gândească la arhitectură. Zece astfel de hotfix-uri — și arhitectura aplicației este distrusă.

Consecințele codului spaghete

Principala consecință — pierderea controlului asupra bazei de cod. Dezvoltatorii încetează să înțeleagă cum funcționează aplicația în ansamblu. O modificare într-un loc strică alt loc, aparent fără legătură. Fiecare patch creează două bug-uri noi. Echipa intră într-o stare de „teamă de schimbări“.

Productivitatea echipei scade exponențial. Cercetarea Microsoft Research (2023) a arătat că timpul de adăugare a unei noi funcții în codul spaghete crește conform legii pătratice în raport cu dimensiunea bazei de cod. Pentru o arhitectură curată, această creștere este liniară. Diferența devine critică la 50 000+ linii de cod.

Securitatea — o altă victimă. În codul spaghete, este ușor să treci cu vederea o excepție netratată, o validare incorectă a intrărilor sau o scurgere de date. Auditul de securitate într-un proiect cu arhitectură încâlcită este practic imposibil — găsirea tuturor locurilor unde se utilizează datele de intrare ale utilizatorului este nerealistă.

Impactul asupra echipei

Fluctuația în proiectele cu cod spaghete este mai mare decât media. Dezvoltatorii experimentați pleacă pentru că nu vor să lucreze cu „tăieței“. Angajații noi nu pot înțelege codul și pleacă în primele luni. Proiectul pierde expertiza, ceea ce înrăutățește și mai mult calitatea codului — un cerc vicios.

Cum să refactorizezi codul spaghete

Primul — începe cu separarea straturilor. Împarte codul în trei niveluri: presentation (UI, controllere), business logic (servicii, use cases) și data access (repositorii, DAO). Chiar și o separare parțială îmbunătățește imediat structura și face codul testabil.

Al doilea — implementează dependency injection. Înlocuiește crearea directă a dependențelor cu transmiterea prin constructor sau parametri. Aceasta rupe legăturile rigide între componente și permite testarea fiecărui modul în mod izolat.

Al treilea — extrage clasele zeu și funcțiile zeu. Împarte-le în clase și metode mici cu o singură responsabilitate. Folosește pattern-ul Facade pentru simplificarea subsistemelor complexe. Amintește-ți: o clasă de 20 de linii este mai ușor de înțeles decât una de 2000 de linii.

// spaghetti — totul într-o singură metodă
function handleRequest(req, res) {
  const db = new Database("mysql://...");
  const user = db.query("SELECT * FROM users WHERE id =" + req.params.id);
  let html = "";
  html += "
" + user.name + "
";
  html += "
Balance: " + user.balance + "
";
  html += "";
  res.send(html);
}

// arhitectură curată — straturi separate
class UserController {
  constructor(userService) {
    this.userService = userService;
  }

  async getUser(req, res) {
    const user = await this.userService.findById(req.params.id);
    res.json(new UserResponse(user));
  }
}

class UserService {
  constructor(userRepository) {
    this.userRepository = userRepository;
  }

  async findById(id) {
    return await this.userRepository.findById(id);
  }
}

Strategia de refactorizare: metoda chirurgiei

Nu încerca să rescrii întreaga bază de cod dintr-o dată — acesta este un eșec garantat. Alege un modul, scrie pentru el teste (characterization tests) care fixează comportamentul curent și abia apoi refactorizează. Treptat, modul cu modul, vei descurca spaghetele.

Prevenirea apariției codului spaghete

Planificarea arhitecturală — baza prevenirii. Înainte de începerea dezvoltării, aprobă stilul arhitectural: MVC, MVVM, Clean Architecture, VIPER sau altul. Scrie un ADR (Architecture Decision Record) cu justificarea alegerii. Cere respectarea arhitecturii la code review.

Principiul inversiunii dependențelor (DIP) — un instrument puternic în lupta cu codul spaghete. Modulele de nivel înalt nu trebuie să depindă de modulele de nivel scăzut. Ambele trebuie să depindă de abstractizări. Dependency Injection — implementarea practică a acestui principiu.

Testarea — cea mai bună prevenire. Dacă scrii teste înaintea codului (TDD), proiectezi inevitabil componente slab cuplate. Codul testabil — este cod bine structurat. Codul netestabil — este aproape întotdeauna cod spaghete.

• Arhitectura înaintea codului: aprobă schemele straturilor și dependențelor
• Dependency Injection ca pattern principal de cuplare
• TDD sau cel puțin o acoperire ridicată cu teste
• Code review cu verificarea arhitecturii, nu doar a stilului
• Refactorizare regulată ca parte a procesului de dezvoltare

Instrumente pentru combaterea codului spaghete

SonarQube — urmărește complexitatea ciclomatică, adâncimea moștenirii, dimensiunea metodelor. JDepend (Java) — măsoară dependențele între pachete. PhpMetrics — oferă indicele de mentenanță pentru proiecte PHP. Urmărește metricile în CI/CD — previne apariția codului spaghete, nu lupta cu el post-factum.