Clean Code Developer - Was ist CCD?

14.03.2018

Clean Code Developer - Was ist CCD?

In meinem zweiten Beitrag, «Warum CCD?», habe ich die Frage erörtert, warum es Prinzipien und Praktiken braucht um qualitativ hochwertige Software zu erstellen. In diesem Beitrag geht es um die Frage « Was ist CCD?».

Was ist nun das Clean Code Developer System? Kurz zusammengefasst: Es handelt sich um eine Sammlung von Prinzipien und Praktiken, die in unterschiedliche Grade unterteilt sind. Diese Grade werden schrittweise und getreu der agilen Vorgehensweise iterativ durchwandert. Grundlage der Bewegung ist das Buch Clean Code: A Handbook of Agile Software Craftsmanship von Robert C. Martin. Der Autor ist Mitbegründer der "Software Craftsmanship" Bewegung die in ihren Anfängen bis in die späten 90er zurückreicht. Er ist auch einer der Unterzeichner des «Agile Manifesto», das bekanntlich die Grundlage von agilen Vorgehensmodellen ist. Die Craftsmanship Bewegung fordert unter anderem, dass die Tätigkeit des Softwareentwickelns als Handwerkskunst angesehen werden soll. In aktuellen Definitionen von agiler Entwicklung taucht Clean Code aber eher selten als grundlegende Entwicklungsmethode auf. Daher sehen wir es als notwendig an, dieses Wissen um qualitative hochwertige Entwicklung wieder ins Bewusstsein zu rufen.

Gründer des Clean Code Developer Systems sind Stefan Lieser und Ralf Westphal die auch die Seite clean-code-developer.de unterhalten.

Die Autoren fassen CCD sehr passend mit dieser Umschreibung zusammen:

Clean Code Developer

Eine Initiative für mehr Professionalität in der Softwareentwicklung

Professionalität = Bewusstheit + Prinzipien

  • Ein professioneller Softwareentwickler setzt sich mit dem Metier bewusst auseinander.
    Dies bedeutet, er reflektiert über sein Produkt, seine Arbeitsweise, seine Materialien und Werkzeuge. Ein professioneller Softwareentwickler ist nicht einfach zufrieden, wenn sein Chef oder Kunde zufrieden ist. Er ist auch nicht einfach mit dem zufrieden, was ein Hersteller ihm empfiehlt. Stattdessen beobachtet und prüft er ständig seine Ergebnisse und bemüht sich um die Weiterentwicklung seiner selbst wie auch des Metiers.
  • Ein professioneller Softwareentwickler hat ein inneres Wertesystem.
    Anhand dieses Wertesystems prüft er seine Ergebnisse und Handlungen. Nur wenn seine Arbeit diesem Wertesystem entspricht, empfindet er sie zufriedenstellend. Sein Streben ist es daher, auch unter widrigen Umständen, unter Druck von Kunden oder Herstellern, diesem Wertesystem treu zu sein.

Softwareentwicklung - eine Handwerkskunst?

Die Frage, ob die Softwareentwicklung als Handwerkskunst anzusehen ist ausführlich zu behandeln, würde einen eigenen Beitrag verdienen. Trotzdem möchte ich für ein besseres Verständnis kurz auf die Thematik eingehen. Die Software Craftmanship Bewegung verfolgt den Ansatz nach welchem die Softwareentwicklung nicht nur ein Ingenieurwesen ist, sondern auch eine Handwerkskunst darstellt. Sehen wir uns verschiedene Interpretationen des Begriffs Kunsthandwerk an. Ihr werdet viele Parallelen zu den Berufen in der Softwareentwicklung finden:

Kunsthandwerk steht für jedes Handwerk, für dessen Ausübung künstlerische Fähigkeiten maßgebend und erforderlich sind. Die Produkte des Kunsthandwerks sind in eigenständiger handwerklicher Arbeit und nach eigenen Entwürfen gefertigte Unikate (Autorenprodukte)....

Der Begriff Kunsthandwerk hebt - im Vergleich zur Kunst - das handwerkliche und technische Interesse hervor....

Genau diese Fähigkeiten sind es, die mit CCD systematisch vermittelt werden. Denn ein fortgeschrittener Entwickler setzt die erlernten Techniken und Entwurfsmuster kreativ ein, um in der jeweiligen Situation die bestmögliche Lösung zu finden. Somit ist jede Applikation ein Unikat das durch die kreativen Fähigkeiten einer oder vieler Entstanden ist. Es mag für manche schwer sein, den Zusammenhang zwischen dem Begriff "Kunst" und der Tätigkeit des Softwareentwicklers zu sehen. Die folgende Definition von Kunst sollte euch aber dabei behilflich sein:

Das Wort Kunst (lateinisch ars, griechisch téchne) bezeichnet im weitesten Sinne jede entwickelte Tätigkeit, die auf Wissen, Übung, Wahrnehmung, Vorstellung und Intuition gegründet ist....

Im engeren Sinne werden damit Ergebnisse gezielter menschlicher Tätigkeit benannt, die nicht eindeutig durch Funktionen festgelegt sind....

Spätestens jetzt sollten die Gemeinsamkeiten ersichtlich sein. Aber auch in der personellen Organisation von Handwerkskünsten können Parallelen erkannt werden.

Wieder einmal bemühe ich einen Vergleich, der mir aber sehr passend erscheint. Wenn wir uns die verschiedenen Rollen in den mittelalterlichen Bauhütten und Handwerkslogen anschauen, werden wir schnell die Gemeinsamkeiten mit der Softwareentwicklung feststellen:

Der Architekt einer Kathedrale ähnelt in seiner Kernfunktion dem Softwarearchitekten. Hier stehen der Entwurf mit all den möglichen Berechnungen sowie die Planung der funktionalen Anforderungen im Vordergrund. Auch sollte der Softwarearchitekt die Umsetzung begleiten, um bei Bedarf den Entwurf aufgrund von neuen Erkenntnissen, die man während der Umsetzung gewinnt, abändern oder erweitern zu können (Hier zeigt sich der agile Gedanke das der Plan der Realität zu folgen hat, sofern dies der Umsetzung dienlich ist). Dies war auch beim Bau einer Kathedrale ein ganz normaler, ja sogar notwendiger Vorgang. Der Bau-Architekt muss seinerseits seine Planung im Rahmen der Möglichkeiten durchführen. Hier ist er auf die Erfahrung der Baumeister und Gesellen angewiesen. Durch deren Rückmeldung gewinnt der Architekt mehr und mehr Wissen welche seiner Ideen realistisch umsetzbar sind. Dazu zählt nicht nur die technische Machbarkeit. Auch die Ressourcenplanung sowie der Faktor Mensch muss in den Entwürfen berücksichtigt werden. Dies ist bei der Planung einer Software nicht anders. Auch hier ist es die technische Machbarkeit, Zeit und Kosten sowie die vorhandenen Mitarbeiter, die neben den Anforderungen in die Planung miteinbezogen werden müssen.

Die Baumeister hingegen planten und realisierten die handwerkliche Umsetzung der Pläne. Diese wussten einerseits mit den architektonischen Entwürfen umzugehen, andererseits konnten sie diese theoretischen Entwürfe aufgrund ihrer Erfahrung sowie ihrem Wissen über die Handwerkskünste auf realistische Weise beurteilen. Auch wenn sie nicht mehr alle Tätigkeiten selbst ausführten, so konnten sie sich doch in die ausführenden Handwerker und ihren Aufgaben hineinversetzen. Diese Funktion ist am besten mit der eines Senior Softwareentwicklers zu vergleichen. Hier floss das Wissen über das Handwerk, die Planung von Ressourcen sowie die Fähigkeit mit seiner Erfahrung die Handwerker zu leiten in eine Funktion ein.

Die Gesellen hingegen erfüllten selbstständig die Anforderungen der Baumeister und somit im weitesten Sinne wieder die des Architekturentwurfes. Sie konnten sich voll und ganz auf ihr Handwerk konzentrieren. Hier sehen wir die Funktion des Softwareentwicklers der sich ganz und gar der täglichen Arbeit widmet. Aufgrund seiner Kenntnisse die er nach und nach umfassender entwickelt, kann er auch immer wieder den Baumeistern das benötigte Feedback über den Fortgang der Arbeiten geben.

Die Lehrlinge waren und sind natürlich noch heute die Zukunft eines Betriebes sowie der ganzen Entwicklungsbranche. Anfangs mit den einfacheren Aufgaben betraut, werden sie Schritt für Schritt in die Geheimnisse ihrer Tätigkeit eingeführt. Sie sammeln Erfahrung aber bringen auch immer wieder neue Ideen und Sichtweisen in ihre Tätigkeit mit ein. Sie garantieren die Weiterentwicklung von Prinzipien und Praktiken, die für den Fortschritt einer Handwerkskunst und des Berufsstandes notwendig sind.

Wie ihr sehen könnt findet sich diese natürliche Ordnung oder Hierarchie einer Handwerkskunst auch in der Softwareentwicklung wieder. So scheint es doch ganz natürlich das es auch Gemeinsamkeiten in der Vorgehensweise geben muss. Und wie auch in den alten Handwerkskünsten sind dies Werte, Prinzipien, Praktiken und Lernmethoden, die uns über die gesamte Berufslaufbahn begleiten.

Was war da mit dem Buch Clean Code:

Ich möchte nochmals kurz einen Blick auf das Buch "Clean Code: A Handbook of Agile Software Craftsmanship" von Robert C. Martin werfen. Da seine Erkenntnisse und Ausarbeitungen die Grundlage für das Clean Code Developer System darstellen, ist der Gedanke naheliegend das es ausreichend wäre das Buch zu lesen. Und ich möchte vorausschicken das es sich auch heute auf jeden Fall noch lohnt dieses Buch als Ratgeber für einige der Prinzipien zu benutzen! Aber um als gesamtheitliche Vorgehensweise zu gelten fehlen mir noch einige wichtige Themen. Dies wird klar, wenn wir uns den Inhalt des Buches etwas genauer ansehen. Das erste Drittel des Buches beschäftigt sich mit wichtigen Grundlagenthemen, wie zum Beispiel Naming, Functions, Comments, Formatting, Error-Handling oder 3th Party Modules. Im zweiten Drittel kommen sehr detaillierte Vorschläge zu Themen wie Unit-Tests, Classes, Systems , Concurrency und Refactoring-Strategien. Abgeschlossen wird das Buch mit Smells und Heuristics.

Aber wenn wir dies mit den Prinzipien und Praktiken des CCD vergleichen, fällt uns auf das viele wichtige Punkte fehlen. Source Code Verwaltung, Issue Tracking, statischer Code Analyse oder Continous Integration und Continous Deployment sind hier als Beispiele zu nennen. Diese Praktiken stellen heute eine unverzichtbare Hilfestellung in der Softwareentwicklung dar. Der wichtigste Punkt ist aber, dass es dem Buch an einem geordneten System für das schrittweise Erlenen der Prinzipien und Praktiken fehlt. Die Grade von CCD mit ihren Abstufungen stellen hier einen enormen Mehrwert dar. Das Prinzip des steigenden Schwierigkeitsgrades ist es, warum CCD gegenüber dem Lesen eines Buches vorzuziehen ist. Dies wird vor allem klar, wenn ihr beginnt, CCD an einem Legacy-System anzuwenden. Ihr werdet schnell feststellen das es wenig Sinn macht mit den Prinzipien des gelben oder grünen Grades zu beginnen. Zu verkettet und zu gross sind die Methoden in ihrem Umfang, zu verknotet die Klassenstrukturen um zum Beispiel das «Liskov Substition Principle» oder das «Open Close Principle» sinnvoll umsetzen zu können. Hier bedarf es eben um etwas Vorarbeit mit anderen Prinzipien wie «Singe Responsibility Principle» oder gar erst mal eine verständliche Namensgebung von Klassen, Methode und Variablen. Es braucht unter Umständen einige Zeit bevor Klassen oder ganze Module bereit für umfangreichere Refactoring-Massnahmen sind. Hier würde uns der Inhalt des Buches nicht reichen um sinnvoll und effektiv vorgehen zu können.

Trotzdem möchte ich euch dazu animieren das Buch "Clean Code: A Handbook of Agile Software Craftsmanship" von Robert C. Martin in eure Leseliste aufzunehmen. Vieles vom Inhalt hat nichts von seiner Aktualität verloren, und kann somit zu Recht als Standardliteratur für Softwareentwickler bezeichnet werden.

Werte und Lernmethode:

CCD besteht daher im Grunde einerseits aus einer Lernmethode, die sich an das agile «inspect and adapt» anlehnt, sowie aus einer Sammlung von Prinzipien und Werten. Damit sich diese in der Codearchitektur einer Software wiederfinden, werden nach und nach immer mehr Prinzipien und Methoden angewandt. Hier eine kurze Übersicht über die Werte.

  • Evolvierbarkeit
  • Korrektheit
  • Produktionseffizienz
  • Kontinuierliche Verbesserung

Wie ihr erkennen könnt, finden wir hier die Werte in den zuvor beschriebenen qualitativen Anforderungen an die Codequalität wieder. Wir werden später sehen, dass diese Werte in jedem Grad des CCD enthalten sind und sie die Motivation für die Prinzipien und Praktiken darstellen.

Wir beginnen mit einer Übersicht über die Grade des CCD-Systems:


In der Grafik ist der iterative Kreislauf, in dem diese Grade durchlaufen werden, schön zu erkennen. Die Grade bauen in Schwierigkeit aber auch in ihrem Nutzen aufeinander auf. Was in den ersten Graden als trivial erscheint, ist oft eine notwendige Vorarbeit, um die schwierigeren Prinzipien oder Praktiken durchführen zu können.

In jedem Grad befinden sich verschiedene Bausteine, die diesen Werten entsprechen. Sehen wir uns das am Beispiel des roten Grades an:


Wie man sehen kann, weist zum Beispiel das DRY-Prinzip folgende Eigenschaften auf:

  • Es kann individuell beachtet werden.
  • Es sichert einen hohen Grad an Evolvierbarkeit.
  • Es sichert einen hohen Grad an Korrektheit.
  • Es sichert die Produktionseffizienz.
  • Es ist leicht zu reflektieren, die Einhaltung des Prinzips ist prüfbar.

So wie das DRY-Prinzip berühren auch alle weiteren Prinzipien und Praktiken der verschiedenen Grade auf unterschiedliche Weise die Werte des CCD-Systems. Sie unterstützen somit die Sicherstellung der zuvor erwähnten Eigenschaften der Codequalität.

Es gibt auch Prinzipien oder Praktiken die eventuell einige Vorarbeiten oder Abklärungen auf Teamebene oder, in seltenen Fällen, auch auf anderen Ebenen eines Unternehmens benötigen. Als Beispiel sehen wir im roten Grad die Praxis Versionskontrolle (Git, SVC, RTC etc.). Diese Praktiken sollten, wenn möglich schon im Vorfeld abgeklärt werden, da sie unter Umständen Auswirkungen auf die bestehende Infrastruktur haben. Bis auf wenige Ausnahmen sind die Prinzipien oder Praktiken aber ohne weitere Aufwände einzusetzen.

Vorteile gegenüber einmalige Schulungen:

CCD bietet euch die Möglichkeit diese Eigenschaften in kleinen Schritten zu erreichen. Durch ständiges Iterieren der verschiedenen Grade verankern sich diese Prinzipien und Praktiken in den Handlungen der Teammitglieder. Dadurch entsteht innerhalb eines Entwicklungsteams auf natürliche Weise ein Qualitätsbewusstsein, das auch über eine Projektgrenze hinaus dem Unternehmen zur Verfügung steht.

Meist wird aus kostenintensiven Schulungen nur sehr wenig Nutzen für das Unternehmen und die Entwickler gewonnen, da ein einmalig vermitteltes Wissen nur selten in die tägliche Entwicklung aufgenommen wird. Somit sollten Schulungen nur als eine initiale Massnahme angesehen werden. Hier ist es so wie mit dem Lernen in der Schule: Nur wer täglich übt, was er vermittelt bekommen hat, wird dieses Wissen in entscheidenden Momenten intuitiv abrufen können.


Ich hoffe ich konnte euch einige Antworten auf die Frage geben: «Was ist CCD?», und damit euer Interesse an Clean Code Developer steigern. Im nächsten Beitrag  «Wie funktioniert CCD?» werde ich euch verschiedene einige Möglichkeiten zeigen, wie man CCD in verschiedenen Projektarten gewinnbringend etablieren kann. Weitere Beiträge werden sich den einzelnen Graden und Prinzipen im Detail widmen. Also bleibt dran und bis zum nächsten Mal!

Gerne verweise ich hier auf viele spannende Blogbeiträge zu den unterschiedlichsten Themen der Softwareentwicklung auf der Seite der adesso Schweiz AG!

Markus Wagner

Software Engineer


FollowMe