Die „Definition of Clean“ – mehr Programmierfreude durch sauberen Code

Unverständliches ist anstrengend! Ob unter Entwicklern, Projektmanagern oder Architekten – bei der Übernahme eines Projekts mit schwierig nachzuvollziehendem Programmcode stellt sich schnell Frustration ein.

Das Gehirn eines Softwarespezialisten muss nämlich Leistungen auf einem durchaus hohen Niveau vollbringen, um einen unbekannten und schlecht geschriebenen Code zu entschlüsseln: Von mentalem Mapping über Mustererkennung, Auflösen komplexer Strukturen, Übersetzungen, Transformationen, räumlichem Vorstellungsvermögen bis hin zu Abstraktion und vielem mehr.

Das alles kostet Konzentration, Zeit und Kraft. Eine besondere Note der Frustration verleiht der unsaubere Code dadurch, dass er vor allem eines ist: Nämlich unnötig. Wenn Entwickler gähnend, kopfschüttelnd oder stöhnend vor ihren Monitoren sitzen, stellt sich der eine oder andere sicherlich die Frage: „Warum wurde das nicht von Anfang an richtig gemacht?“ Bei einer solchen Ausgangslage kann die Motivation schnell nach unten gehen. Um dies zu verhindern, sollten Entwickler-Teams stets darauf achten, ihren Code sauber und verständlich anzulegen und dies auch über das gesamte Projekt hinweg durchzuhalten. Sind aber nur die Entwickler alleinig schuld an schlechtem Code?

Ursachen von schlechtem Code

Ein Vergleich von OpenSource-Software zu kommerzieller Software zeigt, dass OpenSource-Software annähernd 100% sauber ist, während kommerziell hergestellte Software im Vergleich bei maximal 3% liegt (Gesellschaft für Informations- und Kommunikationssysteme mbH).

OpenSource-Code ist sauber aufgrund unterschiedlicher Aspekte:

• Eigenes Image: Man möchte Profi sein und vor der „ganzen Welt“ keine Blamage erleiden.
• Vorbildfunktion: Der bereits erstellte Code erfüllt sehr hohe Standards.
• Kontrolle: Der „Maintainer“ des OpenSource-Projektes beurteilt den Code streng.
• Selektion, da unverständlicher Code die Konkurrenz auf Dauer nicht überlebt.
   

Kommerzieller Code hingegen ist unsauber, wegen:

• Mangelnder Vorbilder: Es ist hier überall so, warum soll ich es ändern? (Broken Window Theorem).
• Fehlende Kontrolle: Code-Reviews, die echte Nachbesserungen zur Folge haben, sind selten.
• Projektleiter belohnen äußere Qualität (Features / Fehlerfreiheit). Innere Qualität sehen und verstehen sie nicht.

Untersuchungen zeigen, dass sich in Projekten, die eine schlechte Codequalität aufweisen, häufig folgende Unsitten beobachten lassen:

• Kommunikationsprobleme
• Schlechte Infrastruktur
• Konformitätsbrüche
• Workarounds statt Behebung
• Code Verdoppelungen
• Magie im Code / (zu) komplizierte Implementierung
• Toter Code / Spaghetti-Code
• Unglückliche Namensgebung
• Fehlende Tests
• Frühzeitiges Fertigmelden
• Verwaiste TODOs
• …

Doch was heißt „sauber“ nun in diesem Zusammenhang eigentlich genau?

Clean Code beschleunigt die Softwareentwicklung

Zunächst geht es darum, sich darüber bewusst zu werden, was einen sauberen Code ausmacht. Eine einfache und zielführende Definition lautet: Clean oder sauber ist ein Programmiercode dann, wenn er mit so wenig Spezialwissen wie möglich in kurzer Zeit richtig verstanden werden kann. Hierdurch lassen sich in einem Projekt dann am Ende Personalstunden sparen, denn sowohl der Zeitaufwand als auch die benötigte Erfahrung sind geringer, um mit der Entwicklung starten zu können.

Der erste Schritt zum sauberen Code besteht also darin, das richtige Mindset an den Tag zu legen. In der Sache das Richtige zu tun, anderen Menschen unnötige Arbeit abzunehmen, die Wartung niedrigschwellig zu gestalten, sodass Kunden und Anwender in den Genuss besserer Software kommen – dies alles trägt durchaus Züge einer idealistischen und werte-orientieren Herangehensweise. Dies steigert über den praktischen Nutzen hinaus auch das Selbstwertgefühl und die Motivation des ganzen Teams.

Hinter den Regeln für sauberen Code stehen funktionale Ziele

Ein detailliertes Paradigma, wie sich Clean Code implementieren lässt, beschreibt der Fachautor Robert C. Martin in seinem gleichnamigen Buch aus dem Jahr 2009. Martin gibt Empfehlungen und Regeln, wie Qualitätskriterien guter Software – wie beispielsweise wartbar, korrekt, performant, effizient, stabil, zuverlässig, erweiterbar oder auch sicher – in jeder Programmierzeile abgebildet werden können. Für den Quellcode ergibt sich daraus die basale Forderung, dass er verständlich und änderbar und testbar sein muss. Dabei ist das häufige Missverständnis auszuräumen, dass sauberer Code mit „penibel“ oder „akkurat“ gleichzusetzen ist. Bei Clean Code geht es nämlich um die funktionalen Kriterien der Software – und weniger die formalen. 

Um in einem Softwareprojekt konsistent sauberen Code zu schreiben, gilt es unter anderem, folgende konkrete Regeln zu beachten:

• Variablen, Funktionen und Klassen brauchen selbsterklärende oder zumindest aussagekräftige Namen.
• Die Namen sollten aussprechbar sein, also aus natürlichen Worten und keinen Buchstaben- oder Zahlenkürzeln bestehen.
• Getreu dem Motto „DRY – Don’t repeat yourself“ sollten Wiederholungen ausgeschlossen werden.
• Funktionen sollten klein sein, und wenn sie schon klein sind, sollten sie noch kleiner sein. Klein bedeutet in diesem Zusammenhang, dass Funktionen nur eine Sache machen sollen:
• „Function should do one thing, they should do it well, they should do it only.“ – Robert C. Martin
• Die fünf Entwufsprinzipien, deren Anfangsbuchstaben das Akronym „SOLID“ bilden, sollten bekannt sein und eingesetzt werden:
   

1. Singe Responsible Principle: „„Es sollte nie mehr als einen Grund geben, eine Klasse zu ändern.“ – Robert C. Martin
2. Open-/Closed-Principle: „Module sollten sowohl offen (für Erweiterungen) als auch verschlossen (für Modifikationen) sein.“ – Bertrand Meyer
3. Liskov Substition-Principle: „Sei q(x) eine beweisbare Eigenschaft von Objekten x des Typs T. Dann soll q(y) für Objekte y des Typs S wahr sein, wobei S ein Untertyp von T ist.“  - Barbara H. Liskov
4. Interface Segregation-Principle: „Schnittstellen sollen in mehrere Schnittstellen aufgeteilt werden, falls implementierende Klassen unnötige Methoden haben müssen.“ – Bertrand Meyer
5. Dependency Inversion-Principle: „Module höherer Ebenen sollten nicht von Modulen niedrigerer Ebenen abhängen. Beide sollten von Abstraktionen abhängen. Abstraktionen sollten nicht von Details abhängen.Details sollten von Abstraktionen abhängen.“ - Wikipedia

Neben diesen und einigen weiteren Programmierregeln sind auch die Kommentare ein wichtiger Aspekt des Clean Code. Hier kommt leider allzu oft die Devise „viel hilft viel“ zum Tragen. Kommentare per se stellen aber noch keinen Vorteil dar. Zu lange, redundante und irreführende Kommentare, im Extremfall sogar das Führen von Kommunikationen unter Entwicklern anhand von Kommentaren, können im Gegenteil sogar schädlich sein. Das Ideal des Clean Code besteht prinzipiell darin, dass der Code weitestgehend selbsterklärend ist. Bestimmte Ausnahmen gibt es aber doch: Zum Beispiel Hinweise auf Copyrights und Autoren, informative Kommentare, die z.B. einen regulären Ausdruck erläutern, oder Warnungen vor Konsequenzen bei Ausführung bestimmter Codestellen (z.B. bei sehr aufwändigen Test-Durchläufen) sowie TODO- oder FIXME-Kommentare.

Ausgestattet mit einer klaren regelbasierten „Definition of Clean“ können Entwicklerteams sich und ihren Kunden bzw. Auftraggebern viel Frustration und Aufwand sparen. Die Software ist damit zugleich auf einem höheren Qualitätsniveau und in kürzeren Entwicklungszeiten realisierbar.