Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren
… 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.
Warum Entwickler beim Programmieren 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.
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.
