YAGNI-Prinzip
Inhaltsverzeichnis: Definition – Gründe für die Abweichung – Einfache Lösung gesucht – Faktoren – Vorteile – Hinweise
Wissen kompakt: Das YAGNI-Prinzip fordert, spekulative Programmierung zu unterlassen und Features nur dann zu implementieren, wenn sie wirklich benötigt werden. YAGNI steht für You Ain’t Gonna Need It.
YAGNI-Prinzip – Implementiere nur wirklich benötigte Features
YAGNI ist ein Akronym und steht für “You Ain’t Gonna Need It”, also “Du wirst es nicht benötigen”. Es adressiert Entwickler, die gerne vorausdenken und zusätzliche Funktionen programmieren, in der Annahme, diese zu einem späteren Zeitpunkt zu benötigen.
Das YAGNI-Prinzip ist im Kontext des Extreme Programming (XP) entstanden und ist ein Prinzip von Clean Code. Es fordert, diese häufig gelebte Praxis zu unterbinden und lediglich die Features zu implementieren, die konkret benötigt, besprochen oder beauftragt wurden.
Gründe für die Abweichung vom YAGNI-Prinzip
Es gibt eine Reihe von Gründen, warum Entwickler Features implementieren, die heute noch nicht benötigt werden. Eine Ursache für die Abweichung von YAGNI liegt im Requirements Engineering bzw. im Anforderungsmanagement. Je besser das Anforderungsmanagement funktioniert, desto weniger Aufwände entstehen aufgrund von Unklarkeit, Unvollständigkeit oder Interpretation. Ansonsten kann leicht folgendes passieren:
- Entwickler interpretieren Anforderungen und implementieren mehr als konkret gefordert wird. Evtl. fehlen auch Anforderungen oder Anforderungen sind ungenau beschrieben, so dass Entwickler situativ entscheiden, welche Features noch implementiert werden müssen.
- Um zukünftige Anforderungen möglichst einfach umsetzen zu können, werden Features möglichst generisch implementiert. Gerade in einem volatilen Umfeld mit sich häufig ändernden oder neuen Anforderungen ist dies regelmäßig zu beobachten. Flexibilität ist hier das Stichwort.
Es gibt auch eine Reihe von weiteren Gründen, die zur Abweichung vom YAGNI-Prinzip beitragen:
- Entwickler wollen den Auftraggeber mit Funktionalität überraschen, die er nicht erwartet. Dies wird auch als Gold Plating bezeichnet.
- Entwickler haben Zeit, die ihnen in der Zukunft vielleicht fehlen wird.
- Entwickler haben Spaß daran, eine Architektur zu entwerfen, die für gedachte, zukünftige Anforderungen gewappnet ist.
- Entwickler erhoffen sich Vorteile bspw. beim Testing oder beim Continuous Delivery.
Einfache Lösung gesucht: YAGNI- und das KISS-Prinzip kombiniert
Das YAGNI-Prinzip und das KISS-Prinzip ergänzen sich. Das KISS-Prinzip – Keep It Simple and Stupid – sucht nach einer möglichst einfachen Lösung zu einer Aufgabenstellung. “Kompliziert kann jeder”, aber die Kunst liegt in der Einfachheit einer Lösung. Das YAGNI-Prinzip ergänzt KISS, in dem es die Frage “brauchen wir dies wirklich” stellt, und damit die Antwort in Richtung der Vermeidung von Aufwänden lenkt. So kann es bspw. sein, dass
- keine Pattern implementiert,
- keine Bibliotheken benutzt und
- keine Deployment Prozesse automatisiert
werden.
Nichtsdestotrotz kann es natürlich Sinn ergeben, eine Frage nach “brauchen wir das wirklich” auch mit “ja” zu beantworten. Dies sollte idealerweise im Zuge einer gemeinsamen Abstimmung bspw. mit dem Team, dem Product Owner, dem Projektleiter, dem Produktmanager und ggf. auch mit dem Auftraggeber besprochen und vereinbart werden. Und natürlich passiert es auch regelmäßig, dass Entwicklungsteams im Laufe einer Entwicklung schlauer werden und sich sagen, “hätten wir es damals anders gemacht, würde es heute schneller und leichter funktionieren”. Die Folge können Aufwände und Kosten im Form eines Refactorings sein. Dies kann allerdings niemals eine Aufforderung sein, Features auf “Verdacht” zu implementieren.
Faktoren beim YAGNI-Prinzip
Welche Faktoren bzw. Fragen gibt es im Zuge des YAGNI-Prinzips, die Entwickler bei der richtigen Entscheidung unterstützen? Hier eine Auswahl:
- Ist es 100% sicher, dass die Implementierung benötigt wird?
- Wie hoch sind die Investitionskosten?
- Wie lange dauert die Implementierung?
- Welche Opportunitätskosten entstehen?
Oftmals lassen sich solche Fragen nicht unmittelbar beantworten. Das liegt u. a. daran, dass Aussagen über die Zukunft grundsätzlich schwierig sind und sich nicht leicht quantifizieren lassen. Auch aus diesem Grund ergibt es Sinn, sich mit Kollegen abzustimmen und gemeinsam eine gute Entscheidung zu treffen. In agilen Entwicklungen bietet sich bspw. das Sprint Planning 2 dafür an.
Vorteile beim YAGNI-Prinzip
Werden nur diejenigen Anforderungen umgesetzt, die eindeutig implementiert werden müssen, ergeben sich einige Vorteile:
- Ein Feature Creep wird vermieden.
- Es entsteht keine Bloatware, also Software mit Funktionen, die kaum oder gar nicht genutzt werden.
- Nicht implementiere Funktionen müssen nicht getestet, dokumentiert und supportet werden. Somit entsteht kein (unnötiger) Aufwand.
- Der Ertrag steigt, denn der Aufwand für die Implementierung scheinbar benötigter Funktionen entfällt.
- Die Codebasis bleibt “schlanker” und ist damit leichter zu pflegen.
Hinweise:
Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.
Wir suchen Softwareentwickler. Berufseinsteigerinnen, Entwickler mit einigen und Expertinnen mit vielen Jahren Erfahrung.
Bei der Verwendung des YAGNI-Prinzips bietet sich die Kombination mit anderen Prinzipien und Techniken wie Refactoring, automatisiertes Testing und Continuous Integration zu verwenden.
YAGNI wird auch als ein Prinzip bei der Implementierung von Clean Code empfohlen.
Hier finden Sie ergänzende Informationen aus unserem t2informatik Blog:
Der beste Prozess im Anforderungsmanagement
Faktoren der Softwareakzeptanz
Dokumentation im Code – Pro und Contra