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) TL;DR Beim
Entwickeln konzentriere ich mich mit YAGNI ("You ain’t gonna need
it") auf das, wofür es konkrete Anforderungen gibt. Zusätzliche
Features und vorsorgliche Abstraktionsschichten kosten Zeit und
erschweren es dir, den Code zu verstehen und zu erweitern. Welche
Architektur dein Projekt braucht, hängt von seinen Anforderungen
ab; Sicherheit und Benutzerfreundlichkeit gehören früh in deine
Planung. Test Driven Development hilft dir, gezielt das geforderte
Verhalten umzusetzen, während voreilige Performance-Arbeit und
aufwendige Nebenaufgaben Zeit verschlingen. Kapitelmarken
[00:00:00] Einstieg ins YAGNI-Prinzip [00:00:38] Bedeutung und
Anwendung von YAGNI [00:01:49] Zusätzliche Abstraktionen und
komplexe Architektur [00:03:16] Java-Beispiele mit Factories und
Providern [00:05:49] Projektabhängige Anforderungen und
Datenbankabstraktion [00:07:21] Wünsche des Fachbereichs
hinterfragen [00:07:59] Sicherheit und Benutzerfreundlichkeit früh
einplanen [00:09:06] Featuritis und Feature Creep [00:09:47] YAGNI
mit Test Driven Development umsetzen [00:10:40] Premature
Optimization und Laufzeitprobleme [00:12:26] Yak Shaving und
aufwendige Nebenaufgaben [00:13:57] Rückblick auf YAGNI [00:14:30]
Extreme Programming und Literaturempfehlung [00:15:07] Shownotes
und weiterführende Links 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. * Links
YAGNI (hier sind auch zwei treffende Bilder aus dem
Software-Craftsmanship-Kalender zu sehen) What are the most
ridiculous Java class names from real code? How To Build A Horse
With Programming [Comic] Feature creep Premature Optimization yak
shaving Zusammenfassung YAGNI im Entwicklungsalltag Wenn ich beim
Programmieren Ideen für weitere Features bekomme, hilft mir YAGNI,
bei den konkreten Anforderungen zu bleiben. Die Abkürzung steht für
"You ain’t gonna need it", auf Deutsch ungefähr "Du wirst es nicht
brauchen". Das Prinzip stammt aus dem Extreme Programming. Du setzt
damit das um, was der Fachbereich oder du selbst aktuell braucht.
Für zusätzliche Features entstehen Kosten, auch wenn ihr Bedarf
ungeklärt ist. YAGNI betrifft ebenso einzelne Methoden und die
Architektur deiner Software. Wie zusätzliche Architektur den Code
erschwert Eine weitere Abstraktionsschicht kann Aufwand
verursachen, sobald du den Code wartest oder erweiterst. Wer eine
Funktion ergänzen möchte, muss zunächst verstehen, wie die
vorhandenen Schichten zusammenspielen. Als IT-Azubi brauchst du
dafür Zeit, besonders wenn dir die Ideen hinter der Architektur
noch fehlen. Als Beispiel greife ich die Spring-Klasse
SimpleBeanFactoryAwareAspectInstanceFactory auf. Ihr Name enthält
zweimal "Factory" und regt dazu an, über den Umfang von
Abstraktionen nachzudenken. Die Aufgabe dieser Klasse kenne ich
selbst nicht. Dazu passt ein Comic, in dem beim Programmieren eines
Pferdes mit Java zunächst eine Pferdefabrik entsteht. Bei einer
kleinen Änderung an einer Java-REST-Schnittstelle musste ich selbst
zuerst einen Provider samt Factory bauen. Die Architektur machte es
aufwendig, die Funktion hinzuzufügen. Ob die vorhandenen
Abstraktionen im jeweiligen Projekt gerechtfertigt sind, hängt von
dessen Anforderungen ab. Welche Architektur dein Projekt braucht
Bevor du eine Schicht zum Austausch der Datenbank einbaust, prüfst
du, ob dein Projekt diese Fähigkeit braucht. Für ein Framework, das
Kund:innen mit verschiedenen Datenbanken einsetzen, gehört sie zu
den konkreten Anforderungen. Bei meiner eigenen kleinen
Webanwendung mit dauerhaft eingesetztem MySQL oder MariaDB wäre ein
selbst gebauter objektrelationaler Mapper zusätzlicher Aufwand ohne
absehbaren Bedarf. Auch ein komplexes Problem kann eine
entsprechend komplexe Architektur erfordern. Bereits bekannte
architektonische Anforderungen gehören früh in deine Planung, wenn
sie sich später schwer ändern lassen. Sicherheit und
Benutzerfreundlichkeit musst du von Anfang an berücksichtigen. Eine
fertige Windows-Forms-Anwendung lässt sich am Projektende nur
schwer durch eine:n UX-Expert:in benutzerfreundlich machen. Ebenso
müssen erforderliche Sicherheitsmechanismen bereits beim Entwickeln
einzelner Funktionen einfließen. Anforderungen mit dem Fachbereich
prüfen Bevor du ein selbst ausgedachtes Feature programmierst,
fragst du den Fachbereich nach seinem Bedarf. Auch Anforderungen
aus einem Pflichtenheft verdienen einen prüfenden Blick: Manche
Wünsche entstehen, ohne dass jemand die Funktion später braucht.
Als Softwareentwickler:in bringst du dein Fachwissen in diese
Gespräche ein. Kund:innen können technische Fragen und deren Folgen
teilweise schwer einschätzen. Unter Featuritis oder Feature Creep
versteht man, dass immer weitere Features in die Software gelangen.
Zusätzliche Wünsche des Fachbereichs können dazu beitragen, ebenso
wie weitere Interfaces oder Factories, die Entwickler:innen
einbauen. Mit TDD bei der Anforderung bleiben Beim Test Driven
Development (TDD) beschreibt ein Test das gewünschte Verhalten
deiner Software. Im Zyklus Red, Green, Refactor schreibst du
Produktivcode, der einen fehlschlagenden Test erfolgreich macht.
Dafür wählst du die einfachste passende Lösung. So richtest du
deine Arbeit auf eine konkrete Anforderung aus. Ein eigenes
Framework zur Datenbankabstraktion würde zusätzlichen Aufwand
verursachen, wenn der Test bereits mit einer einfachen Lösung
erfolgreich läuft. Voreilig an der Performance arbeiten Premature
Optimization bezeichnet das voreilige Optimieren von Code. Wenn du
etwa Schleifen austauschst oder Java-Streams einsetzt, weil du dir
davon mehr Geschwindigkeit versprichst, kann der Effekt für die
Laufzeit kaum spürbar sein. Bei Anwendungen mit Schnittstellen kann
die Latenz durch Netzwerkzugriffe wesentlich stärker ins Gewicht
fallen. Auch die gewählte Schnittstelle beeinflusst die Laufzeit.
Änderungen an kleinen Codeabschnitten binden dann Zeit, obwohl das
vermutete Problem an anderer Stelle liegt. Yak Shaving: aufwendige
Nebenaufgaben Mit Yak Shaving sind Arbeiten gemeint, die viel Zeit
kosten und das eigentliche Feature kaum voranbringen. Mein Beispiel
ist ein selbst entwickelter objektrelationaler Mapper für eine
Aufgabe, die sich bereits mit einer sicheren und performanten
SQL-Abfrage lösen ließe. Ein kleines Framework zu bauen kann Spaß
machen. Im Projekt kostet es jedoch Zeit, während die benötigte
Funktion liegen bleibt. Meine Literaturempfehlung Zu YAGNI empfehle
ich dir "Extreme Programming Explained" von Kent Beck. Das Buch
behandelt auch Test Driven Development und Pair Programming. Den
Buchverweis sowie die Links zur genannten Java-Klasse und zum Comic
findest du in meinen Shownotes unter
anwendungsentwicklerpodcast.de/WH2. Transkription der gesamten
Episode Automatisch erzeugte Transkription der Episode [0:00]
Herzlich willkommen zu den Wissenshäppchen beim
Anwendungsentwickler-Podcast. In dieser [0:08] Episode geht es um
das Jagni-Prinzip. You ain't gonna need it. Viel Spaß. [0:14] Hallo
und herzlich willkommen zur zweiten Episode der Wissenshäppchen
beim Anwendungsentwickler-Podcast. [0:27] Mein Name ist Stefan
Macke und heute habe ich nach der ersten Episode, in der es um das
DRY-Prinzip, [0:33] Don't Repeat Yourself, ging, ein zweites
wichtiges Prinzip der Softwareentwicklung mitgebracht und [0:38]
zwar Jagni. You ain't gonna need it oder auch wahlweise you aren't
gonna need it, je nachdem, [0:45] wer das gerade schreibt bzw. wer,
ja, wie viel Slang in seiner Sprache so unterbringt. Also, [0:51]
you ain't gonna need it, you aren't gonna need it, ganz egal, auf
Deutsch heißt es ungefähr, [0:55] du wirst es nicht brauchen. Und
genau darum geht es auch. Wir wollen bei der Softwareentwicklung
[1:00] nichts programmieren, was wir nicht brauchen. Jetzt könnte
man auf die Idee kommen, ja, [1:04] das macht ja wohl keiner, warum
sollte ich denn was bauen, was keiner braucht? Aber das passiert
...
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.