Ein befreundeter Produkt Manager klagt über Probleme, die er aktuell mit seinem Team hat. Er wünscht sich eine höhere Produktivität, Skalierung und weniger Bugs. Wir haben zusammen einige Ansätze diskutiert, davon möchte ich einen vorstellen. Er wirkt sich unmittelbar auf die Wirtschaftlichkeit und Qualität aus.
Es ist bekannt, dass Programmierer lange nicht so viel Zeit für das Schreiben von Code aufwenden. Es gibt zu viele Zeitfresser, die einen davon abhalten. Das bestätigt auch eine Umfrage, dieser zufolge sind nach Warten, Brainstorming, usw. noch ca. 20 Stunden fürs Coding übrig. Diese 20 Stunden setzten aus weiteren Teilbereichen zusammen: Strukturierung und überarbeiten der Applikation, Lesen und Schreiben von Code. Bestimmt noch einiges mehr. Aus meiner persönlichen Erfahrung würde ich behaupten, dass das Schreiben den kleinsten Teil ausmacht, im Gegensatz zum Lesen. Deswegen als Letztes in der Aufzählung. Um mehr Zeit mit dem Schreiben zu verbringen, muss diese von den anderen Punkten eingespart werden. So komme ich auf das Thema dieses Beitrags.
Um die Zeit für das Lesen möglichst gering zu halten, ist es wichtig, das der Code sauber ist. Sauber liegt immer im Auge des Betrachters, aber damit ist aussagekräftiger, strukturierter aber auch wart- & erweiterbarer Code gemeint. Oft lässt sich das nur mit Nachbessern erreichen, worauf ich später noch eingehe. Es ist nicht immer möglich all diese Kriterien beim ersten Entwurf umzusetzen, es erfordert einiges an Erfahrung und Übung. Ich bin der Meinung Code sollte so aussagekräftig sein das ein Nicht-Entwickler diesen versteht.
Keine Sorge. Der zeitliche Mehraufwand hält sich in Grenzen und wird nach einiger Zeit sinken. Die Einsparungen beim Verstehen von Code, bei der Fehlerbehebung und bei der Dokumentation des Codes gleichen die aufgewendete Zeit wieder aus.
Das Problem entsteht häufig durch die Meinung Ala “Ich verstehe meinen Code!”, “Der Code ist doch ganz einfach!“. Die Aussagen mögen in diesem Moment stimmen, der Ersteller hat sich mit dem Problem intensiv auseinandergesetzt, sollen aber auch noch nach eingier Zeit zutreffen. Für einen Dritten ist es um so schwerer den Code nachzuvollziehen ohne das Problem zu kennen, weshalb sich dieser Code in der Applikation befindet. Das frisst nicht nur Zeit, sondern stellt auch ein hohes Fehlerpotenzial dar.
Um dieses Problem zu vermeiden, sind regelmäßige Refactorings notwendig. Damit ist vereinfacht ausgedrückt gemeint, es wird kontrolliert, ob der geschriebene Code verbessert werden kann. Unnötige Zeilen werden entfernt, ist es möglich sich klarer auszudrücken, passen die Namen von Variablen und Funktionen, ist es möglich Code auszulagern, wenn dieser in der Applikation doppelt vorkommt.
Für diese Aufgabe sollten Product Owner etwas mehr Zeit einplanen. Häufig wird der Wert nicht erkannt und als unnötige Spielerei angesehen und mit den Worten “Warum wird’s nicht gleich sauber geschrieben?” abgelehnt. Um das in einer Metapher darzustellen, es wäre wie von einem Buchautor zu verlangen, er darf sich bei seinem 1000-Seiten-Roman kein einziges Mal verbessern. Deswegen sollte hier mehr Zeit eingeplannt werden.
“The beginning of wisdom is to call things by their proper name.” Confucius
Es gab in der Vergangenheit verschiedene Ansätze dieses Problem in den Griff zu bekommen. Die wohl verbreiteste ist wahrscheinlich das Kommentieren von Code. Ich halte das für nur teilweise bis gar nicht sinnvoll und behaupte, Kommentare schaden mehr als das sie nutzen. Ja es mag die Ausnahmen geben. Ich rede von unnötigen Kommentaren, Kommentare, die eigentlich in Code ausgedrückt sein sollten. Dazu muss man wissen Kommentare werden beim Ausführen der Applikation ignoriert und existieren nur im Programmcode, nicht in Maschinencode. Die Gefahr, die ich sehe, ist das Kommentare veralten und gepflegt werden müssen. Daher sind sie oft zu ungenau. Möchte man wissen, wie sich das Programm verhält, muss der Programm Code gelesen werden, nicht die Kommentare.
“Code never lies, comments sometimes do.” Ron Jeffries
Tatsächlich habe ich schon solche Kommentare gesehen, siehe das Beispiel weiter unten. Der Kommentar ist überflüssig. Sollte sich der Name der Variable ändern, würde zwar der Kommentar notwendig sein aber ebenso ist dies wieder ein Zeichen, dass der Name der Variable falsch ist. Die Lösung ist den Kommentar zu entfernen.
In diesem Beispiel befinden sich 3 der 4 Wörter eine Zeile darunter. Der Kommentar ist also nicht aussagekräftiger als der Variablenname. Meine Empfehlung, ist es den Kommentar zu entfernen.
// exact address match found
var exactAddressMatch = this.addressService.get(....Vermutlich der größte Punkt von Clean-Code ist die Benennung von Variablen, Funktionen, Klassen usw. Der Ersteller sollte sich einen kurzen Moment nehmen und den bestmöglichen Namen wählen. Ändert sich der Inhalt oder passt aus einem anderen Grund nicht mehr, ist es kein Problem eine Änderung vorzunehmen. Ein zusätzlicher Tipp von mir, es sollten keine Abkürzungen verwendet werden, diese setzen oft ein tieferes fachliches Verständnis voraus, was neuen Mitarbeitern den Einstieg erschwert.
Syntactic Sugar
Um Code noch ausdrucksstärker und lesbarer zu gestalten, kommen wir zum letzten Punkt. Programmiersprachen unterscheiden sich häufig von ihrer Schreibweise. Jede Sprache bietet eine andere “Grammatik”. Diese sollten am besten genutzt werden, solange sie der Lesbarkeit dienen. Dies ist auch unter dem Begriff Syntactic Sugar bekannt. Meistens sind es einfache Dinge, erhöhen aber die Lesbarkeit enorm.
Ein stark vereinfachtes Beispiel möchte ich hier noch zeigen. Im folgenden Code wird einer Variable mit dem Namen Status der dritte Wert aus Status-Liste zugewiesen. Ohne Navigation durch die Applikation ist es nicht möglich, zu wissen was der dritte Status der Liste bedeutet. Zusätzlich stellt dieser Code ein hohes Fehlerpotenzial dar. Es ist möglich das sich die Reihenfolge oder Anzahl der Liste zur Laufzeit ändert.
var status = stateList[3];Einfacher und ausdrucksstärker ist es Folgendes zu schreiben. Dazu ist ein kleines Refactoring notwendig, dient aber der Lesbarkeit. So sollte es auch einem Nicht-Entwickler möglich sein, den Code zu verstehen.
var status = States.InputInvalid;Gibt es noch weitere Fragen? Ich stehe für Beratung oder Fortbildung gerne zur Verfügung.