featured image Clean Code Development Part 2: Warum und wie wir es umsetzen

November 02, 2018 / von Jenny Dornberger / In Quality

Clean Code Development Part 2: Warum und wie wir es umsetzen

Im ersten Teil dieses Blogartikels wurde erläutert, warum wir glauben, dass sich Clean Code Development lohnt. Außerdem wurde deutlich, dass insbesondere „Software Craftsmen“ ein Interesse daran haben saubere Codezeilen zu schreiben und dass diese in agilen Teamkonstellationen besonders gut wirken können. Im diesem Folgeartikel fassen wir die positiv wirkenden Ausgangsfaktoren noch einmal zusammen, bevor wir die Frage nach dem konkreten „Wie“ beantworten.

Warum wir uns entschieden haben auf Clean Code Development zu setzen

Clean Code Development innerhalb unserer Softwareentwicklung zu etablieren hat für uns aus mehreren Gründen Sinn ergeben. So planen wir unser Produkt, das Cloudogu EcoSystem, sowie einige Open Source Projekte an denen wir mitwirken ( SCM Manager und Smeagol) auch in den nächsten Jahren kontinuierlich durch neue Funktionalitäten zu erweitern. Clean Code Development hilft in dieser langfristigen Perspektive die Flexibilität zu wahren. Von Beginn an sauber gebaute Software kann – bei anhaltender Funktionsfähigkeit – laufend adaptiert werden, um neuen Anforderungen Stand zu. Die damit einhergehende steigende Komplexität bringt Herausforderungen mit sich, denen wir mit lesbarem Code effektiver begegnen können. Wir haben hier aus eigener Erfahrung gelernt. Es macht einen großen Unterschied, ob ein einzelner Entwickler mit einer guten Idee und einem kleinen Produkt, das er „wie seine Westentasche“ kennt, Anpassungen macht oder ob man versucht in einem stetig wachsenden Entwicklungsteam eine komplexe Plattform mit immer mehr Features für eine wachsende Nutzerzahl schafft.

Umsetzung durch Checklisten und Prinzipen-Konformität?

Wir halten es für sinnvoll und wichtig, sich die best practices des Buchs von Robert C. Martin im Alltag regelmäßig zu vergegenwärtigen und auf diese als akzeptierte Referenz zurück zu greifen. Dennoch glauben wir, dass Abhaklisten und strikte Prinzipen-Pocherei die Motivation eher bremsen, da nicht alle Regeln stur auf jedes IT-Projekt und jede Situation angewendet werden können. Wirken die Praktiken restriktiv und werden verbohrt von oben durchgedrückt, wird die Clean Code-Idee scheitern. So gibt es Pauschalisierungen im Buch, die mit Vorsicht zu genießen sind. Beispielsweise werden Kommentare an einigen Stellen als nicht wünschenswerter „smell“ stigmatisiert. Das spielt schreibfaulen Entwicklern zwar in die Karten, bei komplexeren Sachverhalten und Hintergründen, die man nun einmal nicht in selbstredendem Code ausgedrückt werden können, sind Kommentare aber durchaus notwendig und sinnvoll. In einem wertvollen Blogbeitrag zu diesem Thema rät der Autor Anfängern sich beim Kommentieren nicht auf das „was“, sondern das „warum“ zu konzentrieren und zu erläutern warum man die Codezeilen gerade so und nicht anders geschrieben hat.

Wie wir Clean Code bei uns umsetzen

Im Cloudogu-Team haben wir die Ideen und Hinweise des Teams um Robert C. Martin durch viele kleine Maßnahmen in unseren Entwicklungsalltag eingebunden. So ist die Print-Version des Bestsellers wahlweise im amerikanischen Original oder auf Deutsch Teil unseres Welcome Packages für neue Mitarbeiter. Der impliziten Anregung es auch zu lesen und sich damit (ggf. als Wiederholung) auseinander zu setzen, kommen neue Teammitglieder in der Einarbeitungsphase meist gern nach. So wird die Zeit bis zur festen Einbindung in die Sprintplanung sinnvoll genutzt.


„Als neues Teammitglied lese ich gerade in meiner Einarbeitung deutlich mehr Code, als ich schreibe“, meint auch René Pfeuffer. „Der bei Cloudogu gelebte Clean Code-Ansatz mündete in Codezeilen, die ich von Anfang an gut lesen konnte. Das hat mir wirklich geholfen mich in das neue, doch recht komplexe Produkt einzuarbeiten und nun selbst aktiv zu werden.“ Im agilen Alltag haben wir darüber hinaus Peer Reviews fest in unsere Entwicklungsprozesse eingebettet. Am Ende jeder Story wir jede Zeile neugeschriebene Codes von „einem fremden Paar Augen“ auf Lesbarkeit geprüft und potenziell „unsauberer“ Code mit dem Autor besprochen und refactored. Da das Ergebnis des Reviews von Erfahrung des Reviewers abhängt, bieten die Clean Code Prinzipien hier eine solide Grundlage, die sich jeder relativ schnell aneignen kann. So wird das alltägliche Coden innerhalb des Teams kontinuierlich verbessert.

In Clean Code ist Unit Testing eine Selbstverständlichkeit. Vorhandene Unit Tests sind bei der Entwicklung wertvoll, da sich darin neu geschriebener Code isoliert ausführen und viele Ausführungspfade durchlaufen lassen. Der besondere Nutzen von vorhandenen Tests zeigt sich dann aber bei der Wartung: Nach Erweiterungen oder Refactorings stellen diese als automatische Regressionstests sicher, dass vorhandene Funktionalität nicht beschädigt wurde. Auch bei Cloudogu haben wir den langfristigen Nutzen erkannt, weshalb sich die Frage nach Unit Tests bei uns nicht stellt. Ob diese test-driven oder nach der Implementierung geschrieben werden, kann jeder Entwickler im Einzelfall entscheiden. Erfahrungsgemäß führen aber das Schreiben von Testfällen vor der Entwicklung zu besserer fachlicher Abdeckung. Zusätzlich zum Unit Testing laufen bei uns statische Code Analysen , die best practices im Code verifizieren und gängige Fehlermuster identifizieren. Die Metriken aus der statischen Code Analyse fließen zusammen mit den Ergebnissen der Unit Tests und der Code Coverage in eine zentrale Platform ein. Dort werden diese Metriken gegen ein Quality Goal verifiziert (z.B. sollte die Code Coverage >= 80% sein). Nur wenn dieses eingehalten wird, sehen wir eine Story als „Done“ an. Wir bei Cloudogu haben uns für SonarQube entschieden, da es entsprechend unserer eigenen Philosophie Open Source ist und wir darin unsere verschieden technologischen Umfelder (Java, JavaScript, Go, etc.) einheitlich abbilden können. Darüber hinaus nutzen wir regelmäßige Ad-hoc-Schulungen zum Thema Clean Code in unseren „knowledgebase-Meetings“, um konkrete Codezeilen im Team zu diskutieren und uns auf gemeinsames Vorgehen zu einigen. Last but not least wird natürlich unser agiler Entwicklungsprozess nach jedem Sprint in der Retrospektive weiter optimiert.

Unser Fazit

Wir sehen im Clean Code Development einen „Implementierungsansatz“ direkt am Code, der, ergänzt um agile Methoden und ein Security Konzept der richtige Weg ist um qualitativ hochwertige Software zu produzieren. Schon der Diskurs im Team darüber, was genau im konkreten Fall unter „sauberer“ Software zu verstehen ist, ist wertvoll. In der Umsetzung des Ansatzes hilft es viele intrinsisch motivierte software craftsmen im Entwicklungsteam zu haben, die das Vorhaben nicht nur mittragen, sondern engagiert voran bringen. In unserem Verständnis sollte der Prinzipien-Reiterei allerdings eine gezielte Einbettung der best practices aus dem Standardwerk in die täglichen (agilen) Alltagsprozesse weichen.


Jenny Dornberger
Jenny Dornberger

- Marketing Manager -

Sie versucht die Welt der Softwareentwicklung für Kunden und Bewerber zu erklären – auch vor technischen Themen macht sie dabei nicht Halt!