Mit dem roten Grad beginnt der Weg des Clean Code Developers. Ab hier gilt es, einen ersten Teil der Clean Code Developer Bausteine in die tägliche Arbeit einzubringen und immer wieder zu üben. Der rote Grad ist so gestaltet, dass jeder Entwickler hier mit minimalem Aufwand einsteigen kann. Veränderungen an den Projektverhältnissen sollten kaum nötig sein. Seinen Weg als Clean Code Developer kann also jeder auch „in aller Stille“ beginnen.
Inhaltsverzeichnis
Prinzipien
Don't Repeat Yourself (DRY)
Jede Doppelung von Code oder Handgriffen leistet Inkonsistenzen und Fehlern Vorschub.
| Wandelbarkeit | |
|---|---|
| Korrektheit | |
| Produktionseffizienz | |
| Kontinuierliche Verbesserung | |
| Single Developer |
Das DRY-Prinzip lautet: Don’t Repeat Yourself – Wiederhole dich nicht. Es gilt seit den Anfängen der Softwareentwicklung – sonst gäbe es keine Unterprogramme und keine Datennormalisierung. Dennoch ist es wahrscheinlich das am meisten missachtete Prinzip. Denn nichts ist einfacher, als Code durch Copy&Paste zu wiederholen. Gerade dann, wenn es mal schnell gehen soll, passiert das allzuoft.
Clean Code Developer üben sich im roten Grad daher darin, dieses Prinzip stets zu beachten. Sie sind sich bewusst, wann sie Code oder andere Artefakte wiederholen. Sie erkennen solche Wiederholungen, die sie selbst oder andere erzeugt haben. Sie bereinigen Wiederholungen durch Refaktorisierungen – wenn keine anderen Prinzipien oder Beschränkungen dagegen sprechen.
Keep it simple, stupid (KISS)
Wer mehr tut als das Einfachste, lässt den Kunden warten und macht die Lösung unnötig kompliziert.
| Wandelbarkeit | |
|---|---|
| Korrektheit | |
| Produktionseffizienz | |
| Kontinuierliche Verbesserung | |
| Single Developer |
Oder um es mit Albert Einsteins Worten zu sagen: „Alles sollte so einfach wie möglich gemacht werden, aber nicht einfacher.“. Für die Wandelbarkeit des Codes ist zwingende Voraussetzung, dass der Code verständlich ist. Eine einfache, klare und leicht verständliche Lösung sollte daher immer bevorzugt werden. Wenn man seinen eigenen Code nach kurzer Zeit schon nicht mehr versteht, sollten die Alarmglocken klingen. Noch wichtiger aber ist, dass auch andere Entwickler den Code schnell verstehen können. Dabei helfen regelmäßige Reviews und Pair Programming. Sie dienen der Kontrolle, ob tatsächlich die einfachste Lösung verwendet wurde.
Gerade in technischen Details steckt die Versuchung, eine komplizierte Lösung anzustreben. Das Bekannte, naheliegende ist manchmal zu „langweilig“ – und schon hat sich eine komplizierte Lösung eingeschlichen. Wenn die einfache Lösung auch funktioniert, sollte ihr Vorrang gewährt werden. Das gleiche gilt für Datenstrukturen. Wenn ein IEnumerable reicht, sollte keine ICollection oder sogar IList verwendet werden.
Beware of Premature Optimization
Optimierungen kosten immer viel Aufwand. Wer Vorsicht walten lässt, spart oft wertvolle Ressourcen für das, was dem Kunden wirklich nützt.
| Wandelbarkeit | |
|---|---|
| Korrektheit | |
| Produktionseffizienz | |
| Kontinuierliche Verbesserung | |
| Single Developer |
Rule 1: Don’t do it.
Rule 2 (for experts only): Don’t do it yet.
Im Vordergrund steht immer die Verständlichkeit von Code. Optimierter Code ist aber oft alles andere als lesbar. Indem er auf das absolut Notwendige in kürzester Form reduziert ist, mag er zwar die funktionalen und nicht funktionalen Anforderungen des Kunden erfüllen – doch er spiegelt sie meist nicht mehr verständlich wider. Das ist kontraproduktiv im Sinne der meist gewünschten Langlebigkeit einer Software. Donald Knuth schrieb bereits 1974: „We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.“ (Knuth, Donald. Structured Programming with go to Statements, ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974. p.268.)
Die Pfadfinderregel ist also nicht so gemeint, dass immer weiter nach Codeoptimierungen gestrebt werden sollte. Sie bezieht sich vielmehr auf deren Gegenteil: Verständlichkeit und Wandelbarkeit.
Wenn es dem Clean Code Developer also in den Fingern zuckt, weil er denkt, er könne doch noch ein Quäntchen Performance durch eine Optimierung herausholen, dann sollte er mindestens zweimal überlegen. Zum einen würde er dadurch die Verständlichkeit verschlechtern, zum anderen aber ist es wahrscheinlich, dass solche Optimierung aus mehreren Gründen gar nicht nötig ist. Ist die Performanceschwäche nicht nur punktuell und ein Sonderfall, wird sich die nächste größere Refaktorisierung ihrer wahrscheinlich ohnehin annehmen, denn dann liegt ihr ein grundsätzliches Strukturproblem zugrunde. Oder die nächste Hardwaregeneration bügelt den Performanceknick aus. Oder der Kunde fühlt sich durch ihn gar nicht gestört. Ohnehin muss der Kunde die Forderung nach der Optimierung gestellt haben. Keine Codeveränderung ohne vom Kunden erwarteten Nutzen. Denn nur für ihn ist er bereit zu zahlen.
Der Regel, sich im Zweifelsfall gegen Optimierungen zu entscheiden, liegt somit eine noch fundamentalere zugrunde: YAGNI – You ain’t gonna need it. Sie ist in ihrer vollen Ausprägung allerdings erst Bestandteil des blauen Grades.
PS: Wenn denn entgegen allen Warnungen und Bedenken gerade eine Performanceoptimierung unumgänglich ist, dann sollte sie immer nur aufgrund einer detaillierten Analyse mit einem Profiler begonnen werden. Denn nur wer mit einem Profiler nachvollziehbar Performance-Engpässe lokalisiert hat, kann während und nach der Optimierung prüfen, ob und inwiefern er sie geweitet hat.
Favour Composition over Inheritance (FCoI)
Komposition fördert die lose Kopplung und die Testbarkeit eines Systems und ist oft flexibler.
| Wandelbarkeit | |
|---|---|
| Korrektheit | |
| Produktionseffizienz | |
| Kontinuierliche Verbesserung | |
| Single Developer |
Für die Wiederverwendung von Funktionalität kennt die Objektorientierte Programmierung (OOP) zwei sehr bekannte Kandidaten: Die Vererbung (whitebox – reuse) und die Komposition (blackbox – reuse). Verwendet man Funktionalität wieder durch das Ableiten von einer Klasse, so ist die Subklasse abhängig von der Elternklasse. Dies macht ein System in vielen Fällen unnötig komplex, schlechter testbar und erschwert das Austauschen von Funktionalität zur Laufzeit. CCD hat für das korrekte Ableiten das Liskov Substitution Prinzip (LSP) bereit, das es dabei zu befolgen gilt.
Bei der Komposition verwendet eine Klasse eine andere. Verwendet man dazu eine klar definierte Schnittstelle, fördert das die Entkopplung. Auch können verschiedene Implementationen einfach ausgetauscht werden. Bevor man sich also der Liskov Substitution stellt, fordert Favour Composition over Inheritance, sich die Frage zu stellen, ob man der Komposition nicht Vorrang geben kann.
„Because inheritance exposes a subclass to details of its parent’s implementation, it’s often said that ‚inheritance breaks encapsulation„. (Gang of Four 1995:19)
Integration Operation Segregation Principle (IOSP)
Ein deutliches Symptom schlecht wandelbaren Codes sind tiefe Hierarchien funktionaler Abhängigkeit. Sie reduzieren die Verständlichkeit und erschweren automatisierte Tests wie Refactoring.
| Wandelbarkeit | |
|---|---|
| Korrektheit | |
| Produktionseffizienz | |
| Kontinuierliche Verbesserung | |
| Single Developer |
Indem in Methoden verhaltenserzeugende Anweisungen (Logik) gemischt mit Aufrufen anderer Methoden derselben Codebasis steht, ist nicht mehr klar erkennbar, wie Gesamtverhalten entsteht; die Anweisungen sind ja verschmiert über eine u.U. sehr tiefe Hierarchie. Zudem tendieren Methoden mit solcher Mischung dazu, unbegrenzt zu wachsen.
Dem stellt sich das IOSP mit einer klaren Trennung entgegen:
- Entweder enthält eine Methode nur Logik, d.h. Transformationen, Kontrollstrukturen oder I/O- bzw. allgemeiner: API-Aufrufe. Dann wird sie Operation genannt.
- Oder eine Methode enthält keinerlei Logik, sondern nur Aufrufe von anderen Methoden derselben Codebasis. Dann wird sie Integration genannt.
Diese strikte Unterscheidung führt zu mehrerlei positiven Effekten:
- Methoden tendieren dazu, sehr kurz zu bleiben. Denn mehr als 10, 20 oder 30 Zeilen reine Logik oder ausschließlich Methodenaufrufe „fühlen sich nicht gut an“. Da eine Mischung nicht erlaubt ist, werden weitere kleine Methoden extrahiert.
- Kurze Methoden, die nur Logik enthalten, sind leicht zu testen, da sie keine Abhängigkeiten haben.
- Kurze Methoden, die nur Logik enthalten, sind vergleichsweise leicht zu verstehen. Der Methodenname kann wirklich bedeutungsstiftend wirken.
- Kurze Methoden, die ausschließlich integrieren, sind sehr gut zu verstehen und beschreiben „auf einen Blick“, was geschieht.
- Die Korrektheit von Integrationen lässt sich sehr leicht durch Augenscheinnahme prüfen. Es ist lediglich festzustellen, ob Verarbeitungsschritte grundsätzlich in der korrekten Reihenfolge angeordnet sind. Den Rest übernimmt der Compiler – bzw. die Testabdeckung der Operationen.
- Integrationen lassen sich leicht durch „Zwischenschieben“ weiterer Methoden erweitern, um neue Anforderungen zu erfüllen. Die Verständlichkeit bleibt dabei erhalten.
Das IOSP lässt sich „aus dem Stand“ von jedem Entwickler guten Willens anwenden. Seine Einhaltung ist durch jedermann leicht zu überprüfen. Integrationen und Operationen unterscheiden sich in der Form deutlich. Weitere Details, insbesondere zur Abgrenzung zum Dependency Inversion Principle (DIP), findest du bspw. hier.
Praktiken
Boy Scout Rule
Jede Beschäftigung mit einem Gegenstand macht ihn zumindest ein klein wenig besser. Ganz ohne bürokratische Planung. Fundament und Graswurzelansatz für mehr Qualität.
| Wandelbarkeit | |
|---|---|
| Korrektheit | |
| Produktionseffizienz | |
| Kontinuierliche Verbesserung | |
| Single Developer |
Das Clean Code Developer Wertesystem lässt sich nicht mit einem Mal etablieren. Dafür braucht es Zeit. Vor allem, da ein Clean Code Developer selten auf einer grünen Wiese und auch noch allein arbeitet, ist es schwer, die Prinzipien auf eine gesamte Codebasis anzuwenden. Wir glauben daher, dass es wichtig ist, sich nicht zu hohe Ziele zu setzen. Viel realistischer und motivierender ist es, nur kleine Fortschritte anzustreben – dafür aber kontinuierliche.
Zum Fundament des Clean Code Development gehört deshalb für uns die Pfadfinderregel. Sie findet sich auch in Clean Code und lautet: Hinterlasse einen Ort immer in einem besseren Zustand als du ihn vorgefunden hast.
Auf die Softwareentwicklung angewandt bedeutet das: Clean Code Developer hinterlassen Code immer in einem „besseren Zustand“ als sie ihn vorgefunden haben. Nach getaner Arbeit stimmt der Code also mit dem Clean Code Development Wertesystem mehr überein als vorher.
Was ein Clean Code Developer an ihm dafür getan hat, ist situations-/codeabhängig – und wird natürlich auch durch den Grad bestimmt, an dem er arbeitet. Im roten Grad achtet ein Clean Code Developer z.B. darauf, dass Code, der noch nicht im Repository der Versionsverwaltung war, nun auch dort abgelegt ist. Und er achtet darauf, dass Wiederholungen jeder Art – also Verletzungen des DRY-Prinzips – „ausgebügelt“ werden.
Wo ein Clean Code Developer Suboptimalitäten im Sinne des CCD-Wertesystems feststellt, bemüht er sich also stetig darum, sie zu verbessern. In kleinen Schritten. Und natürlich bemüht er sich, Suboptimalitäten von vornherein zu vermeiden. Wie gesagt: immer auf der Stufe seiner Entwicklung.
Diese Maxime steht am Anfang der Entwicklung des Clean Code Developers eingedenk der Broken Windows Theorie. Nach ihr beginnt der Verfall von Qualität im allgemeinen Sinn mit Kleinigkeiten, die nur lange genug unbeachtet bleiben.
Wenn Clean Code Developer jedoch nach der Pfadfinderregel arbeiten, kommt es gar nicht erst zu „Broken Windows“ – vorhandene werden eines nach dem anderen repariert. „Risse und Unebenheiten“ im Code schließt die Pfadfinderregel konsequent auf der Basis des CCD-Wertesystems, sodass sich keine weiteren „Ablagerungen“ ansammeln können. Sie wirkt damit proaktiv einer Code-Erosion entgegen. Das halten wir für so fundamental, dass wir sie in den roten Grad aufgenommen haben.
Root Cause Analysis
Symptome behandeln bringt vielleicht schnell eine Linderung – langfristig kostet es aber mehr Aufwand. Wer stattdessen unter die Oberfläche von Problemen schaut, arbeitet am Ende effizienter.
| Wandelbarkeit | |
|---|---|
| Korrektheit | |
| Produktionseffizienz | |
| Kontinuierliche Verbesserung | |
| Single Developer |
Regel vom ersten Tag als Clean Code Developer an sollte sein, bei Problemen immer intensiv nach der wahren Wurzel des Übels zu suchen. Clean Code Developer geben sich nicht mit einer Symptomkur zufrieden. Beispiel: Die Sortierung von Daten im Speicher ist zu langsam. Eine oberflächliche Kur würde jetzt daran gehen, einzelne Anweisungen oder Anweisungsblöcke zu beschleunigen. Vielleicht wird der Einsatz von unsafe Code probiert, vielleicht eine Parallelisierung. Eine nähere Problemanalyse jedoch hätte ergeben, dass ein suboptimaler Algorithmus die Wurzel des Übels ist. Schwer verständliche Optimierungen auf niedriger Abstraktionsebene können also vermieden werden. Ein besserer Algorithmus ist die saubere Lösung.
Wurzelproblemanalyse ist also ein Dienst an der Verständlichkeit und am Aufwand. Denn bei Kenntnis des Wurzelproblems ist die Bereinigung meist weniger aufwändig als eine Symptomkur. Stößt der Clean Code Developer auf ein Problem, so hält er also als erstes inne, um sich eine Chance zu geben, hinter die Symptome zu schauen.
Die Root Cause Analysis ist auch unter dem Begriff Five Why’s bekannt. Dieser Begriff stammt aus der Terminologie des Toyota Produktions Systems (TPS). Die Grundidee: frage mindestens fünf mal „Warum?“.
Version Control System
Angst vor Beschädigung eines „running system“ lähmt die Softwareentwicklung. Mit einer Versionsverwaltung ist solche Angst unbegründet. Die Entwicklung kann schnell und mutig voranschreiten.
| Wandelbarkeit | |
|---|---|
| Korrektheit | |
| Produktionseffizienz | |
| Kontinuierliche Verbesserung | |
| Team |
Unabdingbare Voraussetzung für jeden Clean Code Developer ist es, seinen Code unter den Schutz eines Versionskontrollsystems zu stellen. Ob das Mercurial, Git, Subversion, VSS, TFS oder Vault ist, spielt dabei keine Rolle. Wir meinen nur, dass heute keine Arbeit an Code mehr durchgeführt werden sollte, ohne ihn in einem Versionskontrollsystem zu pflegen. Der Grund dafür ist ganz simpel: Ein Versionskontrollsystem befreit von Angst. Und Angstfreiheit ist nötig, um mutig die Prinzipien und Praktiken des CCD-Wertesystems umzusetzen.
Ein Versionskontrollsystem nimmt die Angst, etwas falsch und damit kaputt zu machen. Wenn Code in ihm gehalten wird, kann jeder CCD den Code nach Belieben verändern, ohne befürchten zu müssen, einen erreichten Stand zu zerstören. Nichts geht verloren. Das Versionskontrollsystem ist wie eine Zeitmaschine für Code.
Damit ist ein Versionskontrollsystem die allerbeste Grundlage für alles Lernen. Denn Lernen bedeutet Fehler machen. Mit einem Versionskontrollsystem als Sicherheitsnetz können wir uns alle Fehler erlauben. Deshalb: Erste Voraussetzung für den Einstieg ins Clean Code Development ist der ständige Gebrauch eines Versionskontrollsystems.
Wo das im Projekt nicht möglich ist, sehen wir das Fundament für Clean Code Development abwesend. Wir würden auch nicht verstehen, warum der Einsatz eines Versionskontrollwerkzeuges nicht möglich sein sollte. Kosten müssen dafür nicht anfallen und der Einarbeitungsaufwand in die einfachsten Funktionen ist minimal. CCD schreibt ja keine bestimmte Nutzung eines Versionskontrollsystems vor, sondern nur, dass eines benutzt werden muss.
Siehe auch unter Tools.
Simple Refactorings
Code verbessern ist leichter, wenn man typische Verbesserungshandgriffe kennt. Ihre Anwendungsszenarien machen sensibel für Schwachpunkte im eigenen Code. Als anerkannte Muster stärken sie den Mut, sie anzuwenden.
| Wandelbarkeit | |
|---|---|
| Korrektheit | |
| Produktionseffizienz | |
| Kontinuierliche Verbesserung | |
| Single Developer |
Um Code immer ein wenig besser zu hinterlassen, als man ihn vorgefunden hat, sind mehr oder weniger große Eingriffe nötig. Die kann ein Clean Code Developer dank des Versionskontrollsystems angstfrei vornehmen. Doch wie macht er sich die Arbeit möglichst einfach?
Das Schlüsselwort lautet „Refaktorisierung“. Martin Fowler hat das Refaktorisieren/Refactoring in seinem gleichnamigen Buch als grundlegende Technik zur Erhöhung der Codequalität beschrieben. Er definiert darin eine Anzahl von Codeveränderungsmustern, um „code smells“, d.h. suboptimale Strukturen oder allgemeiner Missachtungen von Prinzipien, zu bereinigen.
Für den roten Grad ist darin vor allem die Refaktorisierung Methode extrahieren relevant, um dem DRY-Prinzip zu genügen. Die wenden Clean Code Developer an, um mehrfach vorkommenden Code in eine Methode zu extrahieren, die statt seiner an den Wiederholungsorten aufgerufen wird.
Als zweite Refaktorisierung sollte bei der Arbeit am roten Grad das Umbenennen wo nötig eingesetzt werden. Sie passt zur Pfadfinderregel, denn eine oft anzutreffende „Unsauberkeit“ im Quellcode sind kryptische Namen.
Refaktorisierungen können von Hand angewandt werden, doch es gibt auch Werkzeugunterstützung. Moderne IDEs wie Visual Studio bieten einige Refactoringmuster, weitere Tools listet unsere Werkzeugliste.
„Refactoring“ wie „Clean Code“ gehören zur Pflichtlektüre jedes Clean Code Developers ab dem roten Grad.
Für weitere Informationen siehe auch unter refactoring-legacy-code.net.
Daily Reflection
Keine Verbesserung, kein Fortschritt, kein Lernen ohne Reflexion. Aber nur, wenn Reflexion auch eingeplant wird, findet sie unter dem Druck des Tagesgeschäftes auch statt.
| Wandelbarkeit | |
|---|---|
| Korrektheit | |
| Produktionseffizienz | |
| Kontinuierliche Verbesserung | |
| Single Developer |
Im Zentrum von CCD steht die persönliche Entwicklung. Es geht also um Veränderung: Mit jedem Tag soll sich das CCD-Wertesystem ein klein wenig mehr im Projektalltag des Clean Code Developers manifestieren. Das ist die Pfadfinderregel des Clean Code Developers auf sich selbst angewandt.
So ein Veränderungsweg geht sich allerdings gerade allein nicht leicht. Wie also auf Kurs bleiben? Wie Fortschritt messen?
Ohne ein „Kontrollsystem“ etablieren zu wollen, glauben wir, dass dazu zweierlei gehört:
- Kleinschrittige Planung
- Reflexion nach jedem Schritt
Unabhängig von Vorgaben durch eine Projektleitung sollten Clean Code Developer ihre Arbeit so einteilen, dass sie aus Aufgaben besteht, die an einem Arbeitstag zu bewältigen sind. Nur so kann am Abend jedes Tages eine Bilanz gezogen werden. Das halten wir für wichtig, um jeden Tag die Arbeit nicht mit in den Feierabend zu tragen. Da hat sie nichts zu suchen; der dient der Entspannung.
Durch solche kleinen Planungsschritte wird der Arbeitsalltag allerdings nicht nur befriedigender, weil sich jeden Tag über Erfolg oder Misserfolg entscheiden lässt. Die schiere Möglichkeit der Entscheidung am Abend – Habe ich alle meine Aufgaben erledigt? Wie habe ich meine Aufgaben erledigt? – erlaubt auch die Reflexion über die Einhaltung des Clean Code Developer Wertesystems.
Um sich konsequent zu einem Clean Code Developer zu entwickeln, soll der Entwickler sich auf jedem Grad nach jedem Arbeitstag darüber Rechenschaft ablegen, ob er alle für ihn nach Grad relevanten Aspekte des Wertesystems berücksichtigt hat. Für den roten Grad bedeutet das z.B. Fragen wie: Verwalte ich wirklich alle Codefragmente im Versionskontrollsystem? Habe ich das DRY-Prinzip konsequent angewandt? Habe ich ganz allgemein Code in einem besseren Zustand hinterlassen als vorgefunden?
Wenn er auf eine dieser Fragen nur zögerlich mit Ja oder gar mit einem Nein antworten muss, dann ist das natürlich kein Beinbruch. Bei allem Bemühen klappt es eben nicht immer, dass man den guten Willen auch in die Tat umsetzen kann.
Dennoch oder gerade deshalb ist dann allerdings Folgendes zu tun:
- Entweder bessert der Clean Code Developer jetzt solange nach, bis er in Bezug auf seines Tages Arbeit keine Prinzipienverletzung mehr wahrnimmt.
- Oder er nimmt die erkannten Prinzipienverletzungen für den nächsten Tag auf seinen Aufgabenzettel.
Eine Hilfe bei der Reflexion kann das Clean Code Developer Armband sein. Uns ist bewusst, dass es nicht jedermanns Sache ist, ein buntes Silikonarmband zu tragen. Wer damit kein Problem hat, kann das Armband im Rahmen der persönlichen Reflexion nutzen. Kann oder will der Clean Code Developer die Prinzipienverletzung nicht bereinigen oder auf seinen Arbeitszettel nehmen, sollte er das Armband, das er trägt, vom einen auf den anderen Arm wechseln. So macht er deutlich, dass er eine Differenz zwischen dem Soll seines Grades und dem Geschafften anerkennt. Das ist nicht als Niederlage misszuverstehen oder gar als „Buße“. Es geht vielmehr um eine haptische Unterstützung des Lernvorgangs.
Wenn ein Clean Code Developer 21 Tage lang nach getaner Arbeit das Armband nicht mehr wechseln musste, kann er zur Arbeit am nächsten Grad übergehen. Für den roten Grad ist das der orange Grad.
Deutsch 
English 
Français 
Español