Begriff
YAGNI (You Aren't Gonna Need It)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Entwickler können gut die Zukunft vorhersagen. (Denken sie). "Wir brauchen bestimmt bald Support für chinesische Währung. Ich baue das Interface schon mal generisch." 3 Jahre später: Wir haben nur Kunden in Europa. Aber der generische Code ist da, ist kompliziert, hat Bugs und muss gewartet werden. YAGNI sagt: Baue Features erst, wenn du sie wirklich brauchst. Nicht, wenn du glaubst, dass du sie brauchen wirst.
Merksatz: Ein Prinzip des Extreme Programming (XP), das besagt, dass man Funktionalität erst implementieren soll, wenn sie tatsächlich benötigt wird, niemals vorher.
Dialog: Dev: "Ich baue ein Caching-System, falls wir mal 1 Million User haben." Senior: "Wie viele User haben wir jetzt?" Dev: "Zehn." Senior: "YAGNI. Lass das Cache weg. Bau es, wenn der Server langsam wird."
Es spart Zeit heute (weniger Code) und Zeit morgen (weniger Wartung).
1. Cost of Delay vs Cost of Carry
- Cost of Carry: Code, den du heute schreibst, aber nicht nutzt, "schleppst" du mit. Er kostet bei jedem Refactoring, bei jedem Test-Lauf. Er ist Ballast.
- YAGNI minimiert die "Cost of Carry".
- Gegenargument: Manche Dinge sind später sehr teuer einzubauen (Security, I18n). Hier gilt YAGNI evtl. nicht ("Architectural Drivers").
2. Spekulative Generalisierung
"Ich mache diese Klasse abstrakt, falls wir eine zweite Implementierung brauchen." Meistens braucht man sie nie. Und wenn doch, passt die Abstraktion von damals eh nicht auf das neue Problem. Regel: Mache es konkret. Wenn der zweite Fall kommt -> Refactor (Extract Interface). Das geht dank IDEs heute super schnell.
3. Gold Plating
Das Vergolden von Features. "Ich habe noch den Button animiert und 3 Extra-Filter eingebaut." Der Kunde wollte das nicht. Es ist Verschwendung (Lean Management: Waste). Beschränke dich auf die Requirements.
1. Die Abstraktions-Strafe
Jede Abstraktion (Interfaces, Factories, Layer), die du "auf Vorrat" einbaust, hat eine kognitive Last. Ein neuer Entwickler im Team muss 5 Klassen verstehen, um eine einfache Datenbank-Abfrage zu finden, nur weil jemand "flexibel für die Zukunft" sein wollte. YAGNI schützt den "Flow" des Teams. Wir bauen so wenig Abstraktion wie möglich, damit der Code so direkt und lesbar wie möglich bleibt. Erst wenn wir die zweite Implementierung tatsächlich programmieren, extrahieren wir das Interface.
2. YAGNI vs. Architektur-Enabler
Vorsicht: Man darf YAGNI nicht als Ausrede für schlechte Architektur nutzen. Sicherheits-Features oder Internationalisierung (Sprachunterstützung) sind oft Architectural Drivers. Wenn du ein ganzes System auf Deutsch fest verdrahtest und nach 2 Jahren nach China expandieren willst, kostet der Umbau Millionen. Das ist kein YAGNI-Fall, sondern ein Architektur-Fehler. Regel: YAGNI gilt für Features (Was macht die App?), nicht zwingend für fundamentale Qualitätsattribute (Wie stabil/sicher/skalierbar ist die App?).
3. Yak Shaving vermeiden
YAGNI ist die Rettung vor dem "Yak Shaving" (Yak rasiert man, um an Wolle zu kommen, um ein Kissen zu füllen, um gemütlich zu sitzen, während man eigentlich programmieren wollte). Oft fangen Entwickler an, ein Tool zu bauen, um ein Problem zu lösen, das sie erst in 6 Monaten haben könnten. Am Ende haben sie eine Woche lang nur das Tool optimiert, aber kein einziges Business-Problem gelöst. YAGNI erinnert dich: "Leg die Schere weg, das Yak braucht sein Fell noch!"
Quick-Check
Widerspricht das Vorausplanung?
Jein. Man soll Architektur planen (Grobes Bild). Aber keine Features auf Vorrat bauen.Zusammenhang mit Agile?
Agile sagt: "Wir wissen nicht, was in 3 Monaten ist." YAGNI ist die logische Konsequenz. Warum Code schreiben für eine Zukunft, die sich eh ändert?Verschieberitis?
YAGNI ist keine Ausrede für Faulheit ("Ich mache Error Handling später"). Error Handling braucht man jetzt. YAGNI betrifft Features: "Support für Oracle DB".