Gelb und Grün - Die unterschiedlichen Grade des Clean Code Development

Weiter geht unsere Blogserie zum Thema Clean Code Development – der Entwicklung von sauberem, leicht lesbarem, einfach zu erweiterndem sowie schnell zu wartendem Code. Die bisherigen Teile haben die Grundlagen des Clean Code Development vorgestellt und bereits die ersten Grade der Softwareentwicklung beleuchtet.

Die unterschiedlichen Grade des Clean Code Development

Diesmal im Fokus: Der 3. und 4. Grad der sauberen Softwareentwicklung – auch als Grün und Gelb 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.

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 3: Gelb

Automatisierte Tests stehen im Zentrum der Prinzipien und Praktiken des gelben Grades. Anders als noch im orangenen Grad geht es nicht mehr nur um Tests an der Oberfläche sondern um tiefgreifende Check Up’s. Getestet werden sollen in diesem Grad die kleinstmöglichen Einheiten.

Hilfreich sind dabei folgenden Prinzipien und Praktiken:

Prinzipien

Interface Segregation Principle (ISP): Ein Client sollte nicht von Details eines Service abhängen, die gar nicht benötigt werden. Ein Interface sollte nur Dinge enthalten, die wirklich notwendig sind, um die Kopplung zwischen verschiedenen Komponenten übersichtlich zu gestalten.

Dependency Inversion Principle (DIP): High-Level Klassen dürfen nicht von Low-Level Klassen abhängig sein – beiden ist allerdings eine Abhängigkeit von Interfaces erlaubt. Interfaces wiederum sollten nicht von Detail abhängig sein, sondern Details von Interfaces. So lassen sich Kopplungen vermeiden.

Liskov Substitution Principle (LSP): Abgeleitete Subtypen müssen sich so verhalten wie ihr Basistyp, wobei Subtypen die Funktionalitäten der Basistypen erweitern, aber nicht einschränken dürfen.

Principle of Least Astonishment: Softwareentwicklung ist ein kreativer Prozess, für den ein hohes Maß an Konzentration gebraucht wird. Unterbrechungen jeder Art lenken daher von der eigentlichen Arbeit ab und sind so gut es geht zu vermeiden. Nur so kann sichergestellt werden, dass sich im Code keine Fehler durch Unachtsamkeiten auf Grund von unnötigen Unterbrechungen einschleichen.

Information Hiding Principle: Das Verbergen von Details in einer Schnittstelle hilft dabei Abhängigkeiten zu reduzieren. Je mehr Details sichtbar sind, desto höher ist die Kopplung zwischen einer Klasse und ihren Verwendern. Ist erst einmal ein Detail einer Klasse verwendet worden, wird es schwerer, dieses Detail zu verändern. Dies steht der Wandelbarkeit der Software im Weg.

Praktiken

Automated Unit Tests: Unit Tests überprüfen, ob die entwickelten Komponenten auch wie beabsichtigt funktionieren. Durch die Automatisierung lässt sich Zeit einsparen und Tests werden auch wirklich durchgeführt.

Mockups: Um einzelne Komponenten isoliert testen zu können, gilt es, Abhängigkeiten zu beseitigen. Dazu werden sogenannte Mockups oder auch Testattrappen genutzt, die mit der zu testenden Komponente interagieren, weil beispielsweise das gewünschte Objekt noch nicht zur Verfügung steht.

Code Coverage Analysis: Um die Teile des Quellcodes zu finden, die bisher noch nicht ausreichend durch Testfälle überprüft wurde, wird die Code Coverage Analyse durchgeführt. Die Analyse zeigt, welche Anweisungen, Verzweigungen, Pfade und Bedingungen noch nicht getestet wurden.

Partizipation in Professional Events: Die Teilnahme an Fachveranstaltungen dient, zusätzlich zum Lesen von Fachliteratur und dem Austausch mit anderen Entwicklerinnen und Entwicklern, zur Weiterbildung auf dem Gebiet der Softwareentwicklung und ist ein wichtiger Bestandteil des Clean Code Ansatz.

Complex Refactorings: Einfache Refaktorisierungen sind bereits Teil des roten Grades. Im gelben Grad können nun auch komplexe Refaktorisierungen in Verbindung mit automatisierten Tests effizient und risikolos eingesetzt werden.

Grad Nummer 4: Grün

Noch mehr Automatisierung. So lässt sich das Motto oder Ziel des grünen Grades umschreiben. Eine hohe Automatisierung hilft der Softwareentwicklerin oder dem Softwareentwickler, sich auf die Implementation von Kundenanforderungen zu konzentrieren. Ohne vorhandene Automatisierungen hängt die Entwicklung sonst zu oft an Kleinigkeiten, die viel Zeit kosten. Korrektheitsprüfungen und Releases sind dann mehr Strafe als Mittel zum Erfolg.

Für diesen Grad sind daher folgende Prinzipien und Praktiken einzusetzen:

Prinzipien

Open Closed Principle (OCP): Klassen sollten offen für Erweiterungen sein – allerdings geschlossen gegenüber Modifikationen. So wird das Risiko minimiert, ein bisher fehlerfreies System durch neue Features zu destabilisieren.

Tell, don’t ask: Anstatt ein Objekt nach Daten zu fragen, um mit diesen zu interagieren, soll mit diesem Prinzip dem Objekt mitgeteilt werden, was es tun soll. So lassen sich Daten mit den Funktionen bündeln, mit denen sie arbeiten.

Law of Demeter (LoD): Das Zusammenspiel von Objekten lässt sich mit dieser Methode auf ein gesundes Maß beschränken. Nach dem Law of Demeter sollen Objekte nur mit anderen Objekten aus ihrer unmittelbaren Umgebung kommunizieren, um so die Kopplung zu verringern. Bei reinen Datenhaltungsklassen muss das Prinzip nicht verwendet werden.

Praktiken

Continuous Integration (CI): Die Integration der Softwarekomponenten wird häufig nach hinten geschoben und erfolgt letztlich aufwendig und fehleranfällig manuell. Software sollte aber eigentlich zu jedem Zeitpunkt vollständig einsatzbereit sein. Continuous Integration bezeichnet daher einen Prozess, der dafür sorgt, dass der gesamte Code nach der Übermittlung von Änderungen übersetzt und getestet wird.  

Statical Code Analysis: Kurz heruntergebrochen lässt sich diese Praktik wie folgt umschreiben: „Vertrauen ist gut – Kontrolle ist besser“. Je automatischer diese Kontrolle stattfindet, desto leichter fällt sie schließlich.

Inversion of Control Container: Als Erweiterung des im gelben Grad angesprochenen Dependency Inversion Principles – in dem Abhängigkeiten noch per Hand aufgelöst wurden – macht die Inversion of Control Container den nächsten logischen Schritt und löst Abhängigkeiten automatisch auf. Dazu stehen zwei Verfahren zur Verfügung: Locator und Container.

Share Experience: Wer sein Wissen weitergibt, hilft damit nicht nur sich selbst, sondern auch anderen Personen. Erst durch Wissensvermittlung findet wahre Reflexion und die Durchdringung eines Fachthemas statt. Davon profitieren in der Regel alle Beteiligten.

Error Measurement: Wer weiß, wie viele Fehler auftreten, kann sein Vorgehen so verändern, dass die Fehlerrate entsprechend sinkt. Die Vergleichbarkeit der Messung ist dabei wichtiger als die Präzision.

Ü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 (dieser Blogpost) Blau und Weiß

Quellen

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

» Clean-Code-Developer.de

» t2informatik.de