YAGNI in der App-Entwicklung: Was es ist, das Wesen des Prinzips und der praktische Nutzen

Was ist YAGNI?

YAGNI (You Aren't Gonna Need It) — ein Prinzip der extremen Programmierung (XP), das bedeutet „Du wirst es nicht brauchen“. Die Regel lautet: Implementieren Sie niemals Funktionalität, die nicht durch aktuelle User Stories gefordert wird. Wenn eine Funktion heute nicht benötigt wird — bauen Sie sie nicht ein, nicht einmal „fürs Futur“.

Der Begriff wurde von Ron Jeffries geprägt, einem der Mitautoren der XP-Methodik (zusammen mit Kent Beck). Jeffries sagte: „Implementieren Sie das Einfachste, das funktioniert, und fügen Sie nichts hinzu, bis es benötigt wird.“ YAGNI ist kein Planungsverbot, sondern ein Verbot vorzeitiger Implementierung.

Laut dem Standish Group CHAOS Report (2023) werden 64% der Funktionen in einem durchschnittlichen Softwareprodukt selten oder nie genutzt. Auf eine mobile App übertragen — mehr als die Hälfte des geschriebenen Codes bringt dem Benutzer keinen Wert. YAGNI verhindert diese Ressourcenverschwendung.

Wenden Sie YAGNI als strengen Filter an: Jede Funktion muss die Frage beantworten „Welches spezifische Benutzerproblem löst sie jetzt?“ Wenn es keine Antwort gibt — ist die Funktion nicht nötig.

YAGNI vs. Faulheit und Abkürzungen

YAGNI ist keine Ablehnung qualitativ hochwertiger Architektur. YAGNI verbietet das Schreiben von unnötigem Code, verbietet aber nicht das Schreiben von korrektem Code. Wenn eine aktuelle Funktion eine saubere Abstraktionsebene benötigt — erstellen Sie sie. Wenn die Ebene nicht benötigt wird — erstellen Sie sie nicht. Hauptunterschied: YAGNI geht es um Funktionalität, nicht um Qualität.

Entwickler verwechseln YAGNI oft mit der absichtlichen Anhäufung technischer Schulden (technische Schulden sind immer ein Kompromiss, YAGNI ist ein Effizienzprinzip). Der Unterschied besteht darin, dass technische Schulden erkannt und dokumentiert werden, während ein YAGNI-Verstoß einfach zusätzliche Arbeit ist.

Fragen Sie sich: „Wenn ich diese Abstraktion jetzt nicht erstelle, wie lange würde das Refactoring dauern, wenn sie benötigt wird?“ Wenn die Refactoring-Zeit kürzer ist als die jetzige Schreibzeit — verschieben Sie es.

Warum ist YAGNI für Mobilprojekte entscheidend?

Mobile Entwicklung ist aus drei Gründen besonders anfällig für YAGNI-Verstöße: Die APK/IPA-Größe wirkt sich direkt auf die Installationskonversionsrate aus, die Kompilierungszeit von Mobilprojekten wächst linear mit dem Codevolumen, und jede zusätzliche Funktion fügt Fehlerquellen hinzu. YAGNI geht es nicht um Faulheit, sondern um Fokus.

Eine Studie von Google Play Console Data (2023) zeigte: Jede 10 MB APK-Größe reduzieren die Installationswahrscheinlichkeit um 1,2%. Ungenutzter Code ist nicht nur Müll im Repository — es ist ein direkter finanzieller Verlust. Zusätzliche Bibliotheken (für Funktionalität, die „vielleicht später hinzugefügt wird“) sind die häufigste Ursache für APK-Aufblähung.

Laut dem Gradle Build Performance Report (2024) verlängert jedes zusätzliche Modul in einem Android-Projekt die vollständige Build-Zeit um 3–7 Sekunden. Wenn Sie 5 Module „vorsichtshalber“ hinzufügen — beträgt die Build-Zeiterhöhung 15–35 Sekunden pro Build. Über ein Jahr verliert ein Team von 5 Entwicklern bis zu 200 Arbeitsstunden durch Warten auf die Kompilierung.

Überwachen Sie die Binärgröße im CI: Setzen Sie eine Warngrenze (z. B. +500 KB pro Commit). Wenn die Größe ohne neue Funktion gestiegen ist — ist das ein YAGNI-Verstoß, der im Code Review besprochen werden muss.

YAGNI vs. Gold-Plating: Praxisbeispiele

Gold-Plating: Vorzeitige Animation

Gold-Plating — das Hinzufügen von Funktionalität über die Anforderungen hinaus, um das Produkt zu „verbessern“. Ein typisches Beispiel: Ein Entwickler fügt eine komplexe Übergangsanimation zwischen Bildschirmen hinzu, obwohl das Design einen einfachen Fade vorsieht. Die Animation dauert 2 Tage, der Benutzer bemerkt sie nicht, und Fehler auf verschiedenen Geräten verfolgen das Projekt über Jahre.

Laut dem UX Collective Annual Report (2023) bewerten 78% der Benutzer eine App nach Geschwindigkeit und Stabilität, nicht nach Animationen. YAGNI sagt: Wenn die Animation nicht in den Anforderungen spezifiziert ist — implementieren Sie sie nicht. Der Designer wird die Animation hinzufügen, wenn sie tatsächlich zur Lösung eines UX-Problems benötigt wird.

Implementieren Sie nur das, was in den Mockups steht. Wenn der Designer keine Animation gezeichnet hat — sollte es sie nicht geben. Jede Abweichung vom Mockup ist ein YAGNI-Verstoß.

Vorzeitige Lokalisierung in 20 Sprachen

Ein häufiger Startup-Fehler: Sofort Unterstützung für 20+ Sprachen „für den zukünftigen internationalen Markteintritt“ einzubauen. YAGNI empfiehlt: Lokalisieren Sie nur in die Sprache des aktuellen Marktes. Das Hinzufügen jeder neuen Sprache erfordert Übersetzerzeit, Tests auf String-Abschneidung und Debugging von RTL-Layouts.

Laut dem Deloitte Digital Globalization Survey (2022) verlassen 60% der mobilen Apps nie ihren ersten Markt. Wenn das bei Ihnen der Fall ist — sind die Ressourcen für die Mehrsprachigkeit verschwendet. YAGNI-Ansatz: Englisch (Basis) + Sprache des Zielmarktes. Andere — wenn Sie tatsächlich in eine Region eintreten.

Nutzen Sie YAGNI zur Prioritätensetzung: Wenn eine Funktion nicht im Fahrplan der nächsten zwei Quartale steht — beginnen Sie sie nicht. Der Fahrplan muss dokumentiert und vom Produktmanager genehmigt sein.

Wie wendet man YAGNI in Android und iOS an?

YAGNI in Android: Keine unnötigen Bibliotheken hinzufügen

Android-Projekte leiden unter Bibliotheksinflation. Entwickler fügen Retrofit, OkHttp, Gson, Room, Dagger Hilt, Navigation Component, DataStore hinzu — noch bevor die erste Zeile Geschäftslogik geschrieben ist. YAGNI empfiehlt: Fügen Sie Bibliotheken nach tatsächlichem Bedarf hinzu, nicht präventiv.

// YAGNI-Verstoß: Präventives Einbinden von Bibliotheken
// 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")

// Und die App zeigt nur "Hello World"

Bibliotheken sind Abhängigkeiten mit eigener Komplexität. Jede erfordert Versionsupdates, Migration bei Breaking Changes und erhöht die APK-Größe. Fügen Sie eine Bibliothek hinzu, wenn eine spezifische Aufgabe auftritt, die diese Bibliothek löst. Beginnen Sie mit OkHttp (minimaler HTTP-Client), fügen Sie Retrofit hinzu, wenn Sie einen REST-Client benötigen, und so weiter.

YAGNI in iOS: SwiftUI nicht erzwingen

SwiftUI ist ein leistungsstarkes Framework, aber seine Einführung sollte von echten Bedürfnissen getrieben sein. Wenn ein Projekt mit iOS 14+ startet und die Anforderungen an benutzerdefinierte UI-Komponenten minimal sind — ist SwiftUI eine gute Wahl. Wenn ein Projekt iOS 13 unterstützen muss oder komplexe benutzerdefinierte Gesten erfordert — bleibt UIKit die richtige Lösung. YAGNI ist gegen eine Migration zu SwiftUI „weil es trendy ist“.

// YAGNI: Verwenden Sie UIKit, solange es keinen echten Vorteil von SwiftUI gibt
class ProfileViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "Profil"
    }
}

// Wenn SwiftUI benötigt wird — integrieren Sie es über UIHostingController
let swiftUIView = ProfileView()
let hostingVC = UIHostingController(rootView: swiftUIView)

Die Analyse von Point-Free: „SwiftUI vs UIKit Decision Guide“ (2024) empfiehlt: Migrieren Sie keine bestehenden UIKit-Bildschirme zu SwiftUI ohne einen klaren geschäftlichen Grund (z. B. die Notwendigkeit von Live Preview für den Designer). Das Umschreiben von funktionierendem Code ist ein direkter YAGNI-Verstoß. SwiftUI — für neue Bildschirme, UIKit — für bestehende.

Typische Fehler bei der Befolgung von YAGNI

YAGNI als Ausrede für schlechte Architektur

Der gefährlichste Fehler ist die Verwendung von YAGNI als Ausrede für schlechte Architektur. „Wir werden keine Repository-Ebene erstellen, weil YAGNI — wir schreiben die Abfrage direkt im ViewModel.“ Das ist nicht YAGNI, das ist Anhäufung technischer Schulden. YAGNI verbietet unnötige Funktionalität, nicht architektonische Integrität.

Architektur ist eine Investition in Wartbarkeit. Wenn Sie mehr als 3 Bildschirme schreiben — ist eine grundlegende Architekturebene (MVVM, Repository) bereits gerechtfertigt. Bei 1 Bildschirm können Sie sich einen einfacheren Ansatz leisten. Der Schlüssel: Bestimmen Sie das architektonische Minimum, das für die aktuellen Funktionen erforderlich ist, und fügen Sie nicht mehr hinzu.

Teilen Sie Entscheidungen in „architektonische“ und „funktionale“ auf. Architektonische Entscheidungen (Ebenen, Navigation, DI) werden nicht von YAGNI abgedeckt — sie sind für die Wartbarkeit notwendig. Funktionale Entscheidungen (Features, Screenshots, Animationen) — werden abgedeckt.

Blindes Befolgen von YAGNI bei der Arbeit mit APIs

Ein weiteres Extrem — das Ignorieren zukünftiger API-Verträge. Ein Entwickler erhält ein JSON vom Backend mit 5 Feldern und parst nur 3, weil „die anderen laut YAGNI nicht benötigt werden“. Das Problem: Wenn ein Feld hinzugefügt wird, könnte das Backend das Parsing brechen, wenn sich die Antwort geändert hat. Die Lösung ist, alle Antwortfelder zu mappen, auch wenn nicht alle jetzt verwendet werden.

Laut den Meta API Design Guidelines (2023) muss der Client alle Felder parsen, die der Server zurückgibt, ungenutzte ignorieren, aber nicht die gesamte Struktur verwerfen. YAGNI geht es hier um etwas anderes: Fügen Sie keine Behandlung von Feldern hinzu, die noch nicht in der Spezifikation sind, „fürs Futur falls das Backend sie zurückgibt“.

Parsen Sie die gesamte Antwortstruktur (alle Felder, die der Server aktuell zurückgibt). Fügen Sie keine Behandlung von Feldern hinzu, die nicht in der aktuellen API-Spezifikation sind. Das ist eine Balance zwischen YAGNI und Widerstandsfähigkeit gegenüber Veränderungen.