Blau und Weiß - Die unterschiedlichen Grade des Clean Code Development

Im letzten Teil unserer Blogserie schließen wir den Lernzyklus zum Thema Clean Code Development, also der Entwicklung von sauberem, leicht lesbarem, einfach zu erweiterndem sowie schnell zu wartendem Code, ab. Die bisher erschienenen Blogbeiträge behandelten die Grundlagen des Clean Code Development und zeigten, worauf die unterschiedlichen Grade der sauberen Softwareentwicklung Wert legen.

Die unterschiedlichen Grade des Clean Code Development

Diesmal im Fokus: Der 5. Grad der sauberen Softwareentwicklung – auch als Blau bekannt. Insgesamt gibt es 5 Entwicklungsstufen, die farblich markiert sind. Stufe 1 ist als rot gekennzeichnet und Stufe 2 als orange. Die Farben gelb, grün und blau charakterisieren die weiteren 3 Abschnitte.

Zusätzlich zu diesen 5 Stufen gibt es noch einen weiteren Grad, der die Entwicklung im Rahmen des Clean Code Development abrundet: Der weiße Grad. Dieser Grad dient vor allem der Reflexion und symbolisiert den Anfang und das Ende der Entwicklung von sauberem Code.

An dieser Stelle gilt es noch festzuhalten, dass die Grade keinen Wert ausdrücken. Personen, die am blauen Grad arbeiten sind nicht „besser“ als Entwicklerinnen oder Entwickler, die sich gerade im gelben Grad befinden. Die Entwicklungsstufen dienen lediglich dazu, die Gesamtheit des Wertesystems sowie der Prinzipien und Praktiken in einzelne, leicht verdaubare Lernabschnitte zu unterteilen. Die unterschiedlichen Grade des Clean Code Development werden zudem immer wieder durchlaufen, um einen kontinuierlichen Lernprozess zu ermöglichen.

Grad Nummer 5: Blau

Beim blauen Grad stehen auch Aspekte der Softwareentwicklung jenseits von Code und Tools im Vordergrund. Entwicklerinnen und Entwickler sollen nicht nur gute Strukturen im Kleinen aufbauen, sondern diese auch von vornherein im Großen planen. Damit ist die Softwarearchitektur gemeint, die durch nachfolgende Prinzipien und Praktiken unterstützt wird:

Prinzipien

Design and Implementation Don’t Overlapp: Ein häufiges Problem im Rahmen der Softwareentwicklung sind Implementationen, denen eine vorausgegangene Planung nicht mehr anzusehen ist. Idealerweise sollten derartige Inkonsistenzen durch die Trennung der Zuständigkeiten zwischen Entwurf bzw. Architektur und Implementierung minimiert werden.

Implementation Reflects Design: Die Implementation sollte nicht unabhängig von Entwurf bzw. Architektur existieren. Komponenten, die beispielsweise in der Architektur definiert wurden, sollten deshalb im Code physisch getrennt werden.

You Ain’t Gonna Need It (YAGNI): Ist eine bestimmte Funktionalität wirklich notwendig? Oft sind Anforderungen für Features noch zu ungenau oder stellen sich im weiteren Entwicklungsverlauf als unnötig heraus. Im Zweifel sollte verfrühter oder unnötiger Aufwand vermieden werden.

Praktiken

Design before Implementation: Vor der Umsetzung muss eine Lösung entworfen werden. Andernfalls findet kein konsequentes Nachdenken über die Lösung statt.

Continous Delivery (CD): Die Entwicklungsphase Setup und Deployment müssen ebenfalls automatisiert werden. Nur so kann sichergestellt werden, dass installierbare Software produziert wird. Durch die Automatisierung wird die Chance minimiert, dass Entwicklerinnen oder Entwickler einen wichtigen Schritt, der „zu Fuß“ ausgeführt werden muss, vergessen.

Iterative Development: Die Entwicklung in Iterationen und kurze Feedbackzyklen sind zwei wesentliche Erfolgsfaktoren der Softwareentwicklung. Durch sie sinkt das Risiko von Fehlentwicklungen und die Qualität der Software steigt.

Incremental Development: Ein vertikaler Schnitt durch die verschiedenen Aspekte eines Softwaresystems wird als Inkrement bezeichnet. Ein Inkrement ist damit ein Stück ausführbarer Software und kann einem Product Owner auf einer Testmaschine zur Verfügung gestellt werden, um Feedback einzuholen.

Component Orientation: Die komponentenorientierte Entwicklung fördert die Produktivität durch die parallele Implementierung, verbessert die Übersichtlichkeit der Anwendung und erleichtert das Testen der einzelnen Komponenten.

Test First: Diese Praktik sagt, dass Schnittstellen sowie ein entsprechend gewünschtes Verhalten durch Tests beschrieben werden. Durch diesen Ansatz entsteht gleichzeitig die Spezifikationsdokumentation in Form von ausführbarem Code, der automatisch überprüft werden kann.

Der weiße Grad

Wie eingangs beschrieben, bildet der weiße Grad den Anfang und das Ende des Clean Code Development. Der weiße Grad vereint alle Prinzipien und Praktiken der farbigen Grade. Entwicklerinnen und Entwickler, die diesen Grad erreicht haben, arbeiten ständig an allen Facetten des Wertesystems.

Theoretisch sind Personen im weißen Grad am Ende der Entwicklung angekommen. Da aber davon ausgegangen werden kann, dass die vielen Prinzipien und Praktiken nicht dauerhaft im Gedächtnis bleiben, lautet die allgemeine Empfehlung, den Zyklus des Clean Code Development nach ungefähr 3 Wochen wieder von vorne zu beginnen. Beginnend beim roten Grad können sich Entwicklerinnen und Entwickler so wieder auf einen bestimmten Ausschnitt des Wertesystems konzentrieren und das bereits erlernte verfeinern. Im Optimalfall wird so ein ständiger Lernprozess durchlaufen.

Übersicht zum Clean Code Development

Die Softway AG legt großen Wert auf die Entwicklung von sauberem Code, der leicht bearbeitet, erweitert und gelesen werden kann. Was genau sich hinter dem Softwareentwicklungsansatz noch versteckt und welche weiteren Grade es gibt, erfahren Sie in unseren anderen Teilen der Blog-Serie zum Clean Code Development:

Was ist Clean Code Development?

Das Wertesystem, die Prinzipien und Praktiken des Clan Code Development

Die unterschiedlichen Grade des Clean Code Development:

Rot und Orange Gelb und Grün Blau und Weiß (dieser Blogpost)

Quellen

Für die Blogbeitrage zum Clean Code Development wurden die Ausarbeitungen von folgenden Internetauftritten herangezogen:

» Clean-Code-Developer.de

» t2informatik.de