YAGNI în dezvoltarea aplicațiilor: ce este, esența principiului și beneficiul practic

Ce este YAGNI?

YAGNI (You Aren't Gonna Need It) — un principiu al programării extreme (XP), care înseamnă „nu vei avea nevoie de asta“. Regula spune: nu implementa niciodată funcționalități care nu sunt cerute de poveștile de utilizator curente. Dacă o funcție nu este necesară astăzi — nu o face nici măcar „pentru orice eventualitate“.

Termenul a fost introdus de Ron Jeffries, unul dintre coautorii metodologiei XP (împreună cu Kent Beck). Jeffries susținea: „Implementează cel mai simplu lucru care funcționează și nu adăuga nimic până nu este necesar“. YAGNI — nu este o interdicție de planificare, ci o interdicție de implementare prematură.

Conform datelor Standish Group CHAOS Report (2023), 64% din funcții într-un produs software mediu sunt folosite rar sau niciodată. Dacă extrapolăm la o aplicație mobilă — peste jumătate din codul scris nu aduce valoare utilizatorului. YAGNI previne această risipă de resurse.

Aplicați YAGNI ca un filtru strict: fiecare funcție trebuie să răspundă la întrebarea „ce problemă a unui utilizator concret rezolvă chiar acum?“ Dacă nu există răspuns — funcția nu este necesară.

Diferența dintre YAGNI și lene și tăierea colțurilor

YAGNI — nu este renunțare la arhitectura de calitate. YAGNI interzice scrierea de cod inutil, dar nu interzice scrierea de cod corect. Dacă pentru funcția curentă este necesar un strat de abstractizare curat — creați-l. Dacă stratul nu este necesar — nu-l creați. Diferența cheie: YAGNI este despre funcționalitate, nu despre calitate.

Dezvoltatorii confundă adesea YAGNI cu acumularea intenționată de datorie tehnică (datoria tehnică este întotdeauna un compromis, YAGNI este un principiu de eficiență). Diferența este că datoria tehnică este conștientă și documentată, iar încălcarea YAGNI este pur și simplu muncă inutilă.

Puneți-vă întrebarea: „Dacă nu fac această abstractizare acum, cât timp va dura refactorizarea când va fi necesară?“ Dacă timpul de refactorizare este mai mic decât timpul de scriere acum — amânați.

De ce este YAGNI critic pentru proiectele mobile?

Dezvoltarea aplicațiilor mobile este deosebit de sensibilă la încălcarea YAGNI din trei motive: dimensiunea APK/IPA influențează direct conversia instalării, timpul de compilare a proiectelor mobile crește liniar cu volumul de cod, iar fiecare funcție suplimentară adaugă puncte de defectare. YAGNI — nu despre lene, ci despre focus.

Google Play Console Data (2023) a arătat: fiecare 10 MB de dimensiune APK reduce probabilitatea de instalare cu 1,2%. Codul nefolosit nu este doar gunoi în depozit, ci pierderi financiare directe. Bibliotecile inutile (pentru funcționalități pe care „poate le vom adăuga mai târziu“) — cea mai frecventă sursă de umflare a APK-ului.

Gradle Build Performance Report (2024), fiecare modul suplimentar într-un proiect Android mărește timpul de compilare completă cu 3–7 secunde. Dacă adăugați 5 module „Pentru viitor“ — creșterea timpului de compilare va fi de 15–35 de secunde la fiecare build. Într-un an, o echipă de 5 dezvoltatori pierde până la 200 de ore-om așteptând compilarea.

Monitorizați dimensiunea binarului în CI: setați o limită de avertizare (de exemplu, +500 KB per commit). Dacă dimensiunea a crescut fără o funcție nouă — aceasta este o încălcare YAGNI care trebuie discutată la code review.

YAGNI vs gold-plating: exemple practice

Gold-plating: animație prematură

Gold-plating — adăugarea de funcționalități peste cerințe într-o încercare de „îmbunătățire“ a produsului. Exemplu tipic: dezvoltatorul adaugă o animație complexă de tranziție între ecrane, deși în design este specificat un fade simplu. Animația durează 2 zile, utilizatorul nu o observă, iar bug-urile pe diferite dispozitive bântuie proiectul ani de zile.

UX Collective Annual Report (2023) 78% dintre utilizatori evaluează aplicația după viteză și stabilitate, nu după animații. YAGNI spune: dacă animația nu este specificată în cerințe — nu o implementați. Designerul va adăuga animația atunci când va fi cu adevărat necesară pentru rezolvarea unei probleme de UX.

Implementați doar ceea ce este în machete. Dacă designerul nu a desenat animația — înseamnă că nu ar trebui să existe. Orice abatere de la machetă este o încălcare YAGNI.

Localizare prematură în 20 de limbi

O greșeală frecventă a startup-urilor: să includeți imediat suport pentru 20+ limbi „Pentru viitoarea intrare pe piața internațională“. YAGNI recomandă: localizați doar pentru limba pieței curente. Adăugarea fiecărei limbi noi necesită timpul traducătorilor, testarea tăierii șirurilor și depanarea layout-ului RTL.

Deloitte Digital Globalization Survey (2022) a arătat: 60% din aplicațiile mobile nu depășesc niciodată prima piață. Dacă acesta este cazul vostru — resursele pentru multilingvism sunt irosite. Abordarea YAGNI: engleză (de bază) + limba pieței țintă. Restul — pe măsură ce intrați efectiv în regiune.

Folosiți YAGNI pentru prioritizare: dacă o funcție nu se află în roadmap-ul următoarelor două trimestre — nu o începeți. Roadmap-ul trebuie să fie aprobat documentar de product manager.

Cum să aplici YAGNI în Android și iOS?

YAGNI în Android: nu adăugați biblioteci inutile

Proiectele Android suferă de inflație bibliotecară. Dezvoltatorii conectează Retrofit, OkHttp, Gson, Room, Dagger Hilt, Navigation Component, DataStore — chiar înainte de a fi scrisă prima linie de logică de afaceri. YAGNI recomandă: conectați bibliotecile pe măsură ce apar nevoi reale, nu preventiv.

// Înfrăngerea YAGNI: conectarea preventivă a bibliotecilor
// build.gradle (module)
implementation("com.squareup.retrofit2:retrofit:2.9.0")
implementation("com.squareup.retrofit2:converter-gson:2.9.0")
implementation("androidx.room:room-runtime:2.6.0")

// Iar aplicația deocamdată arată doar "Hello World"

Bibliotecile sunt dependențe cu propria complexitate. Fiecare necesită actualizări de versiune, migrare la breaking changes și mărește dimensiunea APK-ului. Conectați o bibliotecă atunci când apare o sarcină concretă rezolvată de acea bibliotecă. Începeți cu OkHttp (client HTTP minim), adăugați Retrofit când este nevoie de un client REST, etc.

YAGNI în iOS: nu forțați SwiftUI

SwiftUI — un framework puternic, dar implementarea lui ar trebui dictată de nevoi reale. Dacă proiectul pornește cu iOS 14+ și cerințele pentru componente UI personalizate sunt minime — SwiftUI este o alegere bună. Dacă proiectul trebuie să suporte iOS 13 sau necesită gesturi personalizate complexe — UIKit rămâne soluția corectă. YAGNI este împotriva migrării la SwiftUI „pentru că este la modă“.

// YAGNI: folosiți UIKit până nu există un beneficiu real de la SwiftUI
class ProfileViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "Profil"
    }
}

// Dacă aveți nevoie de SwiftUI — implementați prin UIHostingController
let swiftUIView = ProfileView()
let hostingVC = UIHostingController(rootView: swiftUIView)

Point-Free: „SwiftUI vs UIKit Decision Guide“ (2024) nu migrați ecranele UIKit existente la SwiftUI fără un motiv clar de afaceri (de exemplu, necesitatea Live Preview pentru designer). Rescrierea codului funcțional este o încălcare directă YAGNI. SwiftUI — pentru ecrane noi, UIKit — pentru cele existente.

Greșeli tipice la respectarea YAGNI

YAGNI ca scuză pentru arhitectură proastă

Cea mai periculoasă greșeală — să folosești YAGNI ca scuză pentru o arhitectură proastă. „Nu vom separa stratul de repository, pentru că YAGNI — vom scrie interogarea direct în ViewModel“. Acesta nu este YAGNI, ci acumulare de datorie tehnică. YAGNI interzice funcționalitatea inutilă, nu integritatea arhitecturală.

Arhitectura este o investiție în mentenabilitate. Dacă scrieți mai mult de 3 ecrane — stratul arhitectural de bază (MVVM, repository) este deja justificat. Dacă este 1 ecran — vă puteți permite o abordare simplă. Cheia: determinați minimul arhitectural necesar pentru funcțiile curente și nu adăugați mai mult.

Împărțiți deciziile în „arhitecturale“ și „funcționale“. Deciziile arhitecturale (straturi, navigare, DI) nu sunt acoperite de YAGNI — ele sunt necesare pentru mentenabilitate. Cele funcționale (funcții, capturi de ecran, animații) — sunt acoperite.

Respectarea oarbă a YAGNI la lucrul cu API

Cealaltă extremă — ignorarea contractelor viitoare API. Dezvoltatorul primește de la backend un JSON cu 5 câmpuri și parsează doar 3, pentru că „restul nu sunt necesare conform YAGNI“. Problemă: la adăugarea unui câmp, backend-ul poate strica parsarea dacă răspunsul s-a schimbat. Soluție — maparea tuturor câmpurilor de răspuns, chiar dacă nu toate sunt folosite acum.

Conform Meta API Design Guidelines (2023), clientul ar trebui să parseze toate câmpurile returnate de server, ignorându-le pe cele nefolosite, dar fără a arunca întreaga structură. YAGNI aici este despre altceva: nu trebuie să adăugați procesarea câmpurilor care nu sunt încă în specificație, „în cazul în care backend-ul le-ar putea returna“.

Parseați întreaga structură a răspunsului (toate câmpurile pe care serverul le returnează acum). Nu adăugați procesarea câmpurilor care nu sunt în specificația API curentă. Acesta este echilibrul între YAGNI și rezistența la schimbări.