Jank în dezvoltare — ce este, de ce junk-code dăunează și cum să îl eliminați

Ce este jank?

Jank (junk code) — un termen colectiv pentru codul, configurațiile și dependențele care există în proiect dar nu au valoare funcțională. Jank nu este neapărat stricat sau neutilizat — problema este că prezența lui înrăutățește metricile proiectului fără o justificare adecvată.

Jank se împarte în patru categorii. Prima — dependențe redundante: biblioteci atașate pentru o singură funcție care poate fi implementată cu mijloace standard. A doua — greutate moartă: blocuri comentate, TODO-uri fără tichete, metode goale și clase stub. A treia — soluții duplicate: două biblioteci care fac același lucru (de exemplu, Gson și Kotlin Serialization în același proiect). A patra — over-engineering: straturi arhitecturale care nu sunt utilizate, dar sunt menținute „pentru viitor”.

Conform cercetării Stripe Engineering Productivity (2025), eliminarea a 10 procente de jank dintr-un proiect tipic reduce timpul de compilare completă cu 22 de procente în medie. Motivul: fiecare dependență suplimentară mărește graful de compilare, fiecare abstracție goală necesită timp de înțelegere, fiecare bloc comentat distrage atenția.

Principala dificultate în lupta cu jank-ul este lipsa consecințelor imediate. Proiectul cu junk-code se compilează și funcționează. Problemele se acumulează treptat: compilarea încetinește, numărul dependențelor tranzitive crește, iar după un an adăugarea unei noi funcții durează de două ori mai mult decât ar trebui.

Dependențele junk și cum să le identificați

Dependențele junk — sunt bibliotecile și pachetele care sunt conectate la proiect dar nu sunt utilizate direct în cod, sau sunt utilizate doar într-o singură funcție care poate fi implementată mai simplu cu API-uri standard.

Exemple tipice: o bibliotecă pentru lucrul cu JSON când proiectul folosește deja Kotlin Serialization (doi parseri — acesta este jank); biblioteca Apache Commons Lang pentru o singură metodă StringUtils.isEmpty, care poate fi înlocuită cu extensia Kotlin isNullOrBlank; o bibliotecă de DI utilizată într-un singur modul din zece, iar restul primesc dependențe manual prin constructor.

Fiecare dependență suplimentară nu este doar cod în plus în binar. Este și creșterea suprafeței de atac pentru vulnerabilități: conform GitHub Advisory Database (2025), 40 de procente din CVE-urile critice în proiectele mobile revin dependențelor tranzitive pe care dezvoltatorii nu le controlează. Cu cât mai puține dependențe — cu atât mai mică suprafața de atac.

Analiza dependențelor unui proiect Android

// Vizualizați arborele dependențelor Gradle
./gradlew app:dependencies --configuration releaseRuntimeClasspath

// Găsiți dependențe neutilizate (plugin Gradle)
plugins {
    id "com.autonomousapps.dependency-analysis" version "2.0.0"
}

// Generați raportul bibliotecilor neutilizate
./gradlew buildHealth

Pentru iOS utilizați comanda swift package show-dependencies, care afișează arborele complet al dependențelor. Instrumentul Xcode Build Timeline arată cât timp adaugă fiecare bibliotecă la compilare. Dacă o bibliotecă ocupă 30 de procente din timpul de compilare dar este utilizată într-un singur ecran — este un candidat pentru eliminare sau înlocuire.

Pentru Node.js (React Native) utilizați depcheck — o utilitate care găsește dependențe neutilizate în package.json, și npm-check, care arată suplimentar versiunile învechite. Implementați regula: fiecare dependență nouă trece prin code review cu justificarea „de ce nu se poate cu mijloace standard”.

Importurile moarte și codul comentat

Importurile moarte — cel mai răspândit tip de jank. Ele nu afectează runtime-ul, dar măresc timpul de compilare: compilatorul procesează fiecare import, chiar dacă nu este utilizat. În proiectele mari, eliminarea importurilor neutilizate reduce timpul de compilare cu 5–10 procente.

IDE-urile moderne evidențiază automat importurile neutilizate cu gri. Configurați curățarea automată la salvarea fișierului: în IntelliJ IDEA — Optimize Imports on the fly, în Xcode — Editor > Remove Unused Imports. În CI adăugați o verificare: linter-ul trebuie să blocheze commit-urile cu importuri neutilizate.

Codul comentat — un alt tip de jank. Dezvoltatorii comentează blocuri pentru a „nu pierde” funcționalitatea în timpul refactorizării. Însă git păstrează istoricul complet al modificărilor: orice cod șters poate fi restaurat cu o singură comandă git revert sau git log -S . Codul comentat în master este o lipsă de respect față de echipă: fiecare dezvoltator consumă energie mentală întrebându-se „de ce e comentat și când trebuie decomentat”.

Regula: în repository nu există cod comentat. Dacă codul nu este necesar — ștergeți-l definitiv. Dacă codul este necesar dar temporar dezactivat — utilizați un feature toggle cu tichet și termen limită. Comentariile de tip // TODO: remove after migration — nu le lăsați fără termen. Puneți o dată și setați un memento în calendar.

Abstracțiile redundante și over-engineering

Over-engineering — crearea de straturi arhitecturale care nu rezolvă problemele curente dar necesită întreținere. Este unul dintre cele mai dificile tipuri de jank pentru că formal codul este „corect”: respectă SOLID, este acoperit cu teste și corespunde arhitecturii. Problema este că nu este necesar.

Exemplul clasic — o clasă abstractă UseCase cu o singură metodă invoke care doar apelează repository-ul. Dacă UseCase nu adaugă logică (cache, retry, transformare), ci doar transmite apelul mai departe — este o entitate suplimentară. Crește navigarea prin proiect: dezvoltatorul deschide UseCase, vede invoke → repository — și închide. Timp pierdut, beneficiu zero.

Un alt exemplu — parametrizarea excesivă. O interfață generică cu șase parametri de tip, utilizată într-un singur loc. Fiecare parametru de tip este o încărcătură cognitivă: la citirea codului trebuie să ții în minte șase tipuri, deși doar două sunt utilizate efectiv. Dacă abstracția nu este reutilizată — este redundantă.

Criteriul de tăiere: dacă abstracția nu este reutilizată în trei contexte diferite — eliminați-o. Abstracția este justificată când rezolvă efectiv o problemă de duplicare, nu când prezice scenarii ipotetice de viitor. YAGNI (You Ain't Gonna Need It) — cel mai bun principiu de prevenire a over-engineering-ului.

Instrumente de audit al jank-ului

Auditul jank-ului necesită o combinație de analiză statică, analiză a dependențelor și verificare manuală. Nu se poate automatiza complet căutarea abstracțiilor redundante, dar jank-ul tehnic (importuri moarte, biblioteci neutilizate, cod comentat) se găsește cu instrumente.

Pentru un audit complet, rulați buildHealth (Android) sau depcheck (Node.js) o dată pe sprint. Creați un dashboard în CI care să arate dinamica numărului de dependențe de-a lungul sprinturilor. Dacă numărul crește, iar funcționalitatea nu crește proporțional — echipa acumulează jank.

Fiți atenți la duplicate classes — o eroare când două biblioteci conțin aceeași clasă. Aceasta nu este doar jank, ci și o sursă directă de conflicte de compilare. În Gradle, astfel de conflicte se rezolvă prin force sau exclude, dar fiecare astfel de rezolvare este un semnal că una dintre biblioteci este de prisos.

Procesul de curățare regulată a proiectului

Curățarea jank-ului nu este o acțiune unică, ci un proces regulat. Fără un regulament, jank-ul revine în două-trei sprinturi. Cea mai bună practică — alocați 10–15 procente din capacitatea fiecărui sprint pentru curățarea tehnică, inclusiv auditul jank-ului.

Procesul constă din patru pași. Primul — diagnosticare: lansarea instrumentelor, obținerea raportului, prioritizarea. Prioritate înaltă — dependențele cu CVE cunoscute și bibliotecile duplicate. Medie — importurile moarte și codul comentat. Scăzută — abstracțiile redundante (necesită analiză manuală).

Al doilea — curățare: eliminarea dependențelor moarte, înlocuirea bibliotecilor duplicate cu una singură, ștergerea codului comentat. Fiecare modificare se face într-un commit separat cu un mesaj clar: „remove unused dependency: gson (replaced by kotlinx.serialization)”, „delete commented code in LoginViewModel”.

Al treilea — verificare: compilarea proiectului, rularea testelor, verificarea UI. Dacă după eliminarea dependenței testele trec — dependența chiar nu era necesară. Dacă testele eșuează — înseamnă că a rămas o referință ascunsă pe care analizorul static nu a detectat-o.

Al patrulea — prevenție: actualizarea checklist-ului de code review, adăugarea regulii „nicio dependență nouă fără justificare” în Definition of Done, configurarea verificării automate în CI. Prevenția este singura modalitate de a împiedica acumularea repetată a jank-ului.