Wenn einfach unnötig komplex ist (Teil 2)
Kommentare

Du wirst es nicht brauchen
Einfachheit des Codes ist eng mit YAGNI verwandt. Bei YAGNI dreht es sich vor allem darum, sich selbst davon abzuhalten, Funktionalität einzubauen, die noch gar nicht notwendig

Du wirst es nicht brauchen

Einfachheit des Codes ist eng mit YAGNI verwandt. Bei YAGNI dreht es sich vor allem darum, sich selbst davon abzuhalten, Funktionalität einzubauen, die noch gar nicht notwendig ist. Eine bestimmte Funktionalität sollten Sie nur hinzufügen, wenn es sich nicht weiter aufschieben lässt, ohne das Projekt zu gefährden. Dieses Prinzip verkündet wie das vorherige Prinzip ein Konzept, dem keine klugen Experten jemals widersprechen würden. YAGNI ist ein weiteres Stück gesunden Menschenverstands, leicht zu verstehen, doch recht komplex in der Umsetzung.

Auf den zweiten und tieferen Blick ist YAGNI sowohl gut als auch schlecht. Es ist eine sehr gute Regel, die in Projekten zu verwenden ist, da sie den Umfang der Arbeit für Testen, Debuggen, Dokumentieren auf einem absoluten Minimum hält. Dinge werden erledigt, wenn man sie tatsächlich braucht, und nicht, wenn man denkt, sie eventuell einmal brauchen zu können. Unterm Strich belasten Sie sich selbst jeden Tag mit zusätzlicher Arbeit, wenn Sie YAGNI ignorieren, ohne zu garantieren, dass sich Ihr Aufwand morgen auszahlen wird. Darüber hinaus könnte jeder zusätzliche Code, der heute unnötig ist, paradoxerweise zukünftige Erweiterungen behindern. Wenn der Code einmal da ist, lässt er sich schwer ignorieren. Akzeptiert man heute, dass ein neues Feature aufgenommen wird, könnten Ihr Chef oder der Kunde (oder beide) weitere Features vorschlagen, die sie im Produkt sehen möchten. Und dann noch eines und noch eines und so weiter und so fort.

Andererseits ist strenges YAGNI auch eine Untugend, weil es ihre Fähigkeit einschränken kann, das System später zu erweitern. Ein Feature mag heute unnötig erscheinen, könnte aber morgen schon das Produkt erheblich aufwerten. Die Vorausplanung dieses Features könnte der beste Zug für das Projekt sein und bessere Ergebnisse produzieren. Am Ende ist die Entscheidung über YAGNI recht schwierig und verlangt nach einer Bewertung durch mehrere Experten.

Den Kontext verstehen

Ich glaube fest, dass Entwickler Einfachheit effektiv erkennen und implementieren würden, wenn nur ihre Sinne nicht durch die Furcht vor fehlender Erweiterbarkeit vernebelt wären. Anders ausgedrückt scheitern Entwickler oftmals aufgrund von YAGNI, das einfachste Ding zu kodieren, das möglicherweise funktionieren könnte. Verfolgt man den Gedanken, das System erweiterbar und leicht wartbar zu halten, verfehlen Entwickler eventuell das eigentliche Ziel der Software und produzieren etwas, das mit unnötiger Komplexität angereichert und gerade deswegen wesentlich fehleranfälliger ist. Ich müsste Tests ausführen, aber nicht einfach Komponententests. Ich würde funktionale und Integrationstests mit realen Daten benötigen. Diese Stufe der Codeabdeckung zu erreichen, erhöht den Aufwand und das Risiko, dass sich überall Fehler einschleichen.

Der entscheidende Punkt, sowohl Einfachheit als auch YAGNI anzugehen, ist ein ganz anderer. Genauer gesagt geht es darum, ein möglichst umfassendes Verständnis für den Kontext und den Problemraum zu entwickeln. Um die einfachste mögliche funktionsfähige Lösung zu erhalten, müssen Sie sich auf Features konzentrieren, die ausdrücklich angefordert wurden. Ist ein Feature nicht ausdrücklich angefordert worden, müssen Sie sich fragen, ob Sie überhaupt genügend darüber wissen. Und mehr noch, sind Sie sicher, dass der Kunde (oder wer auch immer es vorgeschlagen hat) genügend darüber weiß?

Um Features mit hoher Priorität zu entwerfen und zu kodieren, müssen Sie sicherstellen, dass Sie sie richtig erfasst haben. Dieser entscheidende Punkt wird oftmals übersehen. Als Softwarearchitekt werden Sie sehr selten damit beauftragt, ein System in einer Domäne zu entwerfen, die Sie gut und bequem beherrschen. Das kann möglicherweise passieren, nachdem Sie eine langjährige Karriere hinter sich haben oder wenn Sie Teil eines internen Entwicklungsteams sind. Höchstwahrscheinlich jedoch spezialisieren Sie sich im Softwareentwurf und lassen sich am liebsten anheuern, um Softwaresysteme zu erstellen – gleich welcher Art.

Sie müssen sich über jedes einzelne Feature sicher sein, das Sie entwerfen. Die Rolle des Architekten besteht darin, die Features zu verstehen und sie in einer (halb-)formalen Art und Weise auszudrücken. Wenn es an Kenntnissen oder Kommunikation mangelt, kann das Projekt nur scheitern. In XP geht es um das Zusammenwirken zwischen Kunden und Teams. Beide Parteien sollten sich gegenseitig versichern, dass sie die Zielstellung verstanden haben – das ist der einzige vernünftige und sichere Weg, um kontinuierlich und erfolgreich bis zum Ende des Projekts fortzufahren. Wenn Sie sich als Entwickler oder Architekt über die internen Mechanismen eines gegebenen Prozesses nicht sicher sind, fragen Sie. Als Auftraggeber versichern Sie sich, ob das, was Sie erhalten (und wofür Sie letztlich bezahlen), genau mit Ihren Erwartungen übereinstimmt. Verstehen ist also der Schlüssel und zieht die Grenze zwischen einer einfachen und einer simplen Lösung.

So weit, so gut. Doch gibt es irgendeine besondere Empfehlung, wie das durchzusetzen ist und wie sich solche wundervollen Konzepte der eigentlichen Zielgruppe vermitteln lassen? Es gibt einige Methodologien, die Ihnen dabei helfen. Diesen Methodologien ist ein nachgestelltes Doppel-D gemeinsam, das für „Driven Design“ (getriebener Entwurf) steht. Wir können sie als xDD bezeichnen, wobei das x für Verantwortlichkeit (Responsibility), Domäne (Domain) oder Verhalten (Behaviour) steht. In den folgenden Kolumnen gebe ich Ihnen eine Kurzfassung (in dem für diese Kolumne verfügbaren Platz) zu verantwortlichkeitsgetriebenem, verhaltensgetriebenem und domänengetriebenem Entwurf.

Dino Esposito ist R&D Director bei Crionet, einer Firma, die sich auf webbasierte Lösungen für Sportereignisse in ganz Europa spezialisiert hat (http://www.e-tennis.net). Außerdem ist Dino der Autor von „Programming ASP.NET MVC“, Microsoft Press, 2010.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -