Cod-mizerie și dezordine în proiecte mobile — semne și refactorizare

Ce este codul-mizerie în dezvoltare

Codul-mizerie (de asemenea spaghetti code, dezordine, big ball of mud) — este o metaforă pentru o bază de cod care și-a pierdut structura și s-a transformat într-un ghem încâlcit de dependențe. Într-un astfel de cod, orice modificare într-un loc strică altceva, iar adăugarea de noi funcționalități devine o sarcină riscantă.

În dezvoltarea mobilă codul-mizerie este deosebit de critic: o aplicație construită pe „mizerie" începe să încetinească, să se blocheze pe dispozitive vechi și trece cu greu de code review. Un proiect iOS fără arhitectură poate să nu treacă de App Review din cauza instabilității.

Conform datelor Stripe, dezvoltatorii petrec până la 42% din timpul de lucru citind și înțelegând codul existent. În proiectele cu cod-mizerie, acest indicator depășește 60%, ceea ce face dezvoltarea extrem de ineficientă.

Originea termenilor

Spaghetti code (cod spaghete) — cel mai vechi termen, apărut în anii 1970. El descrie un cod cu salturi de control haotice, care amintește de paste încâlcite.

Big ball of mud (bilă mare de noroi) — termen introdus de Brian Foot și Joseph Yoder în 1997 pentru a descrie sisteme fără o arhitectură clară, care „cresc" haotic.

De ce codul-mizerie este periculos pentru afaceri

Codul-mizerie încetinește lansarea de noi funcții pe piață. Echipa pierde timp nu pentru a crea valoare, ci pentru a încerca să înțeleagă cum funcționează codul existent și să nu strice nimic.

Conform datelor McKinsey, companiile cu calitate scăzută a codului cheltuiesc cu 20-40% mai mult pentru întreținerea produsului, iar viteza de lansare a noilor funcții este de 2-3 ori mai mică comparativ cu companiile cu calitate înaltă a codului.

Semnele codului-mizerie și cum să-l recunoști

Recunoașterea codului-mizerie se poate face printr-un set de semne obiective, dintre care unele se măsoară automat. Cu cât mai multe semne se potrivesc — cu atât problema este mai gravă.

În industrie se folosesc metrici de calitate a codului precum Halstead Complexity, Maintainability Index și Technical Debt Ratio. Cunoașterea acestor metrici ajută la evaluarea obiectivă a stării bazei de cod.

Copy-paste (duplicarea codului)

Cel mai frecvent semn al codului-mizerie — blocuri de cod repetate. În loc să extragă o funcție comună, dezvoltatorii copiază codul dintr-un loc în altul cu modificări minime.

Un nivel normal de duplicare este considerat până la 5%. Dacă duplicarea depășește 15% — acesta este un semnal serios. Instrumente precum Simian și PMD Copy Paste Detector ajută la detectarea automată a copy-paste-ului.

Metode și clase lungi

O metodă mai lungă de 100 de linii — un semn evident al codului-mizerie. O astfel de metodă face de obicei prea multe și încalcă principiul responsabilității unice (Single Responsibility).

Clasele cu peste 1000 de linii de cod sunt de asemenea problematice. Ele conțin funcționalități nelegate, ceea ce îngreunează testarea, înțelegerea și modificarea codului.

Complexitate ciclomatică ridicată

Complexitatea ciclomatică după McCabe (Cyclomatic Complexity) — o metrică care arată numărul de căi independente în cod. O valoare peste 15 este considerată problematică.

Metodele cu complexitate peste 30 — „zona dezastrului". Ele conțin prea multe ramificări, nu pot fi testate sau înțelese fără o analiză profundă.

Cauzele apariției codului-mizerie

Codul-mizerie nu apare „de la sine" — este întotdeauna rezultatul unor procese și decizii specifice în echipă. Înțelegerea cauzelor permite prevenirea apariției lui în viitor.

Conform datelor JetBrains Developer Ecosystem 2024, 67% dintre dezvoltatori recunosc că scriu cod mai prost decât ar putea din cauza lipsei de timp. Aceasta este principala cauză a acumulării datoriei tehnice.

Graba și termenele limită

Cea mai frecventă cauză — termene strânse. Echipa scrie codul „cum iese", doar ca să ajungă la termen. Refactorizarea, testele și code review-ul sunt amânate „pentru mai târziu".

Problema este că „mai târziu" nu vine niciodată — în următorul sprint apar noi termene limită, iar datoria tehnică se acumulează ca un bulgăre de zăpadă.

Lipsa code review-ului

Fără code review, fiecare dezvoltator scrie în propriul stil, folosește propriile pattern-uri și își lasă propriile „capcane". În timp, baza de cod își pierde uniformitatea.

Echipele care practică code review obligatoriu pentru fiecare pull request au cu 60% mai puține defecte în producție, conform cercetării SmartBear 2024.

Arhitectură slabă de la început

Dacă proiectul începe fără o arhitectură clară, codul-mizerie este inevitabil. Primele „soluții rapide" pun o fundație pe care ulterior este greu să construiești ceva de calitate.

În dezvoltarea mobilă, alegerea arhitecturii (MVC, MVP, MVVM, Clean Architecture) ar trebui să fie o decizie conștientă luată înainte de începerea scrierii codului, nu un rezultat al evoluției.

Metode de combatere a codului-mizerie

Combaterea codului-mizerie necesită o abordare sistematică și disciplină din partea întregii echipe. Nu există un singur instrument sau practică care să rezolve problema — este nevoie de un set de măsuri.

Principalul principiu — să nu permiți codul-mizerie în faza de scriere, nu să îl repari ulterior. Prevenția este întotdeauna mai ieftină decât refactorizarea „mizeriei" existente.

Standarde de codare

Un stil unitar de cod — baza pentru prevenirea codului-mizerie. Standardele de codare (Code Style) trebuie documentate și verificate automat de lintere.

Pentru iOS se folosește SwiftLint, pentru Android — Ktlint și Detekt. Configurarea regulilor într-un fișier de configurare permite respingerea automată a pull request-urilor care încalcă standardele.

Refactorizare regulată

Refactorizarea — nu înseamnă repararea bug-urilor, ci îmbunătățirea structurii codului fără a-i schimba comportamentul. Ar trebui să fie o parte regulată a procesului de dezvoltare, nu un proiect separat.

Se recomandă alocarea a 20% din timpul fiecărui sprint pentru refactorizare și plata datoriei tehnice. Aceasta previne acumularea „mizeriei" și menține viteza echipei pe termen lung.

Code review obligatoriu

Fiecare pull request trebuie să treacă prin review de la cel puțin un dezvoltator. Code review-ul detectează nu doar bug-uri, ci și încălcări ale arhitecturii, stilului și surse potențiale de cod-mizerie.

O practică bună — o listă de verificare pentru code review care include verificarea copy-paste-ului, lungimii metodelor, complexității ciclomatice și acoperirii cu teste. Fără listă de verificare, reviewerii omit până la 50% din probleme.

Instrumente pentru curățarea bazei de cod

Instrumentele moderne de analiză a codului permit detectarea automată a codului-mizerie, măsurarea datoriei tehnice și controlul calității. Integrarea acestor instrumente în pipeline-ul CI/CD asigură o monitorizare continuă.

Se recomandă utilizarea a cel puțin un analizor static și un instrument de măsurare a metricilor. Suplimentar, se poate conecta o platformă pentru agregarea datelor despre calitatea codului.

Analizoare statice

• SonarQube — platforma lider de analiză a calității codului, suportă 30+ limbaje și oferă metrici Technical Debt Ratio
• ESLint — standardul pentru JavaScript și TypeScript, configurat prin fișiere de configurare și integrat în IDE
• SwiftLint — instrument obligatoriu pentru proiecte iOS, verifică conformitatea cu Swift Style Guide

Conform datelor SonarSource, echipele care utilizează analiza statică reduc numărul de bug-uri în producție cu 30% deja în primul trimestru după implementare.

Instrumente de măsurare a metricilor

CodeClimate și Codacy — platforme care agregă metrici de calitate a codului, urmăresc dinamica și arată „punctele fierbinți" — fișierele cu cea mai mare datorie tehnică.

Pentru proiectele Android, Detekt oferă peste 100 de reguli de analiză încorporate, inclusiv verificări de complexitate ciclomatică, lungime a metodelor și duplicare a codului.