YAGNI ve vývoji aplikací: Co to je, podstata principu a praktický přínos

Co je YAGNI?

YAGNI (You Aren't Gonna Need It) — princip extrémního programování (XP), který znamená „nebudeš to potřebovat". Pravidlo říká: nikdy neimplementujte funkcionalitu, která není vyžadována aktuálními uživatelskými příběhy. Pokud funkce není potřeba dnes — nedělejte ji, ani „pro jistotu".

Termín zavedl Ron Jeffries, jeden ze spoluautorů metodiky XP (spolu s Kentem Beckem). Jeffries prohlásil: „Implementujte nejjednodušší věc, která funguje, a nepřidávejte nic, dokud to není potřeba." YAGNI — není zákaz plánování, ale zákaz předčasné implementace.

Podle Standish Group CHAOS Report (2023) je 64 % funkcí v průměrném softwarovém produktu používáno zřídka nebo nikdy. Pokud to extrapolujeme na mobilní aplikaci — více než polovina napsaného kódu nepřináší uživateli hodnotu. YAGNI tomuto plýtvání zdrojů zabraňuje.

Aplikujte YAGNI jako přísný filtr: každá funkce musí odpovědět na otázku „jaký konkrétní problém uživatele řeší právě teď?" Pokud odpověď neexistuje — funkce není potřeba.

Rozdíl mezi YAGNI a leností a obcházením problémů

YAGNI — není odmítnutí kvalitní architektury. YAGNI zakazuje psát nadbytečný kód, ale nezakazuje psát správný kód. Pokud aktuální funkce vyžaduje čistou vrstvu abstrakce — vytvořte ji. Pokud vrstva není potřeba — nevytvářejte ji. Klíčový rozdíl: YAGNI se týká funkcionality, ne kvality.

Vývojáři často zaměňují YAGNI se záměrným hromaděním technického dluhu (technický dluh je vždy kompromis, YAGNI je princip efektivity). Rozdíl je v tom, že technický dluh je uvědomělý a dokumentovaný, zatímco porušení YAGNI je jen zbytečná práce.

Zeptejte se sami sebe: „Pokud tuto abstrakci neudělám teď, jak dlouho bude trvat refactoring, až bude potřeba?" Pokud je doba refactoringu kratší než doba psaní nyní — odložte.

Proč je YAGNI kritický pro mobilní projekty?

Mobilní vývoj je obzvláště citlivý na porušení YAGNI ze tří důvodů: velikost APK/IPA přímo ovlivňuje konverzi instalace, doba kompilace mobilních projektů roste lineárně s objemem kódu a každá další funkce přidává body selhání. YAGNI — není o lenosti, ale o zaměření.

Výzkum Google Play Console Data (2023) ukázal: každých 10 MB velikosti APK snižuje pravděpodobnost instalace o 1,2 %. Nepoužitý kód není jen odpad v repozitáři, je to přímá finanční ztráta. Zbytečné knihovny (pro funkcionalitu, kterou „možná přidáme později") jsou nejčastějším zdrojem nafukování APK.

Podle Gradle Build Performance Report (2024) každý další modul v Android projektu zvyšuje dobu plného sestavení o 3–7 sekund. Pokud přidáte 5 modulů „do budoucna" — nárůst doby kompilace bude 15–35 sekund na každé sestavení. Za rok tým 5 vývojářů ztrácí až 200 člověkohodin čekáním na kompilaci.

Sledujte velikost binárního souboru v CI: nastavte limit varování (např. +500 KB na commit). Pokud velikost vzrostla bez nové funkce — je to porušení YAGNI, které je třeba probrat v code review.

YAGNI versus gold-plating: praktické příklady

Gold-plating: předčasná animace

Gold-plating — přidávání funkcionality nad rámec požadavků ve snaze „vylepšit" produkt. Typický příklad: vývojář přidá složitou přechodovou animaci mezi obrazovkami, přestože design uvádí jednoduché fade. Animace zabere 2 dny, uživatel si jí nevšimne a chyby na různých zařízeních pronásledují projekt roky.

Podle UX Collective Annual Report (2023) 78 % uživatelů hodnotí aplikaci podle rychlosti a stability, ne podle animací. YAGNI říká: pokud animace není uvedena v požadavcích — neimplementujte ji. Návrhář přidá animaci, až když bude skutečně potřeba pro řešení UX problému.

Implementujte pouze to, co je v maketách. Pokud návrhář nenakreslil animaci — znamená to, že by neměla být. Jakákoli odchylka od makety je porušení YAGNI.

Předčasná lokalizace do 20 jazyků

Častá chyba startupů: okamžitě plánovat podporu 20+ jazyků „pro budoucí vstup na mezinárodní trh". YAGNI doporučuje: lokalizujte pouze do jazyka současného trhu. Přidání každého nového jazyka vyžaduje čas překladatelů, testování zkracování řetězců a ladění RTL rozvržení.

Průzkum Deloitte Digital Globalization Survey (2022) ukázal: 60 % mobilních aplikací nikdy nepřekročí první trh. Pokud je to váš případ — zdroje na vícejazyčnost byly promarněny. Přístup YAGNI: angličtina (základ) + jazyk cílového trhu. Ostatní — podle skutečného vstupu do regionu.

Používejte YAGNI pro prioritizaci: pokud funkce není v roadmapě nejbližších dvou čtvrtletí — nezačínejte ji. Roadmapa musí být dokumentovaně schválena product managerem.

Jak aplikovat YAGNI v Androidu a iOS?

YAGNI v Androidu: nepřidávejte zbytečné knihovny

Android projekty trpí inflací knihoven. Vývojáři přidávají Retrofit, OkHttp, Gson, Room, Dagger Hilt, Navigation Component, DataStore — ještě před napsáním prvního řádku business logiky. YAGNI doporučuje: přidávejte knihovny podle skutečné potřeby, ne preventivně.

// Porušení YAGNI: preventivní přidávání knihoven
// 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")

// Aplikace zatím jen zobrazuje “Hello World”

Knihovny jsou závislosti s vlastní složitostí. Každá vyžaduje aktualizace verzí, migraci při breaking changes a zvětšuje velikost APK. Přidejte knihovnu, když existuje konkrétní úkol, který tato knihovna řeší. Začněte s OkHttp (minimální HTTP klient), přidejte Retrofit, až bude potřeba REST klient, atd.

YAGNI v iOS: nenuťte SwiftUI

SwiftUI — výkonný framework, ale jeho zavedení by mělo být diktováno skutečnými potřebami. Pokud projekt startuje s iOS 14+ a požadavky na vlastní UI komponenty jsou minimální — SwiftUI je dobrá volba. Pokud projekt musí podporovat iOS 13 nebo vyžaduje složitá vlastní gesta — UIKit zůstává správným řešením. YAGNI je proti migraci na SwiftUI „protože je to moderní".

// YAGNI: použijte UIKit, dokud není skutečný přínos ze SwiftUI
class ProfileViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "Profil"
    }
}

// Pokud je potřeba SwiftUI — implementujte přes UIHostingController
let swiftUIView = ProfileView()
let hostingVC = UIHostingController(rootView: swiftUIView)

Analýza Point-Free: „SwiftUI vs UIKit Decision Guide" (2024) doporučuje: nemigrujte existující UIKit obrazovky na SwiftUI bez jasného obchodního důvodu (např. potřeba Live Preview pro designéra). Přepisování fungujícího kódu je přímé porušení YAGNI. SwiftUI — pro nové obrazovky, UIKit — pro stávající.

Typické chyby při dodržování YAGNI

YAGNI jako omluva špatné architektury

Nejnebezpečnější chybou je použití YAGNI jako omluvy pro špatnou architekturu. „Nebudeme vytvářet vrstvu repozitáře, protože YAGNI — napíšeme dotaz přímo do ViewModelu." To není YAGNI, to je hromadění technického dluhu. YAGNI zakazuje nadbytečnou funkcionalitu, ne architektonickou integritu.

Architektura je investice do udržovatelnosti. Pokud píšete více než 3 obrazovky — základní architektonická vrstva (MVVM, repozitář) je již oprávněná. Pokud 1 obrazovka — můžete si dovolit jednodušší přístup. Klíč: určete architektonické minimum potřebné pro aktuální funkce a nepřidávejte víc.

Rozdělte rozhodnutí na „architektonická" a „funkční". Architektonická rozhodnutí (vrstvy, navigace, DI) nejsou pokryta YAGNI — jsou potřebná pro udržovatelnost. Funkční rozhodnutí (funkce, snímky obrazovek, animace) — jsou pokryta.

Slepé dodržování YAGNI při práci s API

Další extrém — ignorování budoucích API kontraktů. Vývojář obdrží JSON z backendu s 5 poli a parsuje pouze 3, protože „ostatní nejsou podle YAGNI potřeba". Problém: při přidání pole může backend rozbít parsování, pokud se odpověď změnila. Řešení — mapování všech polí odpovědi, i když ne všechna jsou nyní používána.

Podle Meta API Design Guidelines (2023) by měl klient parsovat všechna pole, která server vrací, ignorovat nepoužívaná, ale nezahazovat celou strukturu. YAGNI je zde o něčem jiném: nepřidávejte zpracování polí, která ještě nejsou ve specifikaci, „pro případ, že je backend vrátí".

Parsujte celou strukturu odpovědi (všechna pole, která server aktuálně vrací). Nepřidávejte zpracování polí, která nejsou v aktuální API specifikaci. Toto je rovnováha mezi YAGNI a odolností vůči změnám.