Blogpost vom 09. Januar 2019
Clean Code. eine saubere Sache
Kennen Sie das? Eine Applikation, die seit vielen Jahren verlässlich ihren Dienst tut, braucht plötzlich an einer Stelle des Codes ein Security-Update. Ausgerechnet die Software, bei der die Dokumentation seit den letzten Releases etwas vernachlässigt worden ist; die Software außerdem, deren ursprüngliche Entwickler schon gar nicht mehr verfügbar sind. Was also tun Sie?
… Sie packen sich den besten Softwareentwickler, den Sie finden können, und setzen ihn an das nötige Update. Dieser allerdings hat den Quelltext noch nie gesehen. Was denken Sie, wie teuer seine Änderung sein wird? Zählen Sie einfach seine Kraftausdrücke mit, denn jede einzelne von ihnen ist ein Indikator für die Höhe der entstehenden Kosten.
Nicht begeistert? Kann ich mir denken. In diesem Artikel erfahren Sie, wie das Prinzip Clean Code Sie vor diesem Schicksal bewahrt.
Empfehlung für Softwareentwickler: Hier der JUGH-Talk zum Thema Clean Code mit Arkadius Roczniewski.
Warum Entwickler immer mit dem Code schimpfen
Zunächst klären wir, warum Entwickler schimpfen, wenn sie „schlechten“ Code sehen, und warum dieser den Aufwand erhöht. Stellen Sie sich vor, Sie ziehen 4 Mal im Jahr in das Büro eines Kollegen um. Sie haben dabei max. eine halbe Stunde Zeit, um Altlasten zu beseitigen, Möbel zu rücken und Unterlagen einzusortieren. Was wünschen Sie sich also? Richtig, dass Ihnen nämlich ein möglichst aufgeräumter Arbeitsplatz übergeben wird! Genauso geht es dem Softwareentwickler bei der Übernahme eines ihm noch neuen Quellcodes. Wenn er wenig Zeit hat, läuft er sonst Gefahr, das Chaos seines Vorgängers nicht nur weiter mitzuschleppen, sondern zu verschlimmern.
Was ist die Lösung? Ein aufgeräumter Code! Softwareentwickler bezeichnen dies als sauberes Programmieren oder auch als Clean Code.
Was ist „schlechter“ Code und wie entsteht er?
In langjährigen Projekten mit wechselnden Entwicklern entsteht „schlechter“ Code immer dann, wenn zu wenig Budget für Qualitätsmaßnahmen bzw. Refactoring eingeplant wurde und die Zeit bis zum Release knapp bemessen ist. Dann kümmern sich Entwickler nämlich nur darum, die an sie gestellten Anforderungen umzusetzen und im besten Fall noch per Unittests abzusichern. Bugfixes und Updates werden zwar auch nach dem Release noch eingepflegt, aber dann geht es auch schon weiter mit dem nächsten Release oder sogar mit einem anderen Projekt. Gute Entwickler fordern deshalb zu Recht ein Redesign bzw. Refactoring, denn auf einer unaufgeräumten Baustelle können sie nur schlecht arbeiten, der Aufwand für das nächste Release steigt. Quelltext, der nicht nach dem Prinzip des Clean Code gepflegt wird, gilt deshalb als „schlechter“ Code.
Es gibt Antipattern, die zu schlechtem Code führen und die wir in moderner Software unbedingt vermeiden wollen. Clean Code beschreibt dabei nicht nur, wie der Quelltext zu strukturieren ist, auch Funktionsweisen und Architektur können clean gestaltet werden.
Schreibe deinen Code so, als wäre der Typ, der ihn verstehen muss, ein Psychopath mit einer Axt, der weiß wo du wohnst.
Saubere Software ist mehr wert
Der Einsatz von Unternehmenssoftware hat meistens wirtschaftliche Gründe, ist diese doch in vielen Fällen ein kritischer Erfolgsfaktor. Entsprechend gut sollte sie gepflegt sein. Je nach Einsatzdauer und wirtschaftlicher Kritikalität der Anwendung sollte man deshalb genug Entwicklungsbudget für sauberen Code einplanen.
Die Wahrheit liegt im Quellcode
Softwareentwickler sind Autoren. Wenn sie etwas schreiben, wollen sie, dass es gelesen wird. Ihr Glück: Bei Quelltext ist dies zwangsläufig der Fall. Denn wenn wir eine Implementierung an einer bestehenden Applikation vornehmen wollen, müssen wir uns zunächst einarbeiten. Fehlende Dokumentation und Tests erschweren den Aufwand, aber auch wenn es eine Dokumentation und passende Testfälle gibt: Die eigentliche Einarbeitung beginnt erst, wenn wir den Quelltext durchsuchen und die Anwendung das erste Mal selbst kompilieren bzw. starten können. Wir verschaffen uns also zunächst einen Überblick und suchen die Stelle heraus, wo die Implementierung erfolgen soll. Für diesen Prozess müssen wir viele Zeilen Quelltext lesen und verstehen. Man sagt, das Verhältnis zwischen gelesenem und geschriebenem Code ist 1:10; für 10 geänderte Zeilen müssen folglich 100 Zeilen gelesen und verstanden werden.
Wenn nicht nach dem Prinzip Clean Code gearbeitet wird, ist der Aufwand enorm, diese 100 Zeilen zu verstehen, und das Risiko, bestehende Funktionalität zu zerstören, ist hoch.
Ein solcher Code ist schlicht nicht wartbar – das ist der Punkt, an dem wir Entwickler zu schimpfen beginnen.
Leseempfehlungen zum Thema Softwarequalität: Software Craftsmanship, Refactoring und Pragmatismus in der Softwareentwicklung.
Lesbaren Code produzieren
Wer Clean Code programmiert, bemüht sich darum, leicht lesbaren Quelltext zu schreiben. Code, der sich selbst dokumentiert und von einem anderen Entwickler schnell zu verstehen ist. Mit Clean Code erzeugen wir also wartbare Software, die auch nach vielen Jahren noch für ganz andere Menschen lesbar ist. Wartbare Software mindert das Risiko und ist damit ein kritisches Erfolgskriterium.
Wie so oft lernt man auch hier am besten durch den eigenen Schmerz. Um lesbaren Code überhaupt schreiben zu wollen, haben die meisten von uns vorher schlechte Erfahrungen mit unlesbarem Code gemacht – durchaus auch mit dem eigenen, von dem man Wochen später schon nicht mehr wusste, warum man ihn eingangs für brilliant gehalten hat; geblieben ist nur ein Dickicht aus Quelltext – undurchschaubar, verwirrend und rätselhaft. Jede Änderung bringt plötzlich das Programm zum Absturz und man hat keine Ahnung mehr, wie das Modul überhaupt mal funktionieren konnte.
Clean Code von Anfang an
Wer mit Clean Code startet, dem kann eine alte Pfadfinderregel als Vorbild dienen: „Verlasse den Feuerplatz immer sauberer, als du ihn vorgefunden hast“. Heißt: Wenn du Quelltext gelesen und geändert hast, räum auf, bevor du gehst! Kleiner Bonus dabei: Das Refactoring hilft auch dir beim Verständnis!
Neben dieser Regel gilt beim sauberen Programmieren außerdem: „Richte keinen Schaden an“. Das bedeutet, dass du bei jeder Änderung wissen solltest, ob die Funktionalität und die Struktur der Anwendung anschließend noch intakt ist. Teste sie! Wenn eine Anwendung schwer zu testen ist, ist das übrigens ein Indikator für unsauberes Design – oft wird in solchen Fällen dann nur das geändert, was geändert werden muss, da keine Zeit für ein größeres Refactoring ist. Das ist eine grundlegende Ursache, warum die meisten Softwareprojekte mit der Zeit unwartbar werden und mit steigenden Kosten zu kämpfen haben. Deshalb gilt beim Clean Code: Testen ist wichtig. Nur wer testet, kann sauber programmieren. Am besten, wir schreiben unsere Tests noch VOR der eigentlichen Programmierung: Was soll die Software können, wenn es fertig ist?
Überblick Clean Coding
Eine der wichtigsten Regeln bei Clean Code ist das Thema der Namensgebung. Im Quelltext wird alles benannt: Dateien, Module, Klassen, Methoden, Funktionen und Variablen. Heutzutage ist es nicht mehr notwendig, solche Bezeichnungen kurz zu halten, denn uns stehen genügend Arbeitsspeicher und ausreichend Monitorplatz zu Verfügung. Die Entwicklungsumgebung unterstützt beim Ändern von Namen; wähle stets aussagekräftige und unverwechselbare, die den Zweck beschreiben, Fehlinformationen vermeiden, aussprechbar sind und einen fachlichen oder technischen Kontext haben. Wortspiele, Generika und versteckte mentale Kontexte sind tabu!
Funktionen sollten eine Aufgabe erfüllen und klein sein. Es gilt eine Abstraktionsebene pro Funktion. Man muss anhand der Namen erkennen können, was genau ausgeführt wird. Anstatt zu kommentieren, kann eine Funktion in mehrere Schritte aufgeteilt und mit beschreibenden Namen versehen werden. Kommentare sind keine Wiedergutmachung für schlechten Code, zeigen aber oft Stellen, die dringend überarbeitet werden müssen. Juristische, informierende und klarstellende Kommentare sind nach wie vor in Ordnung, gleiches gilt für Absichtserklärungen, Warnungen und To-dos.
Die größten Diskussionen unter Entwicklern ist die Codeformatierung. Das Team sollte sich unbedingt auf einen Codestyle einigen, oder einen Weg finden, wie jeder in seinem eigenen Stil arbeiten kann ohne andere zu stören. Clean Code behandelt zudem weitere Konzepte zu Objekten, Klassen, Fehlerhandling aber auch saubere Techniken zu Nebenläufigkeit und Testing, welche den Umfang dieses Artikels sprengen würden.
Leseempfehlungen: Weitere Faktoren gut gemachter Software: Software Craftsmanship, Refactoring und Pragmatismus in der Softwareentwicklung.
Fazit
Auch wenn das Erlernen und Einhalten dieser Prinzipien am Anfang zeitaufwändig ist, jeder Entwickler tut sich selbst, seinem Team und dem Softwareprojekt einen großen Gefallen damit. Wem die Zeit fehlt, sich damit zu befassen, hilft vielleicht dieses Zitat als Orientierung: „Schreibe deinen Code so, als wäre der Typ, der ihn verstehen muss, ein Psychopath mit einer Axt, der weiß wo du wohnst.“
