Gównokod în programare: ce este, semne și cum să scrii mai curat

Ce este gównokod în programare

Gównokod — este o caracteristică subiectivă, dar larg acceptată a codului care nu îndeplinește standardele minime de calitate. Robert Martin în cartea „Cod curat” (2008) definește codul prost ca fiind codul care „împiedică înțelegerea a ceea ce face”. Gównokodul poate fi corect sintactic și chiar funcționa, dar întreținerea sa devine un coșmar pentru echipă.

Termenul gównokod este răspândit în special în comunitatea rusofonă. În engleză se folosesc termeni mai formali: spaghetti code, dirty code, technical debt code. Cu toate acestea, coloratura emoțională a „gównokodului” transmite mai exact atitudinea dezvoltatorilor față de un astfel de cod — un amestec de iritare, dezgust și ofensă profesională.

Conform cercetării McKinsey (2023), companiile cu un nivel ridicat de datorie tehnică — iar gównokodul este componenta sa principală — cheltuiesc cu 20–40% mai multe resurse pentru dezvoltarea de noi funcționalități. Calitatea codului influențează direct indicatorii de afaceri, iar aceasta nu este o metaforă, ci un fapt confirmat.

Granita dintre gównokod și codul normal

Nu există metrici obiective, dar există criterii practice: dacă un dezvoltator petrece mai mult de 5 minute pentru a înțelege o funcție de 20 de rânduri — acesta este gównokod. Dacă modificarea unui rând strică trei module neînrudite — acesta este gównokod. Dacă codul nu poate fi acoperit cu teste fără a fi rescris complet — acesta este gównokod.

Principalele semne ale gównokodului

Copy-paste (programare prin copiere) — unul dintre cele mai evidente și ușor de detectat semne. Când același bloc de cod se repetă în mai multe locuri cu modificări minime, aceasta nu este doar gównokod, ci și o sursă de viitoare erori. Corectarea într-un loc și omiterea în altul — o situație tipică.

Nume fără sens ale variabilelor — un clasic. Variabilele cu nume precum `a`, `b`, `x`, `data`, `temp`, `tmp`, `result`, `list`, `obj` nu poartă nicio informație despre scopul lor. Cititorul codului este obligat să analizeze întreaga funcție pentru a înțelege ce este stocat în variabilă. Robert Martin numește aceasta „ minciună în nume” — numele promite informație, dar nu o oferă.

Imbricarea profundă — atunci când condițiile, buclele și gestionarea erorilor creează o construcție cu 5+ niveluri de indentare. Un astfel de cod nu poate fi citit fără derulare laterală sau urmărire mentală a tuturor nivelurilor. Aceasta este o cale directă spre erori: operatorii logici pot fi ușor confundați, iar parantezele de închidere pot fi trecute cu vederea.

Semne ascunse

Dead code — funcții, variabile, clase care nu sunt folosite nicăieri. Aceasta crește volumul codului, distrage atenția dezvoltatorului și creează o impresie falsă despre capacitățile sistemului. Magic numbers — numere fără context. God-clase — clase care fac totul deodată, încălcând principiul responsabilității unice (SOLID: S).

De ce apare gównokodul

Lipsa de timp — cea mai frecventă cauză. Când termenele limită presează, dezvoltatorii sacrifică calitatea în favoarea vitezei. Tactical, acest lucru poate fi justificat, dar strategic — este acumularea de datorie tehnică. Problema este că „temporarul” gównokod rareori este corectat ulterior.

Absența code review — a doua cauză ca importanță. Când codul este scris singur, fără verificare de către colegi, modelele proaste se întăresc și se multiplică. Code review nu este doar control al calității, ci și transmitere de cunoștințe în cadrul echipei. Proiectele fără review alunecă inevitabil spre gównokod.

Calificarea scăzută a dezvoltatorului sau lipsa de mentorat. Dezvoltatorii juniori lăsați fără supraveghere scriu în mod natural gównokod — aceasta face parte din procesul de învățare. Problema apare atunci când acest cod ajunge în producție fără review și refactorizare.

Factori culturali

În echipele unde motto-ul este „funcționează — și e bine”, gównokodul înflorește. Absența standardelor de codare, a cerințelor de testare și a proceselor de review creează un mediu în care calitatea codului nu interesează pe nimeni. Astfel de proiecte devin rapid „legacy” — cod de care le este teamă să se atingă.

Consecințele codului prost pentru proiect

Principala consecință a gównokodului este încetinirea dezvoltării. Paradoxul codului prost este că permite scrierea rapidă a primei versiuni, dar fiecare modificare ulterioară necesită tot mai mult timp. Graficul dependenței vitezei de dezvoltare de calitatea codului este exponențial — după un anumit prag, adăugarea de noi funcționalități devine practic imposibilă.

Fluctuația de personal — o consecință indirectă, dar gravă. Dezvoltatorii, mai ales cei experimentați, nu vor să lucreze cu gównokod. Conform Stack Overflow Developer Survey 2024, 47% dintre dezvoltatori consideră calitatea bazei de cod unul dintre factorii cheie la alegerea locului de muncă. Proiectele cu cod prost pierd cei mai buni angajați.

Securitatea — o altă victimă a gównokodului. Codul prost scris conține mai multe vulnerabilități: excepții netratate, SQL-injection, XSS, scurgeri de memorie. Codul de calitate cu teste unitare și code review detectează majoritatea acestor probleme înainte de producție.

Datoria tehnică ca metrică

SonarQube și instrumente similare pot evalua datoria tehnică în ore-om sau zile. De exemplu, 500 de avertismente despre copy-paste, 200 despre numere magice și 50 despre imbricare profundă oferă o estimare de 30 de zile de datorie tehnică. Aceste cifre pot și trebuie prezentate conducerii pentru a justifica refactorizarea.

Cum să scrii cod curat în loc de gównokod

Principiul DRY (Don't Repeat Yourself) — primul care trebuie implementat. Fiecare fragment de logică trebuie să existe într-un singur exemplar. În loc de copy-paste — extrageți codul repetat într-o funcție, clasă sau modul separat. În loc de numere magice — constante denumite. În loc de funcții lungi — câteva mici.

Principiul KISS (Keep It Simple, Stupid) protejează de complexitatea excesivă. Dacă sarcina poate fi rezolvată în 10 rânduri — nu scrieți 50. Dacă o buclă este mai simplă decât un stream — folosiți bucla. Dacă o funcție obișnuită este mai clară decât un decorator — scrieți funcție. Simplitatea este principala calitate a codului ușor de întreținut.

Principiul Boy Scout Rule — „lăsați codul mai bun decât l-ați găsit”. Chiar și îmbunătățiri mici la fiecare modificare transformă în timp gównokodul într-un cod decent. Redenumirea unei variabile, divizarea unei funcții mari, adăugarea unui test — orice îmbunătățire contează.

// cod prost — copy-paste, numere magice, nume slabe
function calc(a, b, c) {
  let x = a * 0.85;
  if (b > 1000) { x = x * 0.9; }
  let y = c * 0.85;
  if (b > 1000) { y = y * 0.9; }
  return x + y;
}

// cod curat — nume clare, DRY, constante
const DISCOUNT_RATE = 0.85;
const BULK_THRESHOLD = 1000;
const BULK_DISCOUNT = 0.9;

function applyDiscount(amount, quantity) {
  let price = amount * DISCOUNT_RATE;
  if (quantity > BULK_THRESHOLD) {
    price = price * BULK_DISCOUNT;
  }
  return price;
}

function calculateTotal(items, quantity) {
  return items.reduce((sum, item) => {
    return sum + applyDiscount(item, quantity);
  }, 0);
}

Exemple de refactorizare a gównokodului

Să examinăm un exemplu tipic în Python. Funcția procesează comenzile, dar o face prost: 80 de rânduri, imbricare profundă, numere magice, duplicare. După refactorizare, codul devine lizibil, testabil și ușor de întreținut.

# cod prost — o singură funcție face totul
def process_order(order):
    if order.get("type") == "premium":
        if order["amount"] > 100:
            discount = 0.8
        else:
            discount = 0.9
    else:
        discount = 1.0
    total = order["amount"] * discount
    return total

# cod curat — funcții și constante extrase
class OrderProcessor:
    PREMIUM_DISCOUNT_HIGH = 0.8
    PREMIUM_DISCOUNT_LOW = 0.9
    PREMIUM_THRESHOLD = 100

    def get_discount(self, order):
        if order.type == "premium" and order.amount > self.PREMIUM_THRESHOLD:
            return self.PREMIUM_DISCOUNT_HIGH
        return self.PREMIUM_DISCOUNT_LOW

    def calculate_total(self, order):
        return order.amount * self.get_discount(order)

Regula celor trei rânduri pentru funcții

O funcție bună face un singur lucru și îl face bine. Dacă o funcție face trei acțiuni diferite — împărțiți-o. Dacă o funcție conține mai mult de 20 de rânduri — probabil poate fi împărțită. Dacă într-o funcție există mai mult de două niveluri de indentare — este necesară refactorizarea.

Instrumente de detectare a gównokodului

Analizoarele statice de cod — prima linie de apărare împotriva gównokodului. ESLint (JavaScript), Pylint (Python), SonarQube (multilingv), Checkstyle (Java) detectează automat copy-paste, numere magice, blocuri catch goale, funcții prea lungi și sute de alte anti-pattern-uri.

Code style și formatoarele — al doilea nivel de protecție. Prettier, Black, gofmt formatează automat codul, eliminând problemele cu spații, indentări și paranteze. Un stil unitar în echipă face codul lizibil indiferent de cine l-a scris. Disputele privind formatarea trebuie să fie automatizate.

Code review — al treilea și cel mai important nivel. Niciun analizor nu poate înlocui un om care observă că arhitectura soluției este greșită sau că dezvoltatorul a ales o abordare incorectă. Un review eficient necesită timp, dar se amortizează prin reducerea semnificativă a cantității de gównokod.

• ESLint — pentru JavaScript și TypeScript cu regulile complexity, max-lines, max-nested-callbacks
• Pylint — pentru Python cu metrici de cod și evaluare a calității (de la -10 la 10)
• SonarQube — pentru urmărirea datoriei tehnice în dinamică
• CodeClimate — pentru evaluarea indicelui de mentenabilitate al fiecărui fișier
• Better Code Hub — pentru verificarea conformității cu cele 10 principii ale codului curat