YAGNI meint „You Ain’t Gonna Need It“, auf deutsch: „Du wirst es nicht brauchen„. Der Begriff kommt aus dem Extreme Programming. Es beschreibt den Grundgedanken, dass Code erst dann zu entwickeln ist, wenn man ihn wirklich braucht, und nicht schon vorher.
Bei einem Feature ist es sehr einfach: Hat der Kunde dieses Feature in Auftrag gegeben? Der LessCoder lässt unbeirrt alle Features, die der Kunde nicht explizit wünscht, beiseite und schreibt somit weniger Code.
So weit so gut.
Eventuell sorgen ungenaue oder unklare Anforderungen dazu, dass der Implementierer diese trotzdem versucht irgendwie umzusetzen. Entweder er hat Glück und trifft den Nagel auf den Kopf. Oder er liegt falsch und baut ein Feature, das niemals gebraucht wird. Oder er entwickelt eine Vielzahl von Features, in der Hoffnung, dass schon das richtige dabei sein wird. Das ist natürlich der falsche Ansatz. Der LessCoder dagegen fragt den ProductOwner so lange, bis er eine Antwort bekommt. Wenn er nach mehreren Versuchen keine bekommt, ist davon auszugehen, dass es dem ProductOwner wohl nicht wichtig genug war oder er hat selbst noch nicht genau verstanden was er will. Ein klarer Fall von „YAGNI“.
Es gibt aber auch – meist nichfunktionalen – Code, den man, oft aus aus Gründen der langfristigen Wartbarkeit, gerne implementiert haben möchte, der möglicherweise aber schlicht und einfach jetzt noch unnötig ist.
Meist handelt es sich um generischen Code, der hilft, eine bestimmte Art von Problem zu lösen, obwohl es momentan genau ein konkretes Problem dieser Art gibt.
Als einfaches Beispiel soll eine Datei von einem Webserver geladen, irgendwie verarbeitet und wieder zurückgeschrieben werden. Es lässt sich sicherlich eine ganze Menge generischen Codes entwickeln, der Daten lädt, verarbeitet und zurückschreibt, und weiteren Code, der im Kontext dieses generisch Kontrukts arbeitet und Daten eben wie gewünscht von einem WebServer lädt, verarbeitet und zurückschreibt.
Meiner Erfahrung nach ist die magische Zahl, bei der es sich lohnt, eine bestimmte Problemart generisch zu lösen frühestens zwei, manchmal erst bei drei oder vier. Denn solange man eine Art von Problem nur einmal zu lösen hat,
- bringt einem die generische Lösung nichts, solange es kein zweites Problem derselben Art gibt und
- man kennt nur eine einzige Instanz eines Problems und meint, daraus eine ganze Klasse von Problemen identifiziert zu haben, für die man nun sofort eine allgemeine Lösung schaffen will.
Für den LessCoder heisst die Kenntnis von YAGNI normalerweise, dass er sich durch nichts aus der Ruhe bringen lässt, auch dann nicht, wenn der normale Coder grübelt, ob er denn nun schon eine Problemart generalisieren soll oder nicht. Der LessCoder schreibt anfangs nur konkreten Code, evtl. auch noch beim zweiten Problem dieser Art. Charmant dabei ist, dass er damit sofort am Ziel ist, und der Kunde glücklich.
Erst dann, wenn er die Problemdomäne gut genug verstanden hat, und vom Kunden das nächste Mal eine Problemlösung derselben Art gefordert ist, fängt er an zu generalisieren. Dabei baut der konkreten Code so um, dass er sich ebenfalls des neuen generischen Konstrukts bedient. Dank Tests ist er sich sicher, dass die alte konkrete Lösung immer noch funktioniert.
Es gibt aber auch noch eine andere Möglichkeit, darauf zu reagieren: Es sollte nämlich nie so weit kommen, dass der Kunde sich aus heiterem Himmel fragt, warum die dritte Problemlösung so lange auf sich warten lässt (da der LessCoder erst jetzt generalisiert).
Darum ist es unter Umständen wichtig, dass man den Kunden von vornherein fragt, ob er sein Problem generisch gelöst haben möchte, oder erst einmal konkret. Der Kunde denkt vermutlich an grandiose Folgereleases, in der es viele Probleme dieser Art geben wird, und wird für die Generalisierung sein. Aber gleich danach denkt er auch an sein Budget.
Vermutlich wird er sich von der Wahrscheinlichkeit leiten lassen, von der er meint, dass er diese Problemkategorie künftig wieder haben wird. Die Wahrscheinlichkeit kann er jedoch besser bestimmen als man selbst, somit hat man zu Recht dem Kunden die Entscheidung überlassen, wie generisch eine Problemart von Anfang an zu lösen ist. Gerade in agilen Projekten, bei denen das (Test-)Userfeedback die weiteren Features bestimmt, dürfte der Kunde selbst schnell unsicher werden. Hier sollte ihm der LessCoder mit YAGNI weiterhelfen: „Lieber Kunde, du wirst es (vorerst) nicht brauchen.“
Ganz generell kann man sagen, dass sich der LessCoder im Zweifel gegen den Aufwand entscheidet.
