07.10.2021 Lesedauer ca. 8 Min.
Inhalt
Softwareentwicklung ist ein weites Feld
Dabei unterscheidet man grob in Softwareentwicklung „im Kleinen“ und „im Großen“. In der Ausbildung oder im (Selbst-) Studium arbeitet man mit Softwareentwicklung „im Kleinen“. Allein schreibt man kurze Code-Fragmente, um Kernkompetenzen, wie die Verwendung von Schleifen und Bedingungen, zu erlernen. Sobald es an die ersten Praxis-Projekte oder in den Beruf geht, bekommt man es mit Softwareentwicklung „im Großen“ zu tun. Man schreibt an komplexeren Code mit mehreren Personen und kommt in Verlegenheit den eigenen und auch Code, der von anderen Personen geschrieben wurde, zu einem späteren Zeitpunkt erweitern oder verändern zu müssen.
Ein entscheidender Faktor ist die Lesbarkeit des vorliegenden Codes. Ihm kommt nicht nur eine Schlüsselfunktion als Erfolgs- und Kostenfaktor zu, sondern auch für die Arbeit der Entwickler:innen. Sie sollen Ihre Energie voll in ihre Arbeit stecken können anstatt mit Frustration, Angst vor git blame und dem Ausbügeln von Ungereimtheiten konfrontiert zu werden. Und an dieser Stelle kommt Clean Code ins Spiel.
Softwareentwicklung für Menschen
Programmcode wird primär für Maschinen geschrieben. Diese sind im Allgemeinen sehr viel genügsamer als Menschen und geben sich mit semantischer Korrektheit zufrieden. Aus Sicht der Maschine ist kompilierender, also von ihr interpretierbarer Code, fertig und vollkommen ausreichend. Menschen sind jedoch weitaus weniger genügsam. Sie benötigen neben einer korrekten Semantik auch logische Strukturen und sprechende Formulierungen, so dass sie den Code schlüssig verarbeiten können.
Wenn Programmcode schwer verständlich und lesbar ist, geht die menschliche Produktivität auf Dauer verloren. Änderungen nehmen mehr Zeit in Anspruch und werden risikoreicher, da sie nur noch in Teilen nachvollziehbar sind.
Im fortschreitenden Projektverlauf rückt die Neuerstellung von Code in den Hintergrund und die Veränderung von bestehendem Code wird zur Regel. Wenn die Softwareentwicklung nun mehr Code liest als schreibt, explodieren die Kosten in Relation zur aufgewendeten Zeit.
Clean Code trägt dazu bei, diesen Pain Point aufzulösen, in dem:
-
Die menschliche Produktivität durch einfach lesbaren Code dauerhaft erhalten wird.
-
Die Kosten für Änderungen beherrschbar bleiben.
-
Mehr Zeit gewonnen wird, um Mehrwert zu schaffen.
Mit kleinen Schritten zum Erfolg
Vollkommen unabhängig von der verwendeten Programmiersprache gibt es viele kleine, eigentlich triviale Maßnahmen, die sofort zu einer besseren Lesbarkeit von Code beitragen. Drei dieser Maßnahmen werden im Folgenden erläutert.
Naming-Things
There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.
— Leon “very tired” Bambrick (@secretGeek) January 1, 2010
there's two hard problems in computer science: we only have one joke and it's not funny.
— phillip bowden (@pbowden) May 20, 2014
There are so many variations on the “there are only two hard problems in computer programming...” joke that I’m starting to suspect that programming isn’t actually very easy.
— Nat Pryce (@natpryce) May 24, 2021
Die Wahl klarer Namen ist eines der ältesten und essenziellsten Probleme der Informatik. Sprechende Namen für Variablen, Funktionen, Klassen und Packages zu wählen braucht mehr Zeit, spart diese aber letztendlich wieder ein.
Namen sollten unmissverständlich sein und den Inhalt beschreiben: Der Weg der geringsten Unklarheit ist der Richtige. Was darauf steht, sollte auch darin stecken. Zusätzlich ist der Kontext entscheidend zur Schaffung von Verständlichkeit: Gut benannte Variablen in klar benannten Funktionen in sprechend benannten Klassen.
Hier ein reales Beispiel aus dem React-Bereich, das im Code-Review bemängelt wurde:
const [currentSelection, setCurrentSelection] = useState('')
Aus dem Kontext der Klasse ließ sich ableiten, dass es sich vermutlich um die Auswahl der Nutzer, die Zugriff auf das Element bekommen sollten, handeln musste. Die schnelle und einfache Verbesserung der Lesbarkeit konnte folgendermaßen erreicht werden:
const [currentUserSelection, setCurrentUserSelection] = useState('')
Kommentare
Robert „Uncle Bob“ Martin, Mitentwickler des agilen Manifests und Großmeister der Clean Code-Philosophie, sieht den Einsatz angemessener Kommentare als den Versuch der Entwickler:innen ihre eigene Unfähigkeit auszugleichen, sich im Code klar auszudrücken. Er ist der Ansicht, bevor ein Kommentar geschrieben wird, sollten Zeit und Energie in die Überarbeitung des Codes zur Unmissverständlichkeit investiert werden. Auch führt er als Argument an, dass Kommentare häufig nicht gepflegt werden und somit die Gefahr besteht, dass ein Kommentar nicht nur nicht weiter hilft den Code zu verstehen, sondern sogar Fehlinformationen verbreiten kann.
Trotzdem zählt er auch gute Arten von Kommentaren auf, wie beispielsweise Todos oder auch öffentliche Dokumentation in APIs.
Meine persönliche Erfahrung zeigt, dass die Wahrheit, wie so häufig in der goldenen Mitte liegt. Besonders, wenn man sich im Bereich der Legacy-Wartung befindet, sind klarstellende Kommentare lebensnotwendig und auch wenn die Kenntnisstände von technologischen Spezifika im Team (noch) vorhanden sind, können sie angemessen sein.
Hier ein (besonders) schlechtes Beispiel:
// the day of the month
number dayOfTheMonth
Die Benennung der Variable ist bereits ausreichend aussagekräftig. Der einzelne überflüssige Kommentar ist im Prinzip irreleveant. Wenn wir uns jedoch im Kontext eines großen Businessobjektes bewegen, wie beispielsweise einer Stammdatenverwaltung, kann der Code schnell doppelt so lang und damit unübersichtlich werden, ohne an Aussagekraft durch die Kommentare zu gewinnen.
Hier ein positives Beispiel:
/* TODO wird mit der Erledigung des Tickets xy obsolet und kann dann entfernt werden */
Formatierung
Die Hauptaufgabe von professionellen Softwareentwickler:innen ist Kommunikation und Formatierung, also die Darstellung und Strukturierung von Code in Dateien, ist eine wesentliche Form der Kommunikation, die Rückschlüsse auf die allgemeine Sorgfalt und das Augenmerk auf Details im gesamten Projekt ziehen lässt.
Jede moderne integrierte Entwicklungsumgebung (IDE) stellt automatisierte Tools zur Code-Formatierung zur Verfügung, die einheitlich vom Team verwendet werden sollte.
Hier ein schlechtes und unübersichtliches Beispiel einer while-Schleife:
while (i<10) {text+="The number is "+i; i++;}
Mit sauberer Formatierung wird die Schleife lesbar:
while (i < 10) {
text += "The number is " + i;
i++;
}
Wrap-Up
Softwareentwicklung besteht nicht nur aus 0 und 1, ist risikoreich, braucht Zeit und Geld. Eines der vielen Mittel zur Risiko- und somit Kostenbeherrschung in Softwareprojekten ist Clean Code. Bereits mit einfachen Maßnahmen können Erfolge in der Neu- und Weiterentwicklung durch lesbaren Code erzielt werden.
Die hier angeführten Maßnahmen sind nur die Spitze des Eisbergs. Um ein Clean Coder nach Uncle Bob’s Vorstellungen zu werden und frustfreier auf in der Vergangenheit geschriebenen Code zurück zu kommen, sind seine Bücher ein perfekter Einstieg.
Quellen
https://martinfowler.com/bliki/TwoHardThings.html (abgerufen am 13. September 2021) Martin, R. C. (2009). Clean Code: Refactoring, Patterns, Testen und Techniken für sauberen Code ; [Kommentare, Formatierung, Strukturierung ; Fehler-Handling und Unit-Tests ; zahlreiche Fallstudien, Best Practices, Heuristiken und Code Smells]. Deutschland: mitp. https://www.q-dan.de/ (abgerufen am 13. September 2021)
Über Julia Kordick
