Die Implementierung von Clean Code

Sehr viele Softwareprojekte leiden unter einem exponentiellen Anstieg der Kosten. Über die Jahre wird es immer aufwendiger, neue Features in der bestehenden Codebasis zu implementieren. Aufgrund der Größe ist Neuschreiben keine Alternative. Die Software macht so immer mehr Schwierigkeiten in den Bereichen Korrektheit und Wandelbarkeit. Da keine oder deutlich zu wenig automatisierte Tests vorhanden sind, bleiben bei Änderungen Fehler unentdeckt, die Korrektheit der Software verschlechtert sich. Da die Strukturen sehr kompliziert, Methoden und Klassen zu lang und Verantwortlichkeiten vermischt sind und noch vieles andere im Argen liegt, ist auch die Wandelbarkeit nicht gegeben. Code, den keiner versteht, kann man nur schwer verändern. Gleichzeitig geht damit einher, dass Entwickler sich nicht imstande sehen, solchen Code nachträglich zu testen.

Aus dieser Beobachtung sollten wir als Entwickler etwas lernen: machen wir es besser von Anfang an richtig! Allerdings liegt in dieser Erkenntnis allein noch nicht die Lösung. Es bleibt die Frage: was bedeutet das denn, es richtig zu machen? Wie vermeiden wir einen exponentiellen Anstieg des Aufwands?

Prinzipien der professionellen Softwareentwicklung

Ende 2008 habe ich mich als Mitinitiator der Clean Code Developer Initiative mit der Frage befasst, welche Prinzipien und Praktiken zur Professionalisierung der Softwareentwicklung beitragen könnten. Wir haben dort über 40 Prinzipien und Praktiken zusammengetragen, wie etwa das Don’t Repeat Yourself (DRY) Prinzip oder die Test-first Praktik. Ferner haben wir vier Werte identifiziert:

• Korrektheit,
• Wandelbarkeit,
• Produktionseffizienz und
• kontinuierliche Verbesserung.

Das alles ist wichtig und richtig, doch hilft es Entwicklern nicht aus der Misere.

Das tagtägliche Grauen

Einem Entwickler zu erklären, dass eine Funktionseinheit nur eine Verantwortlichkeit haben darf, ist das eine. Ihn zu befähigen, dieses Prinzip wirklich in jedem Moment einzuhalten, ist eine andere Sache. Und die Erkenntnis aus über 10 Jahren Clean Code Developer Initiative lautet: allein auf der Ebene von Quellcode wird das Problem nicht gelöst. Die SOLID Prinzipien führen eben leider nicht zu deutlich besseren Verhältnissen. Natürlich kann entweder beim Codieren oder im Anschluss durch Refactoring einiges verbessert werden. Doch den wirklichen Durchbruch erreichen Teams oder einzelne Entwickler erst, wenn sie vor dem Codieren die Lösung entwerfen. Es muss wieder nachgedacht werden!

Ob es an der Empfehlung der Agilitätsbewegung liegt, kein Big Design Upfront durchzuführen, oder daran, dass UML für den Entwurf nicht geeignet ist, lässt sich nicht abschließend klären. Fakt ist: Entwickler entwerfen ihre Lösung nicht vor der Codierung. Kaum wurde über die Anforderungen gesprochen, geht schon der Konsolendeckel auf, die IDE wird gestartet und loscodiert. Und glauben Sie mir, ich sehe in meinem Trainer- und Berateralltag tagtäglich das Grauen!

Die lieben Anforderungen

Die oberen Ebenen Bounded Context und Anwendung lassen wir hier außen vor, da sie nur in wirklich großen Systemen relevant sind. Innerhalb einer Anwendung lässt sich jede Anforderung einem Dialog zuordnen. Das liegt daran, dass Anwender mit der Anwendung interagieren müssen. Erst dadurch, dass ein Anwender einen Menüpunkt auswählt, eine Schaltfläche betätigt, etc. entsteht die Notwendigkeit, Domänenlogik zu programmieren. Und jede solche Interaktion findet in einem Dialog statt.

Stellen Sie sich einen Dialog als ein Fenster oder Formular vor. In einem solchen Dialog gibt es häufig mehrere Möglichkeiten der Interaktion. Daher gliedern sich damit die Anforderungen sehr anschaulich in immer kleinere Einheiten. Wir können alle Anforderungen einer Anwendung betrachten, nur die Anforderungen eines Dialogs, oder sogar nur die Anforderungen einer einzelnen Interaktion.

Das Feature

Der Entwurf

Der nächste Schritt besteht darin, eine einzelne Anforderung auszuwählen, um diese dann in der Folge detailliert zu entwerfen und zu implementieren. Bei der Verfeinerung des Entwurfs in die Tiefe geht es jetzt darum, eine konkrete Lösung für das Problem zu finden. Das Ergebnis soll so detailliert sein, dass eine Implementation leicht möglich ist. Das bedeutet, die einzelnen zu implementierenden Methoden müssen gefunden werden. Nur so ist sichergestellt, dass Aspekte tatsächlich getrennt werden. Und nur so ist es möglich, zu entscheiden, welche Methoden aufgrund hoher Kohäsion zusammengefasst werden bzw. welche Methoden in unterschiedlichen Dateien oder Klassen untergebracht werden. Wir lassen uns also nicht mehr vom Code überraschen und führen dann Refactorings durch, sondern wir denken zuerst über die Lösung nach, bevor wir sie implementieren. Die nächste Abbildung zeigt eine Verfeinerung der Interaktion „Start“.

Fazit

Nach über 10 Jahren Clean Code Developer Initiative kann ich ganz eindeutig feststellen, dass die Prinzipien und Praktiken der professionellen Softwareentwicklung allein nicht genügen, um Clean Code zu implementieren. Es braucht die systematische Zerlegung von Anforderungen sowie deren Entwurf. Ich nutze dafür ein leicht anzuwendenden Entwicklungsprozess: Flow Design. Er ist erprobt, lässt sich schnell erlernen und ist leicht zu verstehen. Und: Sie haben ihn bereits in meinen Abbildungen in Anwendung erlebt. Ein Cheatsheet zum Herunterladen finden Sie unter https://flow-design.info.

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Weitere Informationen, Beiträge, Buchtipps finden Sie auf der Website von Stefan Lieser.

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.