YAGNI

Co je to YAGNI?

YAGNI je zkratka pro "You Ain't Gonna Need It" (česky: nebudeš to potřebovat) – jeden ze základních principů Extreme Programming a agilního vývoje, který říká: implementuj pouze funkcionalitu, kterou právě teď skutečně potřebuješ, ne to, co si myslíš, že by se mohlo hodit v budoucnu. Tento princip formuloval Ron Jeffries, jeden ze zakladatelů Extreme Programming, jako reakci na častou tendenci vývojářů přidávat "na zásobu" funkce, které by jednou možná někdo mohl potřebovat. Problém je, že většina takových funkcí se nikdy nepoužije – podle různých studií až 64% features v software projektech se používají zřídka nebo nikdy. Přitom každá taková funkce stála čas na návrh, implementaci, testování a dokumentaci. A co hůř, zvyšuje komplexitu kódové základny, což komplikuje údržbu a přidávání skutečně potřebných funkcí. YAGNI vás nutí klást si otázku: "Potřebujeme tuto funkcionalitu právě teď pro aktuální požadavky, nebo ji přidáváme preventivně pro hypotetickou budoucnost?" Pokud je odpověď "pro budoucnost", YAGNI říká: neimplementuj to. Klíčové je rozlišovat YAGNI od špatného designu. YAGNI neznamená hackovat rychlá řešení bez ohledu na architekturu. Znamená to mít flexibilní, čistý základ (clean code, SOLID principy), ale neimplementovat konkrétní funkce, které teď nikdo nepotřebuje. Rozdíl je v tom, že dobrou architekturu je těžké změnit později, zatímco konkrétní funkce můžete snadno přidat, když budou skutečně potřeba.

Proč vznikl YAGNI princip?

YAGNI vznikl jako odpověď na běžnou chybu ve vývoji softwaru – předčasné přeprogramování (premature generalization). Vývojáři rádi přemýšlíme dopředu a snažíme se být připraveni na budoucí požadavky. To zní rozumně, ale v praxi to způsobuje více škody než užitku. Představte si, že vyvíjíte e-shop pro český trh. Vývojář si řekne: "Co když jednou budou chtít prodávat i na Slovensku? Nebo v celé EU? Radši hned udělám systém na více měn, jazyků a DPH sazeb." Problém je, že tato "příprava na budoucnost" zabere týdny práce, během kterých byste mohli implementovat skutečně potřebné funkce. A co hůř – když pak za rok přijde skutečný požadavek na expanzi, ukáže se, že měli úplně jiné představy, a váš preventivní kód stejně musíte přepsat.

Extreme Programming a agilní metodologie se zaměřují na iterativní vývoj – dodáváte malé funkční celky, získáváte feedback a upravujete směr. V tomto přístupu je YAGNI kritický, protože směr projektu se mění na základě reálných dat, ne předpokladů. Pokud implementujete funkce "pro jistotu", porušujete agilní princip "reagovat na změnu je důležitější než následovat plán". YAGNI podporuje lean thinking – eliminaci plýtvání (waste). Práce na nepotřebných funkcích je klasická forma plýtvání v software vývoji. Investujete zdroje do něčeho, co nepřináší hodnotu.

Jak YAGNI funguje v praxi?

• Co implementovat hned

Implementujte funkce explicitně požadované zákazníkem nebo produktovým manažerem pro aktuální sprint či release. Pokud user story říká "uživatel může filtrovat produkty podle ceny", implementujte filtr podle ceny. Nečekejte, co by možná ještě mohli chtít filtrovat. Soustřeďte se na Minimum Viable Product (MVP) – nejmenší sadu funkcí, která doručuje hodnotu. MVP vám umožní získat feedback rychle a iterovat na základě reálných potřeb uživatelů.

• Co odložit na později

Neimplementujte funkce "kdyby náhodou", "pro jistotu" nebo "možná jednou". Pokud nikdo konkrétní funkci nepožaduje pro aktuální release, odložte ji do backlogu. Příklady: konfigurabilní themes, když zákazník chce jedno specifické téma; export do 5 formátů, když teď potřebují jen CSV; komplexní permission systém, když máte dva typy uživatelů. Všechny tyto věci lze přidat později, až budou skutečně potřeba – a tehdy budete implementovat podle aktuálních požadavků, ne dnešních předpokladů.

• Reálné příklady rozhodování

E-shop: "Budeme potřebovat API?" – Pokud teď nemáte mobilní app ani plány na ni, nepotřebujete. Blog: "Co když bude chtít 10 autorů?" – Máte dva autory, prostý permission systém stačí. Reservation systém: "A když někdo bude chtít rezervovat na 6 měsíců dopředu?" – Aktuálně rezervujete na týden, optimalizujte pro to. V každém případě se ptejte: Potřebujeme to teď pro aktuální požadavky? Je to blocker pro launch? Pokud ne, YAGNI říká odložit.

YAGNI vs ostatní principy

• YAGNI vs KISS (Keep It Simple, Stupid)

Oba principy se překrývají v důrazu na jednoduchost, ale KISS se zaměřuje na to "jak" – jednoduché, přímočaré řešení místo komplikovaného. YAGNI se zaměřuje na "co" – neimplementovat nepotřebné funkce. KISS říká: když už něco děláte, dělejte to jednoduše. YAGNI říká: nedělejte věci, které nepotřebujete. Kombinace obou vede k čistému, jednoduchému kódu s minimem funkcionalit.

• YAGNI vs DRY (Don't Repeat Yourself)

DRY říká neopakovat kód, sdílet logiku. Povrchově se to může zdát v konfliktu s YAGNI – abstrakce a znovupoužitelný kód vyžadují "předchozí investici". Klíč je v tom, že DRY aplikujete na existující duplikaci, ne potenciální budoucí. Pokud vidíte stejný kód na třech místech, refaktorujte (DRY). Ale netvoříte abstrakci pro hypotetickou budoucí duplikaci (YAGNI). Rule of three: duplikace na dvou místech tolerujte, na třetím refaktorujte.

• YAGNI vs SOLID principy

SOLID (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) jsou principy objektového designu pro flexibilní architekturu. SOLID a YAGNI se vzájemně doplňují, nekonflikují. SOLID vám dává flexibilní, maintainable základ – když budete potřebovat přidat funkci, bude to snadné. YAGNI vám říká, abyste tu funkci nepřidávali, dokud ji skutečně nepotřebujete. SOLID vytváří otevřenou architekturu, YAGNI zabraňuje přeplnění nepotřebnými implementacemi.

Kdy YAGNI použít a kdy ne?

Používejte YAGNI pro business logiku a features. Pokud klient nežádá multi-currency systém, multi-language support, advanced reporting, role-based permissions pro 15 rolí – neimplementujte to. Tyto věci snadno přidáte, až budou skutečně potřeba. YAGNI platí pro "nice-to-have" features, optimalizace předčasné pro neexistující scale problémy, konfigurovatelnost, kterou nikdo nevyužije.

Neignorujte YAGNI u kritické architektury a bezpečnosti. Volba databáze, API designu, autentizace, logování, error handlingu na hranicích systému – to jsou věci, které je těžké změnit později. Tady investujte do správného řešení od začátku, i když to zabere více času. YAGNI není výmluva pro hacknutá řešení v core architektuře. Bezpečnost nikdy neignorujte – XSS ochrana, SQL injection prevence, šifrování hesel. To jsou must-have, ne nice-to-have.

Rozdíl je v tom, že architekturu je drahé měnit, features jsou levné na přidání. Pokud zvolíte špatnou databázi (relational když potřebujete NoSQL), migrace je nákladná. Pokud přidáte export do XML, když teď potřebují jen CSV, je to snadné. YAGNI se vztahuje na druhou kategorii.

Výhody dodržování YAGNI principu

• Úspora času a nákladů

Nepíšete kód, který nikdy nepoužijete. Místo toho doručujete hodnotu zákazníkovi rychleji. Každá hodina strávená na spekulativní funkcionalitě je hodina, kterou jste mohli investovat do skutečných požadavků.

• Jednodušší kódová základna

Méně kódu znamená méně bugů, jednodušší debugging a rychlejší onboarding nových vývojářů. Čistá, minimalistická kódová základna je snazší pochopit a udržovat.

• Lepší flexibilita

Když přijde skutečný požadavek, implementujete ho s aktuálními znalostmi a technologiemi, ne podle starých předpokladů. Vaše dnešní představa o budoucích potřebách může být zcela jiná než realita.

• Rychlejší delivery a time-to-market

Soustředíte se na MVP a skutečné potřeby, ne na spekulativní funkce. Rychlejší uvedení na trh znamená rychlejší zpětnou vazbu od uživatelů a možnost přizpůsobit směr vývoje.

• Lepší testovatelnost

Méně kódu znamená méně testů, rychlejší test suite a levnější CI/CD. Každá řádka kódu vyžaduje testy a údržbu – méně kódu znamená méně práce.

• Snadnější údržba

Jednodušší kód je snadněji udržovatelný. Vyhnete se legacy kódu, který nikdo nepoužívá, ale nikdo se ho nebojí smazat, protože neví, jestli ho něco potřebuje.

Časté mýty a mylné interpretace YAGNI

• "YAGNI znamená hackovat rychlá řešení bez ohledu na kvalitu"

Nepravda. YAGNI neznamená špinavý kód nebo technický dluh. Znamená to čistý, dobře navržený kód pro aktuální požadavky, ne pro hypotetickou budoucnost. Čistý kód a YAGNI jdou ruku v ruce.

• "YAGNI zakázuje plánování a design"

Nepravda. YAGNI se netýká architektury a designu systému. Investujte do dobrého API designu, volby správných technologií, SOLID principů. YAGNI říká: neimplementuj konkrétní features, které teď nikdo nepotřebuje.

• "YAGNI znamená ignorovat performance a scalability"

Částečně pravda. Neoptimalizujte pro miliony uživatelů, když máte 100. Ale základní best practices (indexy v databázi, efektivní queries, rozumné cachování) jsou správné od začátku. YAGNI se vztahuje na předčasné micro-optimalizace a over-engineering pro scale, který neexistuje.

• "Pokud už vím, že funkci budeme potřebovat za měsíc, můžu ji implementovat teď"

Problematické. I když máte funkci v backlogu, implementujte ji až těsně před tím, než ji potřebujete. Za měsíc se může ukázat, že ji přece nepotřebujete, nebo že požadavky se změnily. Výjimkou jsou případy, kdy by pozdější implementace vyžadovala masivní refactoring – ale i to často signalizuje špatný design.

YAGNI v agilním vývoji

YAGNI je jedním ze základních principů Extreme Programming (XP) a proniká do všech agile metodologií. Agile Manifesto říká: "Reagovat na změnu je důležitější než následovat plán." YAGNI tento princip implementuje na úrovni kódu – když implementujete spekulativní funkce, následujete plán (předpoklady o budoucnosti) místo reakce na aktuální změny.

V Scrumu pracujete ve sprintech s konkrétními user stories. YAGNI znamená implementovat přesně to, co je ve story, ne více. Pokud story říká "uživatel může resetovat heslo emailem", neimplementujete zároveň reset přes SMS "pro jistotu". Pokud to bude potřeba, přijde jako samostatná story v dalším sprintu.

Lean software development identifikuje 7 typů waste (plýtvání). Jeden z nich je "částečně hotová práce" – kód, který je napsaný, ale nepoužívaný. To je přesně to, co YAGNI eliminuje. Každá řádka kódu má svou cenu – psaní, review, testing, maintenance. Pokud kód nepřináší hodnotu teď, je to waste.

Praktické tipy pro aplikaci YAGNI

• Ptejte se "Potřebujeme to teď?"

Při každém návrhu funkce se ptejte: Je to explicitní požadavek pro tento sprint/release? Je to blocker pro launch? Pokud ne, odložte do backlogu. Nechte produktového manažera prioritizovat.

• Používejte feature flags pro experimenty

Místo spekulativních funkcí nasaďte MVP za feature flag, získejte data o tom, zda uživatelé funkci používají, a podle toho rozhodněte o dalším vývoji. Experimentujte, nespekulujte.

• Refaktorujte, když přichází změna

Když skutečně přijde požadavek na funkci, kterou jste dříve odložili kvůli YAGNI, refaktorujte podle potřeby. Často zjistíte, že refactoring je jednodušší, než jste čekali – nebo že požadavky jsou jiné, než jste původně předpokládali.

• Používejte code review pro enforcement YAGNI

Při code review se ptejte: "Je tato abstrakce/konfigurovatelnost/obecnost skutečně potřeba pro aktuální use case?" Pokud ne, simplifikujte. Review je skvělá příležitost zachytit over-engineering.

Související pojmy