YAGNI az alkalmazásfejlesztésben: Mi ez, az elv lényege és gyakorlati haszna

Mi az a YAGNI?

YAGNI (You Aren't Gonna Need It) — az extrém programozás (XP) elve, ami azt jelenti: ‘nem lesz rá szükséged’. A szabály kimondja: soha ne implementálj olyan funkcionalitást, amelyet a jelenlegi user story-k nem követelnek meg. Ha egy funkció ma nem kell — ne csináld meg, még ‘biztos, ami biztos’ alapon sem.

A kifejezést Ron Jeffries vezette be, az XP metódika egyik társzerzõje (Kent Beckkel). Jeffries állította: “A legegyszerűbb dolgot valósítsd meg, ami mŰködik, és ne adj hozzá semmit, amíg nem szŰkséges.” YAGNI — nem a tervezés tilalma, hanem a korai megvalósítás tilalma.

A Standish Group CHAOS Report (2023) szerint az átlagos szoftvertermék funkcióinak 64%-át ritkán vagy soha nem használják. Ha ezt mobilalkalmazásra extrapoláljuk — a megírt kód több mint fele nem nyújt értéket a felhasználó számára. YAGNI megakadályozza ezt az erŐforráspazarlást.

Alkalmazd a YAGNI-t szigorŰ szűrŐként: minden funkciónak válaszolnia kell a kérdésre: “milyen konkrét felhasználói problémát oldja meg éppen most?” Ha nincs válasz — a funkció nem kell.

A YAGNI eltérése a lustaságtól és a sarkok levágásától

YAGNI — nem a minŐségi architektŰra elutasítása. A YAGNI tiltja a felesleges kód írását, de nem tiltja a helyes kód megírását. Ha az aktuális funkcióhoz tiszta absztrakciós réteg kell — hozd létre. Ha a réteg nem kell — ne hozd létre. FŐ kŰlŐnbség: a YAGNI a funkcionalitásról szól, nem a minŐségrŐl.

A fejlesztŐk gyakran Ősszetévesztik a YAGNI-t a szándékos technikai adŐsség halmozással (a tech adŐsság mindig kompromisszum, a YAGNI hatékonysági elv). A kŰlŐnbség az, hogy a technikai adŐsságot tudatosítják és dokumentálják, míg a YAGNI megsértése csak plusz munka.

Kérdezd meg magad: “Ha most nem csinálom meg ezt az absztrakciót, mennyi ideig tart a refactoring, amikor majd kell?” Ha a refactoring ideje kevesebb, mint a mostani megírás ideje — halaszd el.

Miért kritikus a YAGNI a mobil projektek számára?

Mobilfejlesztés kŰlŐnŐsen érzékeny a YAGNI megsértésére három ok miatt: az APK/IPA mérete kŐzvetlenŐl befolyásolja a telepítési konverziót, a mobil projektek fordítási ideje lineárisan nŐ a kód mennyiségével, és minden plusz funkció hibapontokat ad hozzá. YAGNI — nem a lustaságról, hanem a fókuszról szól.

A Google Play Console Data (2023) kutatása kimutatta: minden 10 MB APK-méret 1,2%-kal csŰkkenti a telepítés valószínŰségét. A nem használt kód nem csak szemét a repozitóriumban, hanem kŐzvetlen pénzŐgyi veszteség. Felesleges kŐnyvtárak (olyan funkcionalitáshoz, amit ‘majd késŐbb hozzáadunk’) az APK dagadásának leggyakoribb forrásai.

A Gradle Build Performance Report (2024) szerint minden további modul egy Android-projektben 3–7 másodperccel nŐveli a teljes build idejét. Ha 5 modult adsz hozzá ‘a jŐvŐre’ — a fordítási idŐ nŐvekedése 15–35 másodperc lesz buildenként. Egy 5 fŐs csapat évente akár 200 munkaŰrát veszíthet a fordításra várással.

Figyeld a bináris méretét CI-ben: állíts be figyelmeztetési határt (pl. +500 KB commitonként). Ha a méret nŐtt űj funkció nélkŰl — ez a YAGNI megsértése, amit meg kell beszélni a code review során.

YAGNI kontra gold-plating: gyakorlati példák

Gold-plating: korai animáció

Gold-plating — funkcionalitás hozzáadása a kŰvetelményeken felŰl a termék ‘javítás’ érdekében. Tipikus példa: a fejlesztŐ űsszetett átmeneti animációt ad hozzá a képernyŐk kŰzŰtt, holott a design egyszerű fade-et í elŰ. Az animáció 2 napig tart, a felhasználó nem veszi észre, és a kŰlŐnbŐzŐ eszkŰzŐkŐn jelentkezŐ hibák évekig kísérik a projektet.

A UX Collective Annual Report (2023) szerint a felhasználók 78%-a a sebesség és stabilitás alapján értékeli az alkalmazást, nem az animációk alapján. YAGNI azt mondja: ha az animáció nincs a kŰvetelményekben — ne implementáld. A tervezŐ hozzáadja az animációt, amikor tényleg szŰkséges egy UX-probléma megoldásához.

Csak azt implementáld, ami a maketteken szerepel. Ha a tervezŐ nem rajzolt animációt — akkor nem is kell lennie. Bármilyen eltérés a maketttŐl a YAGNI megsértése.

Korai lokalizáció 20 nyelvre

A startupok gyakori hibája: azonnal 20+ nyelv támogatását tervezik ‘a jŐvŐbeli nemzetkŰzi piacra lépéshez’. YAGNI azt ajánlaná: csak az aktuális piac nyelvére lokalizálj. Minden űj nyelv hozzáadása fordítŐi időt, string-levágás tesztelést és RTL-elrendezés hibakeresést igényel.

A Deloitte Digital Globalization Survey (2022) kimutatta: a mobilalkalmazások 60%-a soha nem lép ki az első piacról. Ha ez a te eseted — a többnyelvűségre szánt erŐforrások kárba mennek. YAGNI-megkŰzelítés: angol (alap) + a célpiac nyelve. A többi — a tényleges piacra lépés szerint.

Használd a YAGNI-t prioritálásra: ha egy funkció nem szerepel a kŰvetkezŐ két negyedév űttervében — ne kezdd el. Az űttervet a product managernek dokumentáltan jóvá kell hagynia.

Hogyan alkalmazzuk a YAGNI-t Androidon és iOS-en?

YAGNI Androidon: ne adj hozzá felesleges kŐnyvtárakat

Android-projekteket sŰjtja a kŐnyvtárinfláció. A fejlesztŐk hozzáadják a Retrofit, OkHttp, Gson, Room, Dagger Hilt, Navigation Component, DataStore kŐnyvtárakat — még azelŐtt, hogy az űzleti logika első sorát megírták. YAGNI azt ajánlaná: a kŐnyvtárakat a tényleges szŰkség szerint add hozzá, ne elŐre megelŐzŐ jelleggel.

// YAGNI megsértése: könyvtárak preventív hozzáadása
// 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")

// Az alkalmazás jelenleg csak a “Hello World”-t mutatja

A kŐnyvtárak saját komplexitással bírŐ fŰggŐségek. Mindegyik verziófrissítést, migrációt váltástŐrásoknál és APK-méret-nŐvekedést igényel. Add hozzá a kŐnyvtárat, amikor konkrét feladat van, amit az a kŐnyvtár megold. Kezdd az OkHttp-val (minimális HTTP-kliens), add hozzá a Retrofitot, amikor REST-kliensre van szŰkség, és így tovább.

YAGNI iOS-en: ne erŐltesd a SwiftUI-t

SwiftUI — egy erŐteljes framework, de a bevezetését valŐs igényeknek kell vezérelniŘk. Ha a projekt iOS 14+-cal indul és minimálisak az egyedi UI-ŐsszetevŐk iránti igények — a SwiftUI jŐ választás. Ha a projektnek támogatnia kell iOS 13-at vagy űsszetett egyedi gesztusokat igényel — a UIKit marad a helyes megoldás. YAGNI ellenzi a SwiftUI-re váltást ‘mert ez a divat’.

// YAGNI: használj UIKit-et, amíg nincs valós előnye a SwiftUI-nak
class ProfileViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "Profil"
    }
}

// Ha SwiftUI kell — vezesd be UIHostingControlleren keresztül
let swiftUIView = ProfileView()
let hostingVC = UIHostingController(rootView: swiftUIView)

A Point-Free: “SwiftUI vs UIKit Decision Guide” (2024) elemzése azt ajánlaná: ne migráld a meglévŐ UIKit-képernyŐket SwiftUI-ra egyértelmű űzleti ok nélkŰl (például Live Preview szŰkségessége a tervezŐ számára). A mŰködŐ kód űjraírása a YAGNI kŐzvetlen megsértése. SwiftUI — űj képernyŐkhŐz, UIKit — a meglévŐkhŐz.

Tipikus hibák a YAGNI követésében

YAGNI a rossz architektŰra igazolásaként

A legveszélyesebb hiba a YAGNI használata a rossz architektŰra igazolására. “Nem emelŘnk ki repo réteget, mert YAGNI — írjuk a lekérdezést kŐzvetlenŐl a ViewModelbe.” Ez nem YAGNI, ez technikai adŐsség halmozása. YAGNI tiltja a felesleges funkcionalitást, nem az architekturális integritást.

Az architektŰra befektetés a karbantarthatóságba. Ha több mint 3 képernyŐt írsz — az alapvetŐ architekturális réteg (MVVM, repository) már indokolt. Ha 1 képernyŐ — megengedheted magadnak az egyszerű megkŰzelítést. Kulcs: határozd meg az aktuális funkciókhoz szŰkséges architekturális minimumot, és ne adj hozzá többet.

Válaszd szét a dŰntéseket ‘architekturális’ és ‘funkcionális’ kategóriákra. Az architekturális dŰntéseket (rétegek, navigáció, DI) nem fedi le a YAGNI — ezek a karbantarthatóság miatt kellenek. A funkcionális dŰntéseket (funkciók, képernyŐképképek, animációk) — igen.

Vak követése a YAGNI-nak API-munka során

Egy másik szélsŐség — a jŐvŐbeli API-kontraktusok figyelmen kívŰl hagyása. A fejlesztŐ JSON-t kap a backendtŐl 5 mezŐvel, és csak 3-at dolgoz fel, mert “a többi nem kell a YAGNI szerint”. Probléma: amikor a backend hozzáad egy mezŐt, eltŐrhet a feldolgozás, ha a válasz megváltozik. A megoldás — az űsszes válaszmezŐ leképezése, még ha nem is használod mindet most.

A Meta API Design Guidelines (2023) szerint a kliensnek fel kell dolgoznia minden mezŐt, amit a szerver visszakŰld, figyelmen kívŰl hagyva a nem használtakat, de nem eldobva a teljes struktŰrát. YAGNI itt másrŐl szŰl: ne add hozzá olyan mezŐk kezelését, amelyek még nincsenek a specifikációban, ‘arra az esetre, ha a backend visszaadná’.

Dolgozd fel a teljes válaszstruktŰrát (az űsszes mezŐt, amit a szerver jelenleg visszakŰld). Ne add hozzá olyan mezŐk kezelését, amelyek nincsenek a jelenlegi API specifikációban. Ez az egyensŰly a YAGNI és a változásokkal szembeni ellenállóképesség kŰzŰtt.