Clean Code: Der heilige Putzlappen für mehr Softwarequalität?
Clean Code gilt seit vielen Jahren als Lösung für gesteigerte Softwarequalität. Allerdings sind sich Entwickler auch heute oft nicht einig, was genau einen guten Quelltext ausmacht und wie sich eine hohe Softwarequalität bewerten lässt. Das Problem ist in jedem Projekt dasselbe: Softwarequalität sinkt kontinuierlich, wenn sie konsequent ignoriert wird.
In diesem Artikel möchte ich erläutern, wie es zu Qualitätsproblemen in Softwareprojekten kommt, wie Clean Code dabei helfen kann und wie es in einem Team eingesetzt werden kann. Starten wir mit einem Beispiel aus einer anderen Branche, um zu verdeutlichen, was in einem Softwareprojekt passiert.
Vor 3 Jahren war noch alles in Ordnung…
Sie sind neuer Koch in einem Restaurant. An Ihrem ersten Tag starten Sie in der Küche, welche einem Schlachtfeld gleicht. Hier stapeln sich ungespülte Teller und Töpfe, ein Gericht brennt im Ofen an und neue Bestellungen kommen rein. Die anderen Köche hängen der Arbeit hinterher. Jetzt sollen Sie aushelfen, damit das Chaos wieder unter Kontrolle gebracht wird.
Auf Nachfrage, was in dieser Küche passiert ist, erhalten Sie folgende Antwort: "Vor 3 Jahren war alles in Ordnung. Wir durften das Equipment und alle Geräte selbst aussuchen. Außerdem haben wir diese Küche nach unseren Wünschen und dem besten Gewissen gestaltet. Doch nach ein paar Monaten wurde uns bewusst, dass wir mehrere Fehlentscheidungen getroffen haben. Hinzukommt, dass wir nicht bedacht haben, dass eine Vielzahl exotischer Kundenbestellungen eingehen. Dadurch lassen sich die vielen Bestellungen nicht mehr zeitlich abarbeiten. Jedoch müssten wir uns Zeit nehmen, die Küche richtig zu säubern und unseren Workflow auf die wichtigsten Bestellungen zu optimieren. Allerdings möchte der Besitzer keine Investitionen mehr machen, da er nicht daran glaubt, dass sich die Situation dadurch verbessert. Zwei Köche haben bereits mit der Kündigung gedroht, sollte sich die jetzige Situation nicht verbessern."
Fehlentscheidungen, fehlende Zeit für Qualitätsmaßnahmen sowie unzufriedene Fachleute. Kommt Ihnen das bekannt vor? Die Auswirkungen in einer Küche sind an der mangelnden Hygiene sowie weniger zubereiteten Gerichten leicht erkennbar. Diese Küche möchte niemand seinen Gästen präsentieren. Wie sich dieses Problem in einem Softwareprojekt äußert und wie es gelöst wird, werden wir nachfolgend beleuchten.
Wieso wird Software "schlecht"?
Außenstehende sind oft erstaunt, wenn Entwickler nach Projektstart eine vollständige Applikation innerhalb von wenigen Tagen aufsetzen und zum Laufen bringen können. Jedoch wundern sie sich, wenn nach einem halben Jahr bspw. eine Sortierung für eine Listenansicht eingepflegt werden soll und für dieses Feature drei Monate Entwicklungszeit veranschlagt wird. Wie kommt dieses Problem zustande?
In den ersten Tagen wurden viele Entscheidungen getroffen. Es wurden Bibliotheken gewählt, die Architektur wurde aufgebaut und die Geschäftslogik wurde implementiert. Nach der Alphaversion ging es an die Feinheiten. Hier wurden ein paar Bugs ausgebügelt, Performance-Probleme behandelt und kleine Änderungen an den Anforderungen nachgebessert. Die erste Version der Software konnte so schnell live gehen.
Technische Schulden sind das Pendant zu einer verdreckten und unhygienischen Küche.
Nach der ersten lauffähigen Version folgen die nächsten Arbeiten, wie bspw. neue Features, neue Bugs und Security-Themen. Für sauberes Testing und Code-Reviews bleibt in diesem Fall keine Zeit. Dabei ist es in dieser frühen Phase wichtig, einen ständigen Überblick über die Codequalität zu haben. Entscheidungen, die langfristige Auswirkungen haben, sind hier bereits zu hinterfragen, denn mit jeder Änderung des Quelltextes steigt die Komplexität kontinuierlich.
Während ein ungeschultes Auge in einer Küche sehen kann, wie sich das Chaos ausbreitet, macht sich das Softwareprojekt-Chaos erst nach einem längeren Zeitraum und bei vermehrtem Auftreten von Bugs bemerkbar. Die Folge ist eine sinkende Softwarequalität bei zunehmenden sogenannten technischen Schulden (Technical Debt). Technische Schulden sind das Pendant zu ungespülten Tellern und Töpfen, die sich im Arbeitsbereich stapeln. Wenn sich niemand darum kümmert, kann bald keiner mehr arbeiten.
Entwickler sind dafür verantwortlich, ihren Arbeitsbereich – nämlich den Quelltext – sauber zu halten, damit langfristig daran gearbeitet werden kann. Kein Stakeholder hat langfristig einen Vorteil davon, wenn die Softwarequalität durch technische Schulden leidet. Denn Software, die in Benutzung ist, unterliegt immer neuen oder geänderten Anforderungen, sei es durch Kundenwünsche oder Fehlentscheidungen.
Ein neues Feature soll entwickelt werden. Die Entwickler entscheiden, das Modul neu zu schreiben und vergessen dabei eine Anforderung, die nicht dokumentiert war. Dadurch wird das System für zwei Tage lahmgelegt und das gesamte Team hat eine Woche Arbeit mit den Nachwirkungen. Wer sich nach so einer Situation nicht der Qualitätssicherung widmet, wird mit den Auswirkungen ständig Probleme haben.
Egal welcher Stakeholder, Menschen machen Fehler und diese belasten die Qualität einer Software. Damit also die Software langfristig weiterentwickelt werden kann, müssen technische Schulden abgebaut und die Komplexität unter Kontrolle gehalten werden. Das funktioniert nur durch kontinuierliche Optimierung des Quelltextes. Und dafür bietet Clean Code notwendige Ratschläge und Leitlinien.
Warum hilft Clean Code bei sinkender Softwarequalität?
Clean Coding ist mittlerweile ein weiter verbreiteter Begriff und wurde unter anderem durch das Buch "Clean Code" von Robert C. Martin bekannt [1]. Ein wichtiger Punkt beim Clean Coding ist die Tatsache, dass man Code lesen muss, um neuen Code schreiben zu können. Das Verhältnis liegt dabei bei ungefähr 1 zu 10.
Für 10 Zeilen Code müssen ungefähr 100 Zeilen Code gelesen und verstanden werden. Sind diese 100 Zeilen unleserlich sowie unverständlich programmiert, ist der Aufwand für 10 Zeilen Code weitaus höher als bei intuitiv verständlichem Quelltext. Das Ziel von Clean Code ist, intuitiv verständlichen und lesbaren Quelltext zu erstellen, um damit gegen steigende Komplexität im Projekt anzukämpfen und die Softwarequalität aufrecht zu erhalten. Clean Code bedeutet nicht, dass Variablen und Methoden ausschließlich mit entsprechenden Namen ausgestattet werden, obwohl auch das ein wichtiger Bestandteil von Clean Code ist.
Wie produziert man Clean Code?
Wie bringt man Entwickler dazu, guten und sauberen Code zu schreiben? Man zeigt Ihnen eine fertige Lösung. Nach 3 Tagen werden diese Entwickler zerstritten ihre Lösung präsentieren.
Beim Erstellen von Software gibt es sehr viele Aspekte, die man beachten kann. Als Entwickler kann man da leicht den Überblick über die ganze Technologielandschaft verlieren. Während ein Entwickler sich auf Sprachfeatures spezialisiert und diese gerne verwendet, arbeitet ein anderer Entwickler bevorzugt mit fertigen Bibliotheken, um sich Arbeit zu sparen. Unabhängig davon, wie ein Feature implementiert wird, gilt es, die Anforderungen zu erfüllen.
Egal ob Sprache, Technologie, Bibliothek oder Programmierparadigma, es gibt fast immer eine bessere Lösung für ein bereits gelöstes Problem. Selbst wenn der Code aufs letzte Bit optimiert ist, wird es einen Entwickler geben, der es anders machen würde. Eine Zeile mehr, oder eine Zeile weniger.
Das ist ein idealer Anfangspunkt für Clean Coding, denn einer der wichtigsten Aspekte ist die Kommunikation. Entwickler sollten Code schreiben, um Anforderungen zu erfüllen und um anderen Entwicklern ihre Lösungsansätze sowie Denkweisen zu kommunizieren. "Die einzig richtige" Lösung für eine Anforderung gibt es nicht.
Clean Code hilft dabei, eine gemeinsame Basis für die Kommunikation zu legen, um damit eine höhere Softwarequalität zu erlangen. Folgende Bereiche sind beim Clean Coding wichtig:
- Coding-Regeln,
- Refactoring,
- Automatisierte Tests,
- Code Reviews und
- Aufwandsschätzungen.
Nachfolgend gehen wir ausführlich auf die einzelnen Bereiche ein.
Coding-Regeln
Die einfachste Form von Clean Code ist intuitiv verständlicher Quelltext. Ich möchte auf ein paar bedeutende Themen eingehen.
Selbstdokumentierender Code: Verständlicher Name in Variablen, Methoden, Funktionen, Klassen und Modulen. Dies hilft dabei, den Quelltext sprechender zu gestalten und gleichzeitig Dokumentationsaufwand zu minimieren. Nachfolgendes Beispiel verdeutlicht diesen Punkt.
Beispiel: Welchen Zweck hat die Variable?
String ws[] = s.split(" ");Auch wenn der erfahrene Programmierer erkennt, dass hier ein String in ein Array aufgeteilt werden soll, ist es ohne Kontext sehr schwer zu erkennen, welche Art von fachlichen Daten hier bearbeitet werden soll.
Beispiel: Welchen Zweck hat die Variable? (Verbesserte Variante)
String words[] = text.split(" ");Am obigen Beispiel wird sofort klar, dass Worte aus einem Text extrahiert werden. Die Logik ist dieselbe, wie im Beispiel davor. Selbstverständlich werden viele Entwickler auch in der verbesserten Code-Variante weitere Optimierungen finden, dazu später mehr.
Größe und Struktur von Code-Konstrukten: Wenn ich Ihnen diesen Artikel ohne Zwischenüberschriften und Absätze, quasi als reinen Blocktext vorlegen würde, hätten Sie höchstwahrscheinlich nicht bis zu dieser Textstelle gelesen. Wie bei einem Text darf auch Quelltext sauber strukturiert sein. Klassen, so groß, dass man diese leicht überblicken kann, Methoden so klein, dass deren Funktionalität schnell begreifbar ist. Dafür lohnt es sich, lieber mehrere Methoden und Klassen zu schreiben oder eine Zwischenvariable einzuführen, auch wenn diese für die Funktionalität nicht notwendig wären.
Kommentare: Da Kommentare – so wie eine Dokumentation – gepflegt werden müssen, gibt es Kommentare, die man sich sparen sollte. Die Wahrheit liegt nun mal im Code. Durchaus gibt es viele nützliche Kommentare. Ein Kommentar welcher vor einem deaktivierten Test warnt, dass der Test 30 Minuten dauert, spart einem Entwickler potenziell 30 Minuten Aufwand.
Formatierung: Hier geht es nicht um die Diskussion, ob Tabs oder Spaces verwendet werden sollten, sondern darum, ein einheitliches Format im Projekt zu verwenden. Sobald das erfolgt ist, erledigt die Entwicklungsumgebung diese Aufgabe. Das ist Zeit, die jeder Entwickler besser investieren kann.
Das sind nur vier grobe Themen, die als Coding-Regeln in einem Projekt Verwendung finden können. Diese Regeln sind keine Gesetze, sondern Vorschläge von erfahrenen Entwicklern. Wer diese Regeln kennt, hat eine Wissensbasis geschaffen, auf die er im Projekt aufsetzen kann. Welche konkreten Regeln ins Projekt tatsächlich übernommen werden, ist sicherlich eine Teamaufgabe. Dieses Thema sprechen wir in Kürze separat an. Die aufgezeigten Coding-Regeln helfen aber beim initialen Schreiben der Software und auch beim Lesen sowie Überarbeiten des Quelltextes. Bei der Überarbeitung spricht man von "Refactoring".
Refactoring
Damit Clean Code entsteht, muss zunächst Code existieren. Jeder Entwickler wird dabei unabhängig von seiner Erfahrung oder seinem Projektverlauf schlechten Code schreiben. Nicht weil er dem Projekt schaden will, sondern weil es externe Einflussfaktoren notwendig machen. Das bedeutet, dass ein Refactoring fast immer in die Entwicklung eingeplant werden sollte. Es gehört zum Prozess der Entwicklung.
Refactoring bedeutet, die Struktur und Lesbarkeit des Codes zu verändern, ohne das Verhalten der Anwendung zu beeinflussen. Auch hier ist das Ziel intuitiv verständliche Software. Die Coding-Regeln helfen dabei als Orientierung, was eigentlich optimiert werden sollte. Doch wie bekommt man eigentlich heraus, ob der eigene Quelltext überarbeitet werden sollte? Als Entwickler hat man selbstverständlich bereits die beste Version, frei von jeglichen Fehlern fertiggestellt!
Code Reviews
Welche Codebestandteile überarbeitet werden sollten, kann ein einziger Entwickler nur schwierig beurteilen. In einem großen Softwareprojekt ist es daher hilfreich, Code Reviews durchzuführen. Die Ausgestaltung dieser Code-Reviews kann, z. B. über Pull-Request oder sogar Pair-Programming erfolgen.
Guter sauberer Code ist subjektiv. Es gibt nie die eine richtige Lösung.
Schauen wir erneut auf ein Beispiel aus einer anderen Branche. Bücher werden vor einem Druck (also vor dem Release), etliche Male geprüft und korrekturgelesen. Ein Fehler in einem gedruckten Buch lässt sich eben nicht so einfach mit einem Hotfix patchen.
Auch wenn Entwickler mit Hotfixes Fehler ausbügeln können, weist dies in vielen Fällen auf eine mangelnde Qualität hin. Weiterhin kostet es wertvolle Zeit. Wird ein Code Review vorab durch mindestens einen weiteren Entwickler durchgeführt, dann erhöht sich die Qualität. Demnach tritt die Anforderung von Hotfixes seltener auf. Ebenso erhält der Entwickler wiederum mehr Zeit für andere Tätigkeiten.
Guter sauberer Code ist subjektiv. Es gibt nie die eine richtige Lösung. Jeder Programmierer versucht eine gute und saubere Lösung zu bauen, aber sie ist auch erst gut, wenn andere diese als gut bewerten. Mit Code Reviews kann die Qualität des Codes schrittweise erhöht werden.
Testing
Warum Testing beim Clean Coding eine der wichtigsten Rollen spielt, zeigt folgendes Beispiel: Kurz vor Release findet der Auftraggeber einen kleinen Fehler, bei dem sich herausstellt, dass die Anforderung nicht klar definiert war. Damit dieser Anforderungsfehler nicht das Release verhindert, wird die Implementierung in Rekordgeschwindigkeit angepasst und dann geht es los auf die Produktion. In einem Projekt ohne automatisierte Tests muss man hoffen, dass die Implementierung keine ungewünschten Randeffekte mit sich bringt.
Manuelle Tests bei kurzfristigen Anpassungen werden selten komplett durchgeführt. Somit bleibt immer ein Risiko, da sich mögliche Randeffekte erst nach Stunden oder nach einer gewissen Last zeigen. Die Behebung solcher Fehler kostet wertvolle Zeit, Nerven und wirkt sich negativ auf den Ruf aus.
Hingegen kann mit automatisierten Tests sichergestellt werden, dass bereits funktionierende Software, selbst nach kleinen Anpassungen, weiterhin funktioniert. Das Risiko unerwarteter Fehler sinkt dadurch signifikant. Sollten Sie automatische Tests das erste Mal in einem Projekt implementieren, reicht es aus, Tests zu schreiben, welche die Basisfunktionalität – also die Anforderungen der Software – abtesten. In einem Projekt ohne Tests können das im ersten Schritt Blackbox-Tests sein. Im weiteren Projektverlauf lassen sich die Tests verfeinern. Hier gilt es, schrittweise eine Testabdeckung zu erreichen, mit der das Projektteam sicherstellen kann, dass die Software alle Anforderungen erfüllt.
Aufwand/Zeit
Coding-Regeln, Reviews, Refactoring und Tests zu schreiben ist eine aufwändige Sache. Diese Zeit muss nicht nur eingeplant werden, sondern auch von den Entwicklern eingefordert werden. Wer hier spart, leidet später unter noch größeren Aufwendungen. Die Behebung von Fehlern nach einem Release spannt in vielen Fällen mehr Ressourcen ein als eine kontinuierliche Qualitätssicherung. Zudem erwartet der Benutzer und der Auftraggeber eine hohe Qualität, unabhängig davon, ob er diese explizit bezahlt oder nicht. In Aufwands- und Kostenschätzungen sollte dieser Posten nicht fehlen, damit die Entwickler sich für die Qualitätssicherung ausreichend Zeit nehmen können.
Wie funktioniert Clean Code im Team?
In Projekten, in denen nur ein Entwickler arbeitet, liegt es an der Disziplin dieses einen Entwicklers, wie hoch er die Qualitätssicherung seiner Software ansiedelt und den entsprechenden Clean Code produziert. Wie kann das Thema Clean Code hingegen in Projekten mit mehreren Entwicklern eingebracht werden? Einige Lösungsvorschläge möchte ich Ihnen nachfolgend aufzeigen.
Kommunikation
Kommunikation ist auch bei Clean Code und der Qualitätssicherung der wichtigste Punkt, um diese erfolgreich im Projektteam einzusetzen. Entwickler müssen einen Raum für den Austausch über den Code erhalten. Bei Clean Code gilt die Regel, dass jeder zunächst immer schmutzigen Code schreibt. Erst mit Clean Code und Code Reviews kann daraus qualitativ hochwertige Software entstehen.
Selbst der erfahrenste Entwickler wird in einem neuen Projekt Fehler machen. Deswegen ist es wichtig, dass die Kommunikation zwischen Entwicklern aufgebaut wird. Ignoriert man sie, werden Qualitätsprobleme nicht angesprochen und ggf. im Verborgenen behoben. Das kann weitere Probleme nach sich ziehen, wie bspw. eine sinkende Stimmung und gesteigerter Frust im Team. Es sollte daher üblich sein, dass Entwickler sich für eine Implementierung über ihren Code austauschen, selbst wenn kein Code Review oder Pair Programming eingesetzt wird. Entwickler müssen sich über Technologien und Lösungen austauschen. Die Kommunikation sollte dem Führungspersonal und dem Auftraggeber gegenüber transparent sein.
Wenn eine kurzfristige Anforderung einen Qualitätsmangel verursacht hat, sollte im Hinblick auf die Prozessverbesserung miteinander gesprochen werden. Es sollte allen Stakeholder deutlich werden, was die Komplexität steigert, was die Qualität senkt und wieviel Aufwand tatsächlich für bestimmte Arbeiten notwendig ist.
Verantwortlichkeit
Im stressigen Projektalltag kann das Thema Qualitätssicherung leicht in Vergessenheit geraten. Um dies zu vermeiden, sollte mindestens eine Person die Qualitätssicherung im Blick behalten und auch Aufgaben in Absprache verteilen dürfen.
Tools
Ein weiteres Mittel für den erfolgreichen Einsatz von Clean Code sowie der Steigerung der Codequalität sind Softwarewerkzeuge. Wenn eine gewisse Qualitätsstufe vorhanden ist, kann damit sinnvoll gearbeitet werden. Solche Werkzeuge können auch direkt am Anfang eines Projektes eingesetzt werden, aber in einem Legacy-Projekt sind diese nicht die erste Wahl. Ein Grund dafür ist, dass die Menge an resultierenden Aufgaben einen zu großen initialen Aufwand bedeuten würde.
Die einfachsten Werkzeuge kennt bereits jeder Entwickler. Darunter befinden sich Compiler-Warnings, CheckStyle, Sonar und Linter. Diese statischen Code-Analysetools kennen fast alle wichtigen Regeln zur Einhaltung und Verbesserung der Codequalität. Sobald ein gewisser Reifegrad an Qualität erreicht ist, kann im Projekt definiert werden, dass ein Deployment oder ein Git-Push verhindert wird, sobald gewisse Regeln verletzt werden. Reports und Metriken dieser Tools geben nicht nur Hinweise zur Steigerung der Qualität, sondern ermöglichen die Messung der Codequalität.
Weitere Tools sind Pair Programming, Test-Driven Development und Domain-Driven Design. Welche davon sinnvoll sind, sollte im jeweiligen Projekt entschieden werden.
Weiterbildung
Softwareentwicklung kann auf vielen Wegen, Technologien, Programmiersprachen und Bibliotheken erfolgen. Entwickler und Projekte haben eigene Vorlieben und Vorgaben. Das technische Umfeld im Projekt muss von jedem Entwickler beherrscht werden, damit eine hohe Qualität erreicht werden kann. Ansonsten können Fehler auf verschiedenen Ebenen erfolgen: Fachliche Fehler, technische Probleme und sogar Sicherheitslücken sind dann vorprogrammiert.
Lesbarer Code ist wartbarer Code.
Aus diesem Grund ist die ständige Weiterbildung für die Softwarequalität äußert wichtig. Speziell für Clean Code gibt es Onlinekurse und Workshops. Am besten bildet sich das Team hier im Ganzen weiter und arbeitet dann aus, wie eine hohe Qualität im Projekt erreicht werden kann.
Fazit: Ist Clean Code die Lösung aller Qualitätsprobleme?
Die Regeln von Clean Code zu kennen hilft, saubereren Code zu schreiben. Allerdings ist sauberer Code subjektiv. Aus diesem Grund ist er immer mit zusätzlichen Maßnahmen verbunden. Entwickler sollten sich über ihren Quelltext austauschen, was nur dann gelingt, wenn es im Team einen Konsens für sauberen Code gibt.
Wie die genaue Umsetzung im konkreten Projekt aussieht, kann ebenfalls von der bekannten Literatur abweichen. Es hilft allerdings, die Regeln und die Ideen hinter Clean Coding zu kennen und zu verstehen: Lesbarer Code ist wartbarer Code. Automatisierte Tests sowie Code-Reviews verringern Aufwände und Fehler. Es geht nicht darum, eine Stunde über einen Variablennamen zu diskutieren oder ein aufwändiges Refactoring durchzuführen. Das Ziel ist wartbare und intuitiv verständliche Software zu produzieren. Die Softwarekomplexität sollte reduziert werden, indem der Entwickler aufräumt und testet.
In der Praxis bewährt sich das schrittweise Vorgehen, wenn Clean-Code-Maßnahmen implementiert werden sollen. Hingegen ist es weniger hilfreich in Extremen zu denken, wenn eine hilfreiche Lösung entstehen soll.
Wie wir gelernt haben, ist Clean Code kein Regelwerk für perfekte Software. Clean Code zu lernen und anzuwenden hilft bei der Verbesserung der Codequalität und vor allem der Kommunikation. In jedem Fall sollten Sie sich Zeit für Clean-Coding-Themen nehmen, um unnötigen Frust und Stress im nächsten Software-Projekt zu vermeiden.
