Clean Code – Sauberer Code ist unverzichtbar
Manchmal behaupten Entwickler, dass Clean Code Development zu lange dauern würde. Man sei viel effizienter, wenn man auf zu viel Codequalität verzichtet. „Keep it Simple“ sagen sie. Clean Code würde doch zu oft als eine Art Religion betrachtet. Agil wäre ja ok, aber Clean Code führe dann doch zu weit. Allein schon der Umfang der Prinzipien und Praktiken sei so groß, dass da doch kein normaler Entwickler durchsteigen würde. KISS, Keep it simple stupid! Wir schreiben einfach ganz normal unseren Code und fertig. Haben wir schon immer so gemacht!
Spätestens bei der Wartung von bestehendem Quellcode merken sie dann, dass die Lesbarkeit des Codes nicht gegeben ist. Der Code ist nicht verständlich, Tests sind nicht automatisiert, und so schreitet die Softwareentwicklung immer langsamer voran. Schon nach wenigen Monaten muss mit Refactoring Maßnahmen vieles an der Anwendung geändert werden. Am Ende wird dann manchmal sogar den Clean Code Developer Ideen die Schuld zugeschrieben. Hätte man nämlich einfach so gearbeitet, wie immer, wäre der Code in Ordnung gewesen. So wie früher.
Clean Code Development
Zum Jahreswechsel 2008/2009 haben mein Kollege Ralf Westphal und ich die Inhalte der Clean Code Developer Initiative veröffentlicht. Es ging uns darum, einen Beitrag zu leisten zur Professionalisierung der Softwareentwicklung. Unsere Beobachtung war damals, dass vieles nicht rund läuft. Seit dem hat sich einiges verändert und verbessert. Doch das Thema ist damit nicht erledigt. Noch immer werden in zu vielen Teams keine oder zu wenig automatisierte Tests geschrieben. Noch immer werden Don’t Repeat Yourself (DRY) Verletzungen eingegangen durch massive Code Dopplung. Die Clean-Code-Prinzipien sind so wichtig wie eh und je.
Clean Code von Robert Cecil Martin
Auslöser für unsere Initiative war das Buch Clean Code von Bob C. Martin. Ralf und ich haben es zufälligerweise zur gleichen Zeit gelesen und kamen darüber in einen intensiven Austausch. So wurde die Idee geboren, eine Sammlung zu erstellen von Bausteinen, die helfen können. Das Buch war für uns der Auslöser. Die Sammlung an Prinzipien und Praktiken ist deutlich umfangreicher als das, was im Clean Code Buch steht.
Prinzipien und Praktiken
Wir haben unsere Sammlung von 45 Bausteinen eingeteilt in Prinzipien und Praktiken. Prinzipien bzw. deren Verletzung können im Code erkannt werden. Ein Verletzung des Prinzips Don’t Repeat Yourself (DRY) macht sich bspw. durch Dopplungen im Code bemerkbar. Die gleichen Zeilen sind exakt oder leicht modifiziert an mehreren Stellen zu finden.
Praktiken dagegen beschreiben Werkzeuge oder Arbeitsschritte auf dem Weg zum Code. So besagt bspw. die Pfadfinderregel, dass man den Code jedesmal ein bisschen besser zurücklassen soll, als man ihn vorgefunden hat. Oder die Praktik Test-first empfiehlt, jeweils erst einen Test zu schreiben, bevor man die Implementation ergänzt.
Werte
Bei aller Wichtigkeit der Prinzipien und Praktiken stellte sich uns die Frage, warum man diese einhalten sollte. Und wir stellten fest, dass es manchmal auch widerstrebende Kräfte geben kann und man sich für das eine oder andere Prinzip entscheiden muss. So kamen wir auf das Wertesystem. Es besteht aus vier Werten:
- Korrektheit – Die Anforderungen müssen korrekt umgesetzt sein.
- Wandelbarkeit – Der Code muss über viele Jahre leicht zu ändern und ergänzen sein.
- Produktionseffizienz – Wir müssen in der Softwareentwicklung effizient vorgehen.
- Kontinuierliche Verbesserung – Entwickler, Teams, ganze Unternehmen sollten sich ständig weiterentwickeln.
Jedes Prinzip und jede Praktik trägt zu mindestens einem dieser vier Werte bei. Manchmal mehr, manchmal weniger. Auf unseren CCD Postkarten haben wir dies durch Symbole gekennzeichnet.
Automatisiert Testen
Eines der nach wie vor drängenden Probleme für Softwareentwickler ist das Thema Testen. Man könnte ja glauben, dass heutzutage alle Klassen und Methoden automatisiert getestet werden. In vielen Projekten mag das der Fall sein. Jedoch begegne ich auch immer noch zu vielen Projekten, in denen die Testabdeckung viel zu gering ist. In der Folge dauert dann alles ewig. Denn bei jeder Änderung oder Ergänzung müssen die Tests manuell durchgeführt werden. Für die Wartbarkeit ist das natürlich völlig ineffizient. Es führt zu Unmut unter den Entwicklern, Auslieferungen verzögern sich, Kunden sind unzufrieden, usw.
Ich sage es daher ganz drastisch: Get your sh*t together!
Die Zeiten sind vorbei, in denen man sich ohne Tests irgendwie durchmogeln konnte. Auch wenn es keine leichte Aufgabe ist, es ist zwingend (!!!), dass automatisierte Tests ergänzt werden. Beginne mit Integrationstests, denn die sind mehr oder weniger unabhängig von der internen Struktur.
Legacy Code
Was tun mit Bestandscode? Ist Clean Code hier auch relevant? Vermutlich wird der alte Legacy Code nicht zu gut lesbar sein wie moderner Code. Die Strukturierung von Software hat sich entwickelt. Neue Muster und Architekturen sind entstanden. Vor allem aber ist der Legacy Code typischerweise sehr umfangreich und ständig in großem Tempo gewachsen. Daraus macht man nicht einfach so eine hübsche Blümchenwiese.
Die Lösungen sind an vielen Stellen beschrieben. Letztlich hilft nur, beständig in kleinen Schritten zu Refaktorisieren und dabei die Prinzipien des Clean Codes anzuwenden.
Software Craftsmanship
Ist Softwareentwicklung wirklich ein Handwerk? Auf Wanderschaft gehen und von den besten lernen… Alles nicht verkehrt, aber zu wenig konkret.
Ich glaube nicht daran, dass es gut ist, die Programmierung von Software mit der Herstellung eines Hauses, Autos oder sonstigen Branchen zu vergleichen. Software ist eben so grundsätzlich anders. Beim Hausbau kann man nicht nachträglich einen Keller unter das Haus bauen. Bei Software schon. Ich beobachte, dass uns der Versuch, Parallelen zu ziehen, eher in die Irre führt.
Für mich ist das Software Craftsmanship ebenfalls die falsche Assoziation. Es geht darum, seinen Job als Softwareentwickler professionell zu erledigen. Doch was bedeutet das ganz konkret? Für mich lautet die Antwort: Prinzipien und Praktiken einhalten! Wir haben die Clean Code Developer Initiative ins Leben gerufen, um die Professionalisierung mit konkreten Bausteinen zu ermöglichen.
Einführung der Clean Code Prinzipien
Wie geht man im Team vor? Wie überzeugt man alle Kollegen? Wie überzeugt man das Management, den PO, den Scrum Master?
Es ist nicht immer leicht, alle im Team an Bord zu holen. Einige Ideen dazu, wie man das Software Development im Team zur Berücksichtigung der Clean Code Prinzipien anregen kann:
- Coding Dojo – Veranstalte eine gemeinsame Codierübung. Das kann im Ensemble-Programming (früher Mob-Programming genannt) geschehen. Einer übernimmt das Keyboard, alle anderen denken mit. Die Rolle kann regelmäßig gewechselt werden. Alternativ können mehrere Pairs parallel arbeiten und man vergleicht am Ende die Lösungen. Ziel: alle im Team steigen in die Diskussion ein.
- Open Space – Du kannst auch einen Open Space veranstalten. Dabei gibt es keine feste Agenda, sondern alle Teilnehmer finden sich selbst zum Austausch zusammen. Voraussetzung ist allerdings, dass man eine größere Gruppe von Entwicklern zusammenbringen kann. Ca. 30 Personen sollten es schon sein.
- Externer Referent – Lade einen Referenten ein, der euch einen Impulsvortrag hält mit anschließender Diskussion. Oft sind es die Impulse von außen, die etwas in Bewegung bringen.
- Ein Training besuchen – Das Team kann gemeinsam an einem Clean Code Training teilnehmen. So wird ein gemeinsames Verständnis entwickelt für die Wichtigkeit der Clean Code Prinzipien.
Fazit
Patterns und SOLID mögen an manchen Stellen etwas helfen. Doch es braucht deutlich mehr, um Code zu produzieren, der wandelbar und korrekt ist. Die Prinzipien und Praktiken des Clean Code Developments sind mit insgesamt 45 Bausteinen umfangreich. Aus gutem Grund haben wir sie in Grade eingeteilt. Aber es hilft nichts, jeder Softwareentwickelnde muss da durch. Have fun!
German 
English