Clean Code
Der Begriff Clean Code wurde durch Bob C. Martin und sein gleichnamiges Buch geprägt. Kurz nach der Veröffentlichung haben Ralf Westphal und ich die Clean Code Developer Initiative gegründet und dort 45 Prinzipien und Praktiken zusammengetragen. Clean Code, das Buch, war dabei für uns eine Anregung, uns mit dem Thema zu befassen. Wir haben uns aus verschiedenen Quellen bedient und die Prinzipien sind teils schon in den 1970er Jahren besprochen worden. Hier findest du bspw. ein PDF von Parnas aus 1972 zur Idee der Modularisierung.
Was ist all den Strömungen gemein? Es geht darum, den Verlauf der Kosten zu linearisieren, wie es die folgende Abbildung zeigt.
Ob man nun von Clean Code, Clean Code Developer oder Software Craftsmanship spricht, im Kern geht es immer darum, Softwareprojekte beherrschbar zu machen, in dem der Verlauf der Kosten linear bleibt, statt exponentiell anzusteigen.
Prinzipien und Praktiken
Dabei helfen uns Prinzipien und Praktiken. Dazu ein Beispiel: Wenn wir im Code dafür sorgen, dass eine Methode oder Klasse genau eine Aufgabe hat, wird es leichter, den Code zu verstehen. Somit sorgt das Single Responsibility Principle (SRP) für eine Linearisierung des Kostenverlaufs. Code, den wir leicht verstehen, können wir leichter ändern oder ergänzen. Ähnliches gilt für die Praktiken. So erkennen wir bspw. durch Continuous Integration Probleme im Code schneller, weil regelmäßig alles integriert wird. Auch Praktiken tragen so zur Linearisierung der Kosten bei.
Werte
Doch hier wird es spannend: bedeutet dass nun, dass die Prinzipien und Praktiken immer eingehalten werden müssen? Stehen sie an oberster Stelle? Ganz offensichtlich lautet die Antwort: nein. An oberster Stelle stehen die Werte. Es geht bspw. um Wandelbarkeit oder Korrektheit. Wie diese Werte erreicht werden, ist erst die zweite Frage, die wir stellen. Häufig lautet die Antwort, ein Prinzip einzuhalten oder eine Praktik anzuwenden. Hier sind wir dann nahe am Begriff des Dogmas.
Laut Wikipedia bezeichnete der Begriff Dogma in der Antike „die von Herrschenden erlassene und somit nicht zu hinterfragende Verordnung“. Ganz offensichtlich sollten wir Prinzipien und Praktiken der Softwareentwicklung nicht als Verordnung auffassen, die von irgendjemandem erlassen wurde und die nicht zu hinterfragen ist. Dennoch stellt sich im Detail die Frage, ob bspw. gegen Prinzipien niemals verstoßen werden darf. Gibt es hier einen Spielraum? Sind die Clean Code Developer Prinzipien und Praktiken eine Meinung, der man folgen kann oder eben nicht?
Clean Code Trainings
Geschlossene Firmenkurse
Wir führen alle Seminare als geschlossene Firmenkurse für Sie durch.
Bei Interesse oder Fragen kontaktieren Sie uns gerne.
Notwendigkeit statt Dogma
Natürlich ist die Zusammenstellung der Clean Code Developer Bausteine etwas geprägt von unseren Ansichten. Das lässt sich nicht ganz vermeiden. So fehlt ganz absichtlich TDD und nur Test-first ist genannt. Über die Gründe habe ich hier bereits geschrieben (https://ccd-akademie.de/tdd-vs-test-first/). Und dennoch liefert unsere Zusammenstellung eine Menge an Bausteinen, die insgesamt zum Ziel führen: die Werte Wandelbarkeit und Korrektheit zu erreichen. Sollte man die Bausteine nun dogmatisch betrachten und in jedem Fall immer einhalten? Nein! Es bedarf einer differenzierten Betrachtung. Als Orientierung ist es zwingend, über die Prinzipien nachzudenken bzw. sie im Code Review abzuklopfen. Es geht nicht um ein Dogma sondern um eine Notwendigkeit. Wenn wir die Prinzipien und Praktiken nicht berücksichtigen, wird der Anstieg der Kosten exponentiell erfolgen. Da dies für unsere Auftraggeber nicht akzeptabel ist, ist die Befolgung von Clean Code eine Notwendigkeit.
Clean Code ist eine Notwendigkeit. Wer nicht nach den Regeln der Kunst arbeitet, wird schnell ins Hintertreffen geraten.
Fazit
Die gute Nachricht lautet: entspann dich. Die Prinzipien müssen nicht dogmatisch eingehalten werden. Die andere Nachricht lautet aber auch: Clean Code ist eine Notwendigkeit. Mindestens im Wettbewerb wird es auf kurz oder lang nicht ausreichen, seinen Code irgendwie rauszuhauen. Prinzipien müssen beachtet werden, Praktiken im Team eingeführt und gelebt werden. Dabei muss in jeder Situation abgewägt werden, was gerade wichtig ist. Manchmal muss ein Prinzip in jedem Fall eingehalten werden, manchmal steht anderes im Vordergrund. Ein Dogma wäre vielleicht sogar einfacher, in der Wirkung aber zu einfach. Es führt eben gerade nicht zum Ziel, nur blind irgendwelche Prinzipien einzuhalten. Ein Team benötigt eine klar strukturierte Arbeitsweise. Dieser Prozess muss sicherstellen, dass alle wichtigen Schritte durchlaufen werden, die zu Code von hoher Qualität führen.
P.S. Möglicherweise können dich folgende Hilfsmittel unterstützen:
German 
English
2 Kommentare zu „Clean Code ist kein Dogma“
Pingback: 4 Gründe, keinen Clean Code zu schreiben - CCD Akademie GmbH
Pingback: 7 Gründe für Software Unternehmen ein Clean Code Training zu buchen - CCD Akademie GmbH