Bad Code

Welche Auswirkungen hat schlechter Code eigentlich über den Code hinaus? Was löst schlechter Code emotional bei den Entwicklern, bei den Managern oder sogar beim Kunden aus?

Neulich hab ich ein Gleichnis von Uncle Bob gehört:

Dein Auto hat ein elektrisches Fenster, das nicht mehr hoch fährt. Du fährst also in die Werkstatt und zeigst es dem Mechaniker. Du erklärst ihm, dass das Auto sehr wichtig für dich ist, da du es im Alltag häufig brauchst und darauf angewiesen bist. Der Mechaniker schaut sich das Problem an und sagt dann: "Ja, kann ich reparieren, morgen kannst du dein Auto abholen."

Am nächsten Tag kommst du also zur Werkstatt und der Mechaniker führt stolz vor, dass das elektrische Fenster wieder geht. Du bedankst dich und setzt dich ins Auto, um loszufahren, aber das Auto startet nicht mehr.

Sowas ist ärgerlich, sicherlich kennen viele ähnliche Situationen. Diese Werkstatt wird man nicht wieder aufsuchen, weil man das Vertrauen verloren hat. Weil man den Mechaniker als inkompetent kennengelernt hat.

Vertrauensverlust

Wieso sollte es nun in der Softwareentwicklung anders sein? Genau das gleiche passiert, wenn Manager und Kunden sehen, wie Entwickler nur eine Kleinigkeit an einer Stelle im Code ändern und auf einmal geht eine ganz andere Funktion kaputt. Nichts verängstigt Kunden mehr als dieser Eindruck, da sie ja keinerlei Einblick unter die Haube bzw. in die Technologie haben: Sie glauben dann, diese Entwickler haben die Kontrolle verloren. Sie vermuten vielleicht sogar, dass unter der Oberfläche die Entwickler in ihren stillen Kämmerlein wohl Müll produziert haben. Sie werden an der Qualität des Projekts zweifeln und beginnen sich davor zu fürchten, Änderungen zu beauftragen.
Der ultimative Vertrauensverlust zeigt sich dann, wenn die Vorgesetzen entscheiden, dass diese Code-Module nicht mehr angefasst werden dürfen, weil Änderungen erfahrungsgemäß riesige Probleme verursachen. Schlussendlich verlieren auch die Entwickler irgendwann das Vertrauen und haben Angst, Code zu ändern.

Clean Code

Wie wollen wir Entwickler statt dessen von unseren Managern, Kunden und Vorgesetzten wahrgenommen werden? Was sollten wir liefern? Wie sollten wir arbeiten? Wie sollten wir auftreten?
Ich wage einen Vergleich: Wie sollte ein Operateur bei der Herz-OP arbeiten? Obwohl er eine Deadline hat, arbeitet er vorsichtig, aber ruhig. Er weiß immer, was er tut und was die richtigen Werkzeuge sind. Und welch hohes Vertrauen genießt er erst beim Patienten...

Aber die Realität schaut anders aus: Viele Entwickler arbeiten emotional, unsicher, unwissend... Und sie produzieren in der Hektik schlechten Code.
Den sie nicht warten können.
Den sie selbst nicht verstehen.
Der nur Fehler und Probleme verursacht.

Um aus dieser Spirale rauszukommen bzw. gar nicht erst rein zu kommen, um das Vertrauen in die Kompetenz des Entwicklers zu erhalten, gibt es nur einen Weg:
Clean Code. Der heilige Gral der Softwareentwicklung.

Vertrauen herstellen

Wenn unser Code nur absolut sauber und clean wäre, dann wäre alles gut. Alle wären zufrieden, dann verhält Software sich genau so, wie bestellt. Änderungen sind schnell und leicht zu integrieren. Wartung und Weiterentwicklung kann auch von anderen Entwicklern ohne Probleme stattfinden.

Guter Code ist aber vor allem langweilig! Er ist offensichtlich und man liest ihn und denkt sich: "Klar, ja genau so sollte es sein! Das hab ich so erwartet..."

Wie schreibt man also guten Code, sog. Clean Code? Wie erlangt man wieder Vertrauen in ein Projekt, in einzelne Code-Module? Einer der besten und effektivsten Werkzeuge sind automatisierte Tests. Sie garantieren zu jeder Zeit die Funktionalität der Software auf Knopfdruck. Sie erfordern und fördern eine Code-Struktur, die offen für Veränderungen bleibt.

Tests verschaffen Sicherheit. Sicherheit bringt Vertrauen. Und Vertrauen bringt einen ruhigen Schlaf.