Clean Code ist kein Selbstzweck. Und kein Dogma, wie ich an anderer Stelle bereits festgestellt habe. Die Clean Code Developer Prinzipien und Praktiken dienen dazu, Werte zu erreichen. Beim Codieren sind dies primär die Werte Wandelbarkeit und Korrektheit. Betroffen ist häufig auch der Wert der Produktionseffizienz.
Um zu einer differenzierten Betrachtung zu gelangen, ist es hilfreich, solche Situationen zu identifizieren, in denen es um anderes geht, als die Werte Wandelbarkeit und Korrektheit. Vier solcher Situationen habe ich identifiziert:
1. Einen sehr kritischen Bug fixen
Nicht jeder Bug ist kritisch. Sofern aber beim Kunden nichts mehr geht, die Produktion steht, es um viel Geld geht, dann spielt Clean Code zunächst keine Rolle. Es geht dann darum, den Fehler zu beheben, damit der Kunde weiter arbeiten kann.
In eine solche Situation solltest du besser nicht geraten. Sie löst enormen Stress aus und schadet dem guten Ruf. In solchen kritischen Momenten auf Clean Code zu verzichten, obschon der Verzicht auf Clean Code initial zum Problem geführt hat, klingt paradox. Das löst sich auf, wenn der restliche Ablauf klar wird: nachdem das Problem behoben ist, müssen automatisierte Tests ergänzt werden, die sicherstellen, dass dieses Problem nie wieder auftaucht. Und damit einhergehend sind in der Regel auch Refactorings verbunden, mit denen die Codequalität leicht verbessert wird.
Fazit: das Wurzelproblem ist der fehlende Clean Code Fokus. In der Situation steht der Bugfix im Vordergrund, im Anschluss wird aufgeräumt.
2. Technologie erlernen
Wenn du eine Technologie einsetzen möchtest, von der du keine Ahnung hast, tust du gut daran, dies in einem gesonderten Projekt zu tun. Insbesondere nicht am Produktionscode. Solche Spikes dienen dazu, Erkenntnisse zu gewinnen. Daher ist es wichtig, den Fokus zu wechseln. Es geht nicht um Wandelbarkeit und Korrektheit von Produktionscode, sondern um die Exploration einer Technologie.
Beim Lernen können automatisierte Tests helfen. Statt eine Konsolenanwendung zu schreiben, um den Code auszuführen, kann auch ein Test diese Rolle übernehmen. Ggf. ist es auch wichtig herauszufinden, wie sich die neue Technologie in automatisierten Tests verhält.
Fazit: beim Lernen ist das Ziel der Erkenntnisgewinn. Wenn die Clean Code Developer Prinzipien und Praktiken dich dabei unterstützen, wunderbar. Wenn nicht, lass sie weg.
Erhalte einen Auszug aus dem Buch „Mit Flow Design zu Clean Code“.
3. Lösungsidee überprüfen
Bei manchen Anforderungen muss eine Lösungsidee zunächst überprüft werden, weil niemand im Team sicher ist, dass es so funktionieren wird. Ein Proof of Concept (POC) kann hier helfen, Sicherheit zu erlangen. Ähnlich wie beim Erlernen einer Technologie geht es auch beim Überprüfen einer Lösungsidee darum, Erkenntnisse zu gewinnen. Ziel ist nicht der Produktionscode sondern die Erkenntnis, ob eine Lösungsidee funktioniert.
Auch beim POC können bspw. Tests dazu dienen, zügig voran zu kommen. Es ist ja nicht verboten, Clean Code Developer Prinzipien und Praktiken anzuwenden. Der Fokus liegt allerdings nicht auf der Langlebigkeit des Codes. Daher ist es in Ordnung, bei einem Proof of Concept keinen hohen Anspruch an die Codequalität zu haben. Gleichzeitig muss der Code den Nachweis erbringen, dass die Lösung tatsächlich funktioniert. Insofern ist die Lesbarkeit und Verständlichkeit des Codes hier nicht unwichtig.
Fazit: beim Prüfen einer Lösungsidee geht es noch nicht um Produktionscode. Es ist zu diesem Zeitpunkt noch unklar, ob der Ansatz trägt. Daher steht der Erkenntnisgewinn im Vordergrund, weniger die Wandelbarkeit.
4. Produktidee überprüfen
Als Startup ist es wichtig, schnell herauszufinden, ob eine Produktidee funktionieren wird. Dazu gibt es diverse Verfahren, die hier nicht weiter thematisiert werden sollen. Irgendwann kommt man an den Punkt, an dem eine erste Produktversion erstellt werden muss. Da zu diesem Zeitpunkt, trotz aller Vorarbeit, noch nicht verlässlich klar ist, ob die ganze Geschichte wirtschaftlich funktionieren wird, muss der Aufwand in Grenzen gehalten werden. Darüberhinaus kann es erforderlich sein, das Produkt nochmals zu pivotieren.
Hier befindet man sich in einem Dilemma. Einerseits soll der Code wandelbar sein, um ihn leicht an einen Schwenk der Produktidee anpassen zu können. Gleichzeitig muss alles zügig vorankommen, weil der Cashflow fehlt. Ich würde nicht vollständig auf die Clean Code Developer Bausteine verzichten, aber manches mit Augenmaß anwenden und anderes auf später verschieben.
Aber Vorsicht! “Das machen wir später” kann schnell zu einem Berg Legacy Code führen. Sobald die ersten zahlenden Kunden da sind und das Produkt trägt, muss aufgeräumt werden. Es muss dann in einem guten Verhältnis von neuen Features und Aufräumen gearbeitet werden.
Fazit: der Spagat zwischen Qualität und Cashflow ist schwierig.
Fazit
Die Clean Code Developer Prinzipien und Praktiken sind enorm wichtig. In der Vergangenheit und auch aktuell wird eher zu wenig davon umgesetzt. Und dennoch gibt es Momente, in denen anderes im Vordergrund steht. Dies ist keine Entschuldigung und kein Argument dafür, nichts zu tun. Codequalität ist wichtig, Clean Code ist wichtig.
Möglicherweise sind wir aktuell in einer Phase, in der wir beginnen, die Prioritäten zu verschieben. Durch das Aufkommen sehr leistungsfähiger AI Werkzeuge wie ChatGPT kann der eigentliche Code bereits jetzt vielfach generiert werden. Der Fokus verschiebt sich damit noch mehr in Richtung automatisierter Tests. Wenn der Code dahinter die Tests erfüllt und stets wieder neu generiert werden kann, spielt die Qualität zukünftig keine Rolle mehr.
Welche Gründe gibt es für dich, keinen Clean Code zu schreiben?
German 
English
1 Kommentar zu „4 Gründe, keinen Clean Code zu schreiben“
Pingback: Clean Code Trainer werden - CCD Akademie GmbH