Clean Code: der nächste Programmierer könntest du sein

Über die Jahre habe ich immer wieder Debatten über Clean Code gehört und selbst daran teilgenommen. Klare Namen, einfaches Design, kleine Funktionen, wenige Verantwortlichkeiten und so weiter. Aber wie wenden wir diese Ideen eigentlich in unserem Alltag wirklich an?

Es gibt viele gute Praktiken, die wir als Programmierer alle im Hinterkopf behalten sollten. Schon allein sie hin und wieder zu wiederholen, finde ich grundlegend, um sich daran zu erinnern, was wir tun und vor allem warum wir es tun. Ich finde es auch interessant zu beobachten, wie sich diese Ideen weiterentwickeln und welche Ansätze uns als Community, und natürlich in einem Unternehmensumfeld als Team, weiterhelfen können.

Besonders interessant finde ich zum Beispiel die praktische Philosophie, die Kent Beck in seinem Buch Tidy First? entwickelt. Nicht weil es eine neue Liste von Clean-Code-Regeln aufstellt, sondern weil es den Fokus auf etwas legt, das ich für grundlegend halte: den Code kontinuierlich zu verbessern, mit kleinen Schritten, die Teil der täglichen Arbeit sind.

Einige Ideen, die ich besonders nützlich finde:

1. Alltägliche Mikrokorrekturen: eine verwirrende Variable umbenennen, toten Code entfernen oder einen kleinen Teil des Designs verbessern. Kleine Handlungen, die sich mit der Zeit summieren und verhindern, dass die Komplexität unkontrolliert wächst.
2. Bevor du den Code änderst, räum ihn auf: Wenn wir eine neue Funktionalität hinzufügen wollen, macht es das Vorbereiten des Terrains vorher viel einfacher, die neue Logik zu schreiben.
3. Mach nicht jede Refaktorierung zu einem großen Projekt: Hör nicht auf, dem Kunden Mehrwert zu liefern, nur um eine komplette Bereinigung des Systems anzugehen. Der Code kann sich organisch nebenbei verbessern, eingebettet in den täglichen Arbeitsfluss.

Ich erinnere mich, dass sowohl Kollegen als auch ich selbst schon einmal in die Falle getappt sind, monatelang an der Refaktorierung eines Monsters zu arbeiten. Das Ergebnis ist meist eine Mischung aus Erschöpfung, Frustration und einem merkwürdigen Gefühl der Verantwortung für etwas, das eigentlich dem ganzen Team gehört.

Übernimmt außerdem eine einzelne Person diese Aufgabe, wird sie unbemerkt zur "verantwortlichen Person" für diesen Teil des Systems. Ihr Name taucht bei allen wichtigen Änderungen auf, und wenn etwas passiert, richten sich die Blicke leicht auf sie.

Aus Erfahrungen lernt man.

Wie schon gesagt, gibt es unzählige gute Clean-Code-Praktiken im Internet. Heutzutage kannst du sogar mit verschiedenen LLMs darüber diskutieren und dir Informationen liefern lassen, die auf deine Interessen zugeschnitten sind. Deshalb glaube ich nicht, dass es sich lohnt, dieselbe Liste von Regeln in einem weiteren Blog neu zu schreiben. Das werde ich nicht tun.

Lieber bleibe ich bei einer Analogie, die mir als Wanderfreund schon immer sehr bildhaft erschienen ist.

Wenn du im Wald einen Pfad anlegst und klare Markierungen hinterlässt, kann die nächste Person ihn gehen, ohne sich zu verirren. Und genauso wie guter Code oft keine Kommentare braucht, weil er sich von selbst erklärt, braucht auch ein guter Pfad nicht alle zwanzig Meter eine Markierung.

Das Schöne an dieser Idee ist, dass wir diesen Weg für die hinterlassen, die nach uns kommen: einen Kollegen, jemanden, den wir noch nicht kennen, oder, interessanterweise, uns selbst.

Denn oft ist diese nächste Person du selbst, Monate später, wenn du dich nicht mehr an den Weg erinnerst, den du angelegt hast.