Schluss mit Frust: Clean Code hilft bei der Softwarequalität

Inhaltsverzeichnis

Was ist schlechter Code und wie unterscheidet er sich von Clean Code? Was genau verstehen Entwicklerinnen und Entwickler unter Clean Code und wie hilft er ihnen dabei, ihren Quellcode "sauber" zu bekommen? Ziel dieses Artikels ist es, Antworten auf diese Fragen zu geben und zu demonstrieren, wie sich durch Clean Code Frust im Arbeitsalltag vermeiden lässt.

Ausgangspunkt soll eine den vermutlich meisten Entwicklerinnen und Entwicklern vertraute Situation in einem beispielhaften Softwareprojekt sein: Ein erfolgreich gereiftes Projekt mit kontinuierlicher Entwicklung rund um ein Kernteam sucht einen neuen Mitarbeiter. Die Anwendung ist bereits seit einigen Jahren im produktiven Einsatz und das Team hat in dieser Zeit bereits mehrere Personalwechsel hinter sich gebracht. Mit einem auf weitere zwei bis drei Jahre ausgerichteten Budget existiert eine solide Grundlage, um auch in Zukunft neue Features zu entwickeln und entscheidende Fortschritte zu erzielen.

Frust im Softwareprojekt

Auch wenn sich die Stellenbeschreibung auf dem Papier nahezu perfekt liest, hinterlässt die Realität im Projekt bei den neuen Teammitgliedern häufig nur Frust. Das Problem dabei: Die Bewerberinnen und Bewerber erhalten vor dem Einstieg in das Projekt keinen Einblick in die Codebasis. Enthält diese aber schlechten Code, ist Stress vorprogrammiert.

Um die Relevanz von sauberem Code gegenüber schlechtem Code zu verdeutlichen, eignet sich der Vergleich mit einem Restaurant. Will ein Koch seine Gerichte nicht nur lecker, sondern auch möglichst reibungslos zubereiten, muss die Küche, in der er arbeitet, einige Rahmenbedingungen erfüllen: Ungewaschenes Geschirr und verstreute Zutaten schon vor Arbeitsbeginn schrecken jeden Koch ab. Restaurantgästen, die einen Blick in eine solche Küche werfen sollten, dürfte zudem der Appetit vergehen. Unter solchen Bedingungen möchte vermutlich kein Koch auf dieser Welt freiwillig arbeiten.

Ähnlich verhält es sich, wenn es um Software geht. Auch hier trifft man immer wieder auf die unangenehme Wahrheit, dass in eingefahrenen Projekten solche schlechten Umstände herrschen, die sich häufig um unsauberen Code ranken. Leider ist schlechter Code aber auf den ersten Blick nicht leicht erkennbar.

Was ist "schlechter" Code und wie entsteht er?

Das weitere Vorgehen im beispielhaften Projekt sieht nun die möglichst reibungslose Einarbeitung des neuen Mitglieds im Entwicklerteam vor. Dazu sollen ein einfaches Feature umgesetzt und die lokale Projektumgebung eingerichtet werden. Neulingen sind zwar die Architektur sowie das benutzte Framework noch nicht bekannt, nach einem ersten Blick in den Quellcode zeigt die neue Kollegin oder der neue Kollege sich jedoch hoch motiviert, mit der Umsetzung des ersten Features zu starten. Die Antwort der Teamkollegen, auf eine um Hilfe bittende Frage, sorgt dann aber für Ernüchterung: "Schau dir dafür die Klassen aus dem Package an. Mehr kann ich dir im Moment auch nicht sagen. Ein Arbeitskollege ist seit gestern nicht mehr in das Projekt involviert. Das Team steht unter enormem Zeitdruck, da bis zum Release in zwei Tagen noch vier Features fertigzustellen sind. Sämtliche Unit-Tests sind rot und die Probleme auf dem Live-System haben derzeit höchste Priorität. Schau bitte, dass du das Feature irgendwie fertigstellst, damit der Release-Termin eingehalten wird."

Rot markierte Unit-Tests, fehlende Teamkollegen, Live-Probleme und ein straffer Release-Plan. Auch ohne den Quellcode der Applikation gesehen zu haben, lässt sich in dieser Situation leicht einschätzen, dass nicht nur das anstehende, sondern vermutlich auch zukünftige Releases in diesem Projekt termingerecht nur schwer fertigzustellen sind.

Leider kommt es in der Praxis in vergleichbaren Projekten allzu häufig vor, dass sich die Softwarequalität kontinuierlich verschlechtert, selbst wenn erfahrene und motivierte Entwickler mitarbeiten. Am Anfang gehen alle Stakeholder mit den besten Absichten ans Werk, müssen sich dann aber vorhersehbaren und unvorhersehbaren Einflussfaktoren beugen – denn Software ist bekanntlich nie ganz fertig. Häufig kommt es vor, dass sich Anforderungen kurz vor vereinbarten Release-Terminen ändern oder ignorierte Unit-Tests zu Produktionsproblemen führen. Mitunter folgen Sicherheitsupdates, die größere Änderungen erfordern. Die beteiligten Entwickler ändern dann hier und da ein paar Codezeilen, damit das Projekt weiterläuft.