Clean Code

Druck Ikon schwarz

Clean Code erfolgreich einführen - Softwarequalität nach neuestem Stand liefern

Daniel Rietmüller

Veröffentlicht in Magazin (Technologie)

Daniel Rietmüller

Mit der Einführung von Clean Code vor rund zwei Jahren erreichte encoway eine wesentliche Qualitätsverbesserung in neuen und alten Softwareprojekten. Die unternehmensweite Einführung der Methodik ist durchaus eine Herausforderung. Diese kann erfolgreich gemeistert werden, wenn man ein paar Dinge beachtet.

Welcher Entwickler kennt das nicht: für ein neues Feature oder einen Bugfix müssen unbekannte Codestellen angepasst werden. Doch schon beim Versuch des Verstehens des vorhandenen Codes fangen die Probleme an. Wir treffen auf Code mit ungeliebten Formatierungen, auf allzu tiefe Verschachtelungen, auf Methoden über mehrere Bildschirmseiten, kryptische Benennung oder auf Zahlen ohne offensichtliche Bedeutung - kurz, wir treffen auf schlechten Code. So wird ein Großteil der eingeplanten Zeit für das Verstehen des bestehenden Codes verbraucht. Das eingeplante Budget für das Feature oder den Bug wird überschritten, die Qualität leidet, der Entwickler ist genervt und der Kunde ist unzufrieden.

“CLEAN CODE ALWAYS LOOKS LIKE IT WAS WRITTEN BY SOMEONE WHO CARES.” (MICHAEL FEATHERS) 


Auch bei encoway kannten wir bis vor zwei Jahren solche Probleme. Unsere Lösung: die unternehmensweite Einführung von Clean Code. Clean Code ist ein Feld mit vielen Fassetten. Wir haben unsere Regelungen nicht von jetzt auf gleich, sondern schrittweise eingeführt. Damit überforderten wir die Entwickler nicht und sicherten uns ihre Akzeptanz. Trotz der vorsichtigen Einführung waren einige Herausforderungen zu meistern. Die folgenden Tipps (klicken Sie auf das gewünschte Thema) basieren auf unseren Erfahrungen. Sie erleichtern den unternehmensweiten Einstieg in Clean Code. 

Clean Code praxisgerecht definieren

Clean Code hat keine einheitliche Definition, lässt sich aber im Wesentlichen auf die folgenden Eigenschaften reduzieren:

  • Leicht zu verstehen
  • Leicht zu verändern
  • Leicht zu testen
  • Funktioniert einwandfrei 

Erfüllt Code diese geforderten Eigenschaften, werden die oben beschriebenen Probleme der Vergangenheit angehören. Doch diese Eigenschaften haben den Nachteil, dass sie subjektiv sind. Für einen unternehmensweit einheitlichen und sauberen Code muss es objektivere, kontrollierbare Kriterien geben. Denn jeder Entwickler sollte den Code als sauber empfinden, egal ob er ihn selber geschrieben hat oder nicht. Bei encoway haben wir deshalb die Definition von Clean Code strikter formuliert. 

Für uns ist Clean Code ein Code, der

  • leicht zu lesen und zu verstehen ist
  • gut getestet ist
  • sich an die Coding Conventions hält
  • sich an Best Practices hält

Der Vorteil dieser Definition ist, dass mit Ausnahme des ersten Punktes, alle Eigenschaften messbar und automatisiert prüfbar sind. Dadurch stellen wir sicher, dass jede unserer Codezeilen diesem Qualitätsanspruch genügt. Ferner besteht eine objektive Grundlage von Clean Code, die in Einzelfällen nicht immer wieder ausdiskutiert werden muss.

Alle Entwickler mit ins Boot holen

Neue Qualitätsansprüche bedeuten neben den vielen Vorteilen auch eine mehr oder weniger große Umstellung für die Entwickler. Daher ist es wichtig, eine größtmögliche Akzeptanz der Methode zu erreichen. Um vom Know-how aller Kollegen und Kolleginnen zu profitieren und um Widerstände abzubauen, haben wir bei encoway die Coding Conventions gemeinsam entwickelt. Die Coding Conventions enthalten die Absprachen zu Formatierung, Benennung und zur Einhaltung von bestimmten Regeln. Für die Erarbeitung der Conventions stellten wir mehrere Vorschläge zusammen und entschieden per Voting, welche Regeln Einzug halten. 

Die so entstandenen encoway Coding Conventions sind unternehmensweit gültig. Sie sind über ein zentrales Wiki einsehbar und ermöglichen so auch neuen Mitarbeitern den schnellen Einblick und Einstieg. Darüber hinaus haben wir die Einführung der neuen Regeln mit Schulungen begleitet und tun das auch weiterhin bei Neuerungen. Mit dieser transparenten und unterstützenden Vorgehensweise stellen wir eine hohe Akzeptanz bei allen Entwicklern sicher.

Feste Integration in den Entwicklungsprozess

Das schriftliche Fixieren der Qualitätsansprüche stellt nur einen ersten Schritt dar. Denn so ambitioniert die Vorsätze der Entwickler auch sind, die Einhaltung muss konsequent geprüft werden. Sonst ist die Gefahr groß, dass der Code über die Zeit doch nicht mehr den Ansprüchen genügt. So etwas kann unbewusst, schleichend und sehr langsam von statten gehen.

Um dieser Gefahr zu begegnen, unterstützen wir die Entwickler bei der Einhaltung der Regeln mit einer Reihe von technischen Maßnahmen. Schließlich soll Clean Code die Arbeit erleichtern und nicht erschweren.

Diese Unterstützung beginnt direkt bei der täglichen Arbeit in der integrierten Entwicklungsumgebung (IDE). Jedem Entwickler wird eine encoway IDE bereitgestellt. Diese basiert auf Eclipse und beinhaltet alle benötigten Funktionen für die tägliche Arbeit. Daraus resultiert, dass der Formatter den Code entsprechend den Regeln bereits automatisch beim Speichern formatiert. Eine Nichteinhaltung der Regeln wird direkt im Codeeditor während des Codeschreibens angezeigt. Es gibt darüber hinaus eine Anbindung der IDE an unsere Infrastruktur, beispielsweise an Buildserver und Issuetracker und vieles mehr. 

Mit Hilfe dieser IDE ist die Umstellung auf die encoway Clean Code Regeln ein Leichtes und auch neue Mitarbeiter verstehen und akzeptieren unseren Qualitätsanspruch sehr schnell.

Die Unterstützung endet aber nicht am Schreibtisch des Entwicklers, sondern geht im Continuous Integration-System weiter. In jedem Build oder spätestens während der nächtlichen Builds wird überprüft, ob der Code sich an die Vorgaben hält. Ist dies nicht der Fall, bricht der Build mit einer entsprechenden Meldung ab. Auf diese Weise verhindern wir, dass schlechter Code überhaupt releast werden kann.

Kein Pardon - Zero Violations

Alle Regeln, die die Einhaltung unserer Qualitätsansprüche sicherstellen, werden über die Plattform SonarQube verwaltet. Dieses Tool hat den Vorteil, dass es eine sehr große Zahl an Regeln bereitstellt und gut in das Tooling rund um IDE und Buildserver integriert werden kann. Wir verwenden allerdings nicht die gesamte Anzahl der möglichen Regeln. Das würde bei den Entwicklern nur Kopfschütteln auslösen und sie vor unlösbare Aufgaben stellen. Man würde schnell mehrere tausend oder gar zehntausend Regelverstöße erhalten. Eine nicht beherrschbare Masse. Neue Regelverstöße würden dabei nicht weiter ins Gewicht fallen und häufig einfach hingenommen werden. Wir starteten aus diesen Gründen mit einem kleinen Regelset, das unsere grundlegenden Ansprüche abdeckt. Dieses bauten wir Schritt für Schritt aus und erreichten eine allmähliche Erhöhung des Qualitätslevels.

Im Gegenzug für diesen schrittweisen Aufbau der Regeln erwarten wir von den Entwicklern das ausnahmslose Einhalten der Regeln. Jede einzelne neue Regelverletzung führt dazu, dass der Build fehlschlägt. Dies gilt für neue wie für alte Projekte. Mit dem Unterschied, dass bei alten Projekten ein Stichtag festgelegt wird, ab dem keine neuen Regelverletzungen stattfinden dürfen. Bei neuen Projekten, die auf der „grünen Wiese starten“, wird grundsätzlich keine Regelverletzung gestattet.

Diese Zero-Violations-Policy klingt zunächst sehr hart, hat sich aber bewährt. Sie führt dazu, dass die Entwickler sehr schnell ihre typischen Fehler nicht mehr machen. Denn wenn man regelmäßig darauf hingewiesen wird, beispielsweise vollständige JavaDoc zu schreiben, dann macht man es irgendwann einfach, ohne darüber nachzudenken.

Mit Pfadfinder-Tugenden alten Code optimieren

Mit der Zero-Violations-Policy stellen wir sicher, dass neu geschriebener Code unseren Qualitätsansprüchen genügt. Doch wie soll mit altem Code umgegangen werden? Bei einer Software mit mehreren hunderttausend Zeilen Code kommen schnell mehrere tausend Regelverstöße zusammen. Diese alle auf einmal zu beheben ist wirtschaftlich nicht sinnvoll. Um alten Code dennoch nach und nach im Sinne des Clean Code zu verbessern, ist jeder Entwickler bei encoway dazu angehalten, die sogenannte „Pfadfinderregel“ anzuwenden. Diese besagt, dass man den Code sauberer hinterlassen sollte, als man ihn vorgefunden hat. 

In der Praxis bedeutet das, dass jede Regelverletzung, die bei der Arbeit an altem Code gefunden wird, ohne zu zögern verbessert wird. Solange sich der Aufwand für die Verbesserung in einem vertretbaren Rahmen hält. Auf diese Art und Weise wird der Code Stück für Stück “clean“, ohne dass aktiv viel investiert wird. Mit dieser Methode reduzierten wir beispielsweise in einem Projekt die Zahl der Regelverstöße innerhalb eines Jahres von über 8000 auf unter 4000. Unsere Erfahrung zeigt: die Pfadfinderregel funktioniert gut, wenn sie konsequent angewendet wird.

Reporting - die Tendenz nach oben zählt

In erster Linie sind die Regeln sowie das Reporting des SonarQube für die Entwickler gedacht. Ihre Arbeit wird vereinfacht und ihr Fortschritt messbar gemacht. Um Leitungsebenen wie die Abteilungsleiter praktikabel zu informieren, erhalten diese jeden Monat einen Report über alle Projekte. In diesem sind jeweils nur zwei Kennzahlen dargestellt! Dies sind die „technische Schuld“ und die „Code Coverage“. Unsere Erfahrung zeigt, dass diese Zahlen auf einem relativ abstrakten Niveau gute Aussagen über die Codequalität erlauben. Sie haben sich auch deswegen als sinnvoll herausgestellt, da die Angabe von spezifischeren, detaillierteren Kennzahlen zu Fehlinterpretationen und zu Fehlsteuerungen geführt hatten.

Dabei wird nicht die absolute Höhe der Kennzahlen betrachtet, sondern ihre Entwicklungstendenz über die Zeit: Bewegen sie sich kontinuierlich in eine positive oder negative Richtung? So lassen sich Entwicklungen verschiedener Projekte miteinander vergleichen. Bei ausgeprägt negativen Tendenzen, für die es keine guten Gründe gibt, wird projektspezifisch reagiert.


Fazit

Mit den beschriebenen Methoden und Maßnahmen haben wir es innerhalb der letzten zwei Jahre geschafft, die Qualität unseres Codes kontinuierlich zu verbessern und auf einem hohen Niveau zu halten. Weitere positive Effekte sind eine bessere Wartbarkeit des Codes sowie zufriedenere, produktivere Entwickler.

Doch darauf ruhen wir uns nicht aus. Wir bauen unsere Regelsets ständig weiter aus und gehen neue Themen an. Zum Beispiel das Thema Mutation Coverage, um unsere Testqualität messbar zu machen.