19.05.2020
in Quality
So setzen Sie Clean Code Development in 2020 effektiv ein
Inhaltsverzeichnis
Dieser Artikel wurde ursprünglich am 13.09.2018 von Jenny Dornberger veröffentlicht und seitdem laufend aktualisiert.
Welche Regeln sollte ein „guter Programmierer“ eigentlich heutzutage berücksichtigen, um qualitativ hochwertige Software zu bauen? Mit Blick auf das Kernelement der Arbeit von Entwicklern – dem Schreiben von Quellcode – kommt mir als Content-Manager eines IT-Unternehmens, natürlich als erstes das Clean Code Development in den Sinn.
13 Jahre nach der Clean-Code-Manifest
13 Jahre nach Erscheinen des englischsprachigen Standardwerks von Robert C. Martin möchte ich nach Interviews mit unserem Entwicklerteam evaluieren, was Clean Code Development (CCD) bewirken kann und welche Hürden die Integration des Ansatzes im Alltag von Softwareentwicklern mit sich bringt.
Die Clean-Code-Prinzipien und die Typ-Frage
Klar ist: Jeder Softwareentwickler hat einen anderen Ausbildungshintergrund, unterschiedliche Vorerfahrungen, divergierende Interessensschwerpunkte und daraus resultierend andere Herangehens- und Arbeitsweisen im Laufe seiner Karriere entwickelt.
Je nach Typ, orientieren sich einige Entwickler lieber an den Code-Ratschlägen anderer und hoffen, dass sie damit durch kommen (Jesse Pinkman-Typ) oder haben als pragmatischer Macher à la MacGyver den schnellen Bugfix im Blick, ohne den perfektionistischen Anspruch zu haben gute Code-Qualität abzuliefern. Viele Entwickler streben jedoch wohl das Idealbild des „Rain Man“ an, der – wie es t3n in seiner scherzhaften Umfrage formulierte – Code atmet und mit einwandfreien Codezeilen denkbar elegant ganz einfach jedes Problem des Entwickler-Alltags in den Griff bekommt, ohne sich darauf etwas einzubilden. Gerade diese Rain Men sind es wohl auch, die als Clean Coder versuchen mehr Qualität in die Softwareentwicklung zu bringen.
Da beim Clean Code Development letztendlich jeder Entwickler selbst dafür verantwortlich ist, langfristig die Prinzipien und Praktiken für sauberen Code einzuhalten, muss er dazu bereit sein, sich ständig mit seiner eigenen Leistung und Herangehensweise auseinanderzusetzen. Eine intrinsische Motivation, sich unaufhörlich weiterzuentwickeln und offen für Neuerungen zu bleiben, ist deshalb von unschätzbarem Vorteil.
Schon 2008 scheint „agile software craftsmenship“ von so großer Bedeutung zu sein, dass Uncle Bob den Begriff im Untertitel seines Buchs „Clean Code“ nannte. Ein Software Craftsman, der mit einem gewissen Qualitätsanspruch an die Arbeit geht, findet sich heute wohl schnell in diversen Architektur-Ansätzen (DDD, SOA, Microservices…) und methodischen Vorgehensweisen (TDD, CD oder Pair-Programming…) wieder.
Folgt man der gängigen Meinung, führt bei der konkreten Code-Produktion kein Weg am Clean Code Development vorbei.
Die Vorteile von Clean Code Development – Uncle Bobs Argumentation
Unsere Entwickler berichteten mir, dass es anfangs schon gewöhnungsbedürftig war, jede Codezeile erneut mit dem Blick darauf zu überprüfen, ob nur eine Abstraktionsebene pro Methode gewählt, beschreibende Namen verwendet, Anweisung und Abfrage getrennt, Wiederholungen vermieden, optimal formatiert wurde, die Klassen klein gehalten waren etc.
Aus der Logik heraus erscheint es natürlich sinnvoll Code von Beginn an so zu schreiben, dass er verständlich und nicht zu komplex ist; dass er Austauschbarkeit erlaubt und sich selbst durch sprechende Namen erklärt. Aber auch in unserem Projekt ging mit diesem Fokus anfangs (gefühlt) eine niedrigere Produktivität einher. Dennoch glauben wir, dass sich dieses Initial-Invest langfristig gelohnt hat. Denn die Ausrichtung auf sauberes Coding geht mit klaren Handlungsanweisungen einher, die Interpretationen und Fehler weniger Raum geben und in einem sehr strukturierten Softwareentwicklungsprozess münden.
Qualitativ hochwertiger und testbarer Code kommt zudem langfristig auch Kunden und Usern zugute. Denn im Sinne der Nachhaltigkeit ist Clean Software für spätere Anpassungen und Erweiterungen besser vorbereitet und verursacht so langfristig weniger Aufwand. Statt eines Wegwerfprodukts und teuren Starts von Null, sind es langfristig nutzbare Funktionen, die Investitionssicherheit geben. Orientieren sich Entwickler schon bei den ersten Codezeilen an den Hinweisen aus dem Clean-Code-Buch, können zudem ungeplante Arbeitsumfänge durch Refactoring verringert werden und sind durch vorhandene Tests weniger fehleranfällig.
Auch wenn dauerhafte Produktivitätssteigerungen durch Clean Code Development nur schwer mess- und beweisbar sind, folgen wir Uncle Bobs Argumentation, dass die „Lebenszykluskosten eines Chaos“ langfristig zu einer Null-Produktivität in Teams führen kann, wenn man keinen Wert auf sauberen Code legt.
Wie man Clean Code in 2020 effektiv einsetzt
Clean Code kann eine Grundlage für Standards am Code bilden und in anregenden Diskussionen zur Schaffung einer gemeinsamen Qualitätsbasis dienen, die kontinuierlich verbessert werden kann. Gerade im arbeitsteiligen Alltag eines agilen, wachsenden Teams wie bei uns, ist es wichtig den Code für unbedarfte Kollegen zu optimieren, die z.B. neu im Team sind oder sich Tasks aus dem Sprint Backlog genommen haben, mit denen es zuvor wenig Berührungspunkte gab und die normalerweise einer Einarbeitung bedürfen.
Die Lesbarkeit ist aber auch für den Entwickler selbst essentiell, denn Code wird nach dem einmaligen Schreiben bei langfristig laufenden Projekten mit teilweise mit großem Zeitversatz immer wieder „neu“ gelesen und ggf. angepasst.
Eine optimierte Maschinen-Lesbarkeit sollte erst dann im Fokus stehen, wenn es wirklich Notwendigkeit wird, denn “Premature optimization is the root of all evil” (Donald Knuth, 1968)“. Dass die Performance einer Anwendung durch das Clean Code Development unter einer „Kleinschrittigkeit“ im Code Design leidet, ist für uns kein hinreichendes Argument auf den Ansatz zu verzichten.
So nehmen uns moderne Compiler heute einen Großteil der Optimierungsarbeit auf Basis von maschinenlesbarem Code ab. Das iterative Vorgehen und eine kontinuierliche Reflektion des geschriebenen Codes ist tief im Clean-Code-Ansatz verankert. Beides passt sehr gut mit agilen Vorgehensmodellen (wie z.B. Scrum) zusammen, welche wir im Team leben.
Clean Code Development innerhalb unserer Softwareentwicklung zu etablieren hat für uns aus mehreren Gründen Sinn ergeben. So planen wir unsere Open-Source-Produkte, z.B. das Cloudogu EcoSystem oder den SCM-Manager auch in den nächsten Jahren kontinuierlich durch neue Funktionalitäten zu erweitern. Bei weiteren Open-Source-Projekte an denen wir mitwirken, wie dem Smeagol Git Wiki, planen wir ebenso kontinuierliche Verbesserungen.
Clean Code Development hilft in dieser langfristigen Perspektive die Flexibilität zu wahren. Von Beginn an sauber gebaute Software kann – bei anhaltender Funktionsfähigkeit – laufend adaptiert werden, um neuen Anforderungen Stand zu halten. Die damit einhergehende steigende Komplexität bringt Herausforderungen mit sich, denen wir mit lesbarem Code effektiver begegnen können.
Wir haben hier aus eigener Erfahrung gelernt. Es macht einen großen Unterschied, ob ein einzelner Entwickler mit einer guten Idee und einem kleinen Produkt, das er „wie seine Westentasche“ kennt, Anpassungen macht oder ob man versucht in einem stetig wachsenden Entwicklungsteam eine komplexe Plattform mit immer mehr Features für eine wachsende Nutzerzahl zu schaffen.
Individuelle Beratung für Sie
Schaffen Sie mit uns den optimalen Rahmen für erstklassige Softwareentwicklung in Ihrem Unternehmen.
Zum GitOps Consulting
Herausforderungen bei der Umsetzung von Clean Code
Wir halten es für sinnvoll und wichtig, sich die Best Practices des Buchs von Robert C. Martin im Alltag regelmäßig zu vergegenwärtigen und auf diese als akzeptierte Referenz zurück zu greifen. Dennoch glauben wir, dass Abhaklisten und strikte Prinzipen-Pocherei die Motivation eher bremsen, da nicht alle Regeln stur auf jedes IT-Projekt und jede Situation angewendet werden können.
Wirken die Praktiken restriktiv und werden verbohrt von oben durchgedrückt, wird die Clean-Code-Idee scheitern. So gibt es Pauschalisierungen im Buch, die mit Vorsicht zu genießen sind. Beispielsweise werden Kommentare an einigen Stellen als nicht wünschenswerter „smell“ stigmatisiert. Das spielt schreibfaulen Entwicklern zwar in die Karten, bei komplexeren Sachverhalten und Hintergründen, die man nun einmal nicht in selbstredendem Code ausgedrückt werden können, sind Kommentare aber durchaus notwendig und sinnvoll. In einem wertvollen Blogbeitrag zu diesem Thema rät der Autor Anfängern sich beim Kommentieren nicht auf das „was“, sondern das „warum“ zu konzentrieren und zu erläutern warum man die Codezeilen gerade so und nicht anders geschrieben hat.
Clean Code Best Practices
Im Cloudogu-Team haben wir die Ideen und Hinweise des Teams um Robert C. Martin durch viele kleine Maßnahmen in unseren Entwicklungsalltag eingebunden. So ist die Print-Version des Bestsellers wahlweise im amerikanischen Original oder auf Deutsch Teil unseres Welcome Packages für neue Mitarbeiter. Der impliziten Anregung es auch zu lesen und sich damit (ggf. als Wiederholung) auseinander zu setzen, kommen neue Teammitglieder in der Einarbeitungsphase meist gern nach. So wird die Zeit bis zur festen Einbindung in die Sprintplanung sinnvoll genutzt.
„Als neues Teammitglied lese ich gerade in meiner Einarbeitung deutlich mehr Code, als ich schreibe“, meint auch René Pfeuffer. „Der bei Cloudogu gelebte Clean-Code-Ansatz mündete in Codezeilen, die ich von Anfang an gut lesen konnte. Das hat mir wirklich geholfen mich in das neue, doch recht komplexe Produkt einzuarbeiten und nun selbst aktiv zu werden.“
Im agilen Alltag haben wir darüber hinaus Peer Reviews fest in unsere Entwicklungsprozesse eingebettet. Am Ende jeder Story wird jede Zeile neugeschriebenen Codes von „einem fremden Paar Augen“ auf Lesbarkeit geprüft und potenziell „unsauberer“ Code mit dem Autor besprochen und refactored. Da das Ergebnis des Reviews von Erfahrung des Reviewers abhängt, bieten die Clean-Code-Prinzipien hier eine solide Grundlage, die sich jeder relativ schnell aneignen kann. So wird das alltägliche Coden innerhalb des Teams kontinuierlich verbessert.
In Clean Code ist Unit Testing eine Selbstverständlichkeit. Vorhandene Unit Tests sind bei der Entwicklung wertvoll, da sich darin neu geschriebener Code isoliert ausführen und viele Ausführungspfade durchlaufen lassen. Der besondere Nutzen von vorhandenen Tests zeigt sich dann aber bei der Wartung: Nach Erweiterungen oder Refactorings stellen diese als automatische Regressionstests sicher, dass vorhandene Funktionalität nicht beschädigt wurde.
Auch bei Cloudogu haben wir den langfristigen Nutzen erkannt, weshalb sich die Frage nach Unit Tests bei uns nicht stellt. Ob diese test-driven oder nach der Implementierung geschrieben werden, kann jeder Entwickler im Einzelfall entscheiden. Erfahrungsgemäß führen aber das Schreiben von Testfällen vor der Entwicklung zu besserer fachlicher Abdeckung.
Zusätzlich zum Unit Testing laufen bei uns statische Code-Analysen, die Best Practices im Code verifizieren und gängige Fehlermuster identifizieren. Die Metriken aus der statischen Code-Analyse fließen zusammen mit den Ergebnissen der Unit Tests und der Code Coverage in eine zentrale Platform ein. Dort werden diese Metriken gegen ein Quality Goal verifiziert (z.B. sollte die Code Coverage >= 80% sein). Nur wenn dieses eingehalten wird, sehen wir eine Story als „Done“ an.
Wir bei Cloudogu haben uns für SonarQube entschieden, da es entsprechend unserer eigenen Philosophie Open Source ist und wir darin unsere verschieden technologischen Umfelder (Java, JavaScript, Go, etc.) einheitlich abbilden können. Darüber hinaus nutzen wir regelmäßige Ad-hoc-Schulungen zum Thema Clean Code in unseren „Knowledgebase-Meetings“, um konkrete Codezeilen im Team zu diskutieren und uns auf gemeinsames Vorgehen zu einigen. Last but not least wird natürlich unser agiler Entwicklungsprozess nach jedem Sprint in der Retrospektive weiter optimiert.
Unser Fazit
Um die langfristigen Vorteile zu nutzen, die Clean Code Development bringen kann, sind sowohl die individuelle Grundeinstellung zu Eurer täglichen Arbeit, als auch das Team-Committment und die Disziplin, die Anpassungs- und Lernbereitschaft aller Beteiligten ausschlaggebend.
Wir sehen im Clean Code Development einen „Implementierungsansatz“ direkt am Code, der, ergänzt um agile Methoden und ein Security Konzept der richtige Weg ist, um qualitativ hochwertige Software zu produzieren.
Schon der Diskurs im Team darüber, was genau im konkreten Fall unter „sauberer“ Software zu verstehen ist, ist wertvoll. In der Umsetzung des Ansatzes hilft es viele intrinsisch motivierte Software Craftsmen im Entwicklungsteam zu haben, die das Vorhaben nicht nur mittragen, sondern engagiert voran bringen. In unserem Verständnis sollte der Prinzipien-Reiterei allerdings eine gezielte Einbettung der Best Practices aus dem Standardwerk in die täglichen (agilen) Alltagsprozesse weichen.
Jetzt Newsletter abonnieren
Verpassen Sie nicht die neusten Informationen zur Digitalen Transformation, Ankündigungen von Produktneuheiten und Sonderaktionen.
