You Ain't Gonna Need It (YAGNI)

You Ain’t Gonna Need It (YAGNI) – Wissenshäppchen #2

Dieser Beitrag ist Teil 2 von 3 in der Serie Wissenshäppchen.

In der zweiten Episode meiner „Wissenshäppchen“ geht es um ein weiteres wichtiges Prinzip der Softwareentwicklung: You Ain’t Gonna Need It (YAGNI) (alternativ auch You Aren’t Gonna Need It). Wir sollten immer nur das entwickeln, was wir wirklich brauchen!

Always implement things when you actually need them, never when you just foresee that you need them. (YouArentGonnaNeedIt)

Probeabo bei Audible (Affiliate)

Inhalt

  • Durch den Fokus auf das wirklich Wichtige vermeiden wir unnötige Komplexität (vgl. SimpleBeanFactoryAwareAspectInstanceFactory) in unserem Code, die zu schlechterer Wartbarkeit führt.
  • Außerdem widmen wir damit den Großteil unserer wertvollen Arbeitszeit der Lösung des eigentlichen Problems.
  • Das bedeutet nicht, dass wir absichtlich zu einfache Lösungen bauen sollen.
  • Wir sollten nur keine Features einbauen, von denen wir lediglich glauben, dass wir sie später einmal brauchen (bzw. der Fachbereich sie gerne hätte).
  • Die Praktik des Test Driven Development forciert YAGNI, da immer nur der produktive Code geschrieben wird, der den nächsten Testfall grün macht.
  • Anforderungen bzgl. der Architektur unserer Anwendung, Sicherheit oder Benutzerfreundlichkeit können nicht im Nachhinein eingebaut werden und müssen daher schon von Beginn des Projekts an eingeplant werden.
  • Durch YAGNI kann Featuritis vermieden werden, das Problem, dass immer mehr Features hinzugefügt werden, anstatt die wirklich gewünschten perfekt umzusetzen.
  • Auch das Problem der voreiligen Optimierung (Premature Optimization) steht im Zusammenhang mit YAGNI. Meistens optimiert man Kleinigkeiten, die im Verhältnis zum großen Ganzen kaum Auswirkungen haben.
  • Ein weiterer Begriff, der mit YAGNI in Verbindung gebracht werden kann, ist das Yak Shaving. „Nur noch eben schnell meinen eigenen ORM programmieren und dann kann es weitergehen!“

Literaturempfehlungen

YAGNI wird oft im Kontext von Extreme Programming zitiert. Kent Beck hat dazu das Standardwerk Extreme Programming Explained* geschrieben, das ich jedem Anwendungsentwickler wärmstens empfehlen kann. Auch der Sinn von Praktiken wie TDD und Pair Programming und Werten wie Einfachheit und Feedback wird hier detailliert beschrieben.

Extreme Programming Explained: Embrace Change (Affiliate)*

Links

Probeabo bei Audible (Affiliate)

Navigation der Serie<< Don’t Repeat Yourself (DRY) – Wissenshäppchen #1Single Responsibility Principle (SRP) – Wissenshäppchen #3 >>

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax