Rot und Orange - Die unterschiedlichen Grade des Clean Code Development

Im letzten Blogbeitrag ging es um die Werte, Prinzipien und Praktiken des Clean Code Development. Die dort vorgestellten Regeln bilden die Grundlage für eine saubere Entwicklung von Software. Nur, wer diese Regeln wirklich verinnerlicht, kann sich nach einer gewissen Zeit als Clean Code Developer bezeichnen. Es geht nicht darum, die Regeln auswendig zu lernen, sondern das Wertesystem, die Prinzipien und Praktiken auch wirklich zu leben.

Die unterschiedlichen Grade des Clean Code Development

Um diesen Prozess des Verinnerlichen zu unterstützen, wird das Wertesystem des Clean Code Development in verschiedene Stufen unterteilt. Diese sogenannten Grade sollen von Entwicklerinnen und Entwicklern nach und nach erklommen werden. Allerdings nicht in Form eines Prozesses, der sich Schritt für Schritt einem Ziel nähert, sondern im Rahmen wiederkehrender Abschnitte.  Die einzelnen Grade des Clean Code Development werden deshalb immer wieder durchlaufen, um einen kontinuierlichen Lernprozess zu unterstützen.

Insgesamt gibt es 5 Entwicklungsstufen, die farblich gekennzeichnet 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.

Grad Nummer 1: Rot

Der rote Grad vermittelt die unverzichtbaren Elemente des Clean Code Development Wertesystems sowie der Prinzipien und Praktiken. Auf dieser ersten Stufe geht es noch nicht so sehr um Softwareentwicklungsprinzipien sondern vielmehr um den Aufbau eines fundamentalen Verständnisses der Softwareentwicklung nach dem Clean Code Ansatz. Gleichzeitig ist der rote Grad so aufgebaut, dass alle Entwicklerinnen und Entwickler mit minimalem Aufwand einsteigen können.

Nachfolgend finden Sie eine vereinfachte Übersicht über die Prinzipien und Praktiken des roten Grades, die für die Implementierung von sauberem Code wichtig sind.

Prinzipien

Don’t Repeat Yoursef (DRY): Wiederholungen von Code sollen vermieden werden. Jede Doppelung von Code oder Handgriffen führt schneller zu Fehlern und erschwert gleichzeitig die Wartbarkeit. Das DRY-Prinzip soll genau das verhindern.

Keep it simple, stupid (KISS): Code sollte immer gut verständlich sein. Daher sollten einfache, klare und leicht verständliche Lösungen immer bevorzugt werden. Machen Sie es sich in der Entwicklung so einfach wie möglich und hören Sie auf damit, Abläufe etc. unnötig zu verkomplizieren.

Beware of Premature Optimization: Vorsicht vor Optimierungen! Optimierungen sind immer mit Kosten verbunden und sind dabei selten notwendig oder nützlich. Wer hier vorsichtig agiert, spart oft wertvolle Ressourcen für das, was dem Kunden / was dem Projekt wirklich hilft.

Favour Compositio over Inheritance (FCoI): Das Prinzip besagt, dass Kompositionen anstelle von Vererbungen genutzt werden sollen, sodass Klassen von ihren Algorithmen und deren Details getrennt werden, um so das Verhalten einer Klasse zur Laufzeit verändern zu können.

Integration Operation Segregation Principle (IOSP): Bei der Entwicklung von Code muss klar zwischen unterschiedlichen Entwicklungsmethoden unterschieden werden. Entweder wird nur Logik verwendet, d.h. Transformationen, Kontrollstrukturen oder API-Aufrufe, dann wird das Vorgehen als Operation bezeichnet. Oder es wird keinerlei Logik verwendet und es wird stattdessen nur auf Aufrufe von Methoden mit der selben Codebasis zurückgegriffen, dann wird das Vorgehen als Integration bezeichnet.

Praktiken

Boy Scout Rule: Die Pfadfinderregel besagt: Hinterlasse einen Ort immer in einem besseren Zustand, als du ihn vorgefunden hast. Dieses Konzept lässt sich auch auf die Softwareentwicklung übertragen. Ersichtliche Fehler sollten im Code so schnell wie möglich beseitigt werden, bevor sie zu einem größeren Problem werden.

Root Cause Analysis: Diese gründliche Analyse dient dazu, bei Problemen im Code immer direkt nach dem Ursprung des Übels zu suchen und nicht erst am Ende der Entwicklung mit der Problembehandlung zu beginnen.

Version Control System: Das Versionskontrollsystem ist eine zwingend notwendige Voraussetzung für jede Entwicklerin und jeden Entwickler. Das System nimmt die Angst, etwas falsch oder kaputt zu machen und ermöglicht so den mutigen Einsatz aller Prinzipien und Praktiken des Clean Code Development.

Simple Refactorings: Diese Praktik ist auf die Restrukturierung von Software unter der Beibehaltung des Funktionsangebots ausgelegt. Zwei einfache Refaktorierungsmuster sind beispielsweise das Extrahieren von Methoden oder das Umbenennen von Variablen.

Daily Reflection: Aktives Lernen, Verbesserung und Fortschritt lassen sich nur erreichen, wenn täglich über das Geleistete reflektiert wird. Deshalb sollte die Reflexion, in Form eines sich wiederholenden Termins, fester Bestandteil des Tages werden.

Grad Nummer 2: Orange

Während in Grad 1 die Grundlagen für den kontinuierlichen Verbesserungsprozess geschaffen werden, geht es im 2. Grad darum, einige fundamentale Prinzipien auf den Code anzuwenden und erste Erfahrungen mit der Automatisierung von Abläufen zu sammeln. In dieser Phase dienen Automatisierungen insbesondere der Korrektheitsprüfung.

Nachfolgend finden Sie eine vereinfachte Übersicht über die Prinzipien und Praktiken des orangenen Grades.

Prinzipien

Single Level of Abstraction (SLA): Eine Codezeile kann auf verschiedenen Abstraktionsniveaus liegen. Damit Code allerdings gut zu lesen ist, sollte innerhalb einer Methode auch nur ein Abstraktionsniveau verwendet werden. Andernfalls fällt es schwer, Essentielles von Details zu unterscheiden.

Single Responsible Principle (SRP): Dieses Prinzip besagt, dass eine Klasse nur eine Aufgabe/Verantwortlichkeit haben sollte. Je mehr Klassen angepasst werden müssen, um eine Funktion zu optimieren, umso höher ist die Fehleranfälligkeit.

Separation of Concerns (SoC): Hängt eng mit dem vorherigen Prinzip zusammen und bedeutet übersetzt so viel wie „Trennung der Belange“. Demnach besagt das Prinzip, dass nicht mehrere Belange (Concerns) in einer Klasse zusammengefasst werden sollen.

Als Concerns werden in diesem Fall Übermengen von Responsibilities bezeichnet. Jede dieser Verantwortlichkeiten besteht im Idealfall aus genau einem Concern. Oftmals sind in einer Responsibility allerdings mehrere Concerns vermischt.  Da sich dies technisch meist nicht ganz vermeiden lässt, besagt das Prinzip nicht etwa, dass eine Responsibility nur aus einem Concern bestehen darf, sondern dass die Concerns getrennt sein sollten. Innerhalb einer Methode sollte beispielsweise klar erkennbar sein, dass es mehrere Concerns gibt. Ferner sollten die Concerns nicht irgendwie über die Methode verstreut sein, sondern so gruppiert, dass klar ist, was zu einem Concern gehört.

Source Code Conventions: Das Prinzip definiert Leitlinien, die dabei helfen, die Softwarequalität zu verbessern. Diese Leitlinien enthalten beispielsweise Namensregeln, Kommentare, Deklarationen oder White Spaces.

Praktiken

Issue Tracking: Die Rückverfolgung von Fehlern beschreibt den Prozess von der Erfassung bis zur Beseitigung von Fehlern oder offenen Punkten.

Automated Integrationtests: Automatisierte Integrationstest stellen sicher, dass die Zusammenarbeit verschiedener Komponenten auch noch nach einem Refactoring oder einer Erweiterung funktionieren.

Read, Read, Read: Viele Dinge im Rahmen der Softwareentwicklung entwickeln sich weiter, wie z.B. Softwaretechnik, Methoden, Frameworks oder Tools. Deshalb ist es für Entwicklerinnen und Entwickler notwendig, sich permanent weiterzubilden und aktuelle Zeitschriften, Bücher oder Blogs zu lesen.

Reviews: Reviews erhöhen die Qualität des Codes. Ganz nach dem Motto: Vier Augen sehen mehr als zwei. Denkbar sind beispielsweise Walkthroughs, technische Reviews, Peer Reviews oder Inspektionen.

Übersicht zum Clean Code Development

Die Prinzipien und Praktiken der anderen vier Grade werden demnächst vorgestellt. Hier finden Sie eine Übersicht über die Themen der bisherigen und kommenden Blogbeiträge:

Was ist Clean Code Development? Das Wertesystem, die Prinzipien und Praktiken des Clean Code Development

Die unterschiedlichen Grade des Clean Code Development:

Rot und Orange (dieser Blogpost) Gelb und Grün 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