Good Times with Bad Code

#JCON2017 #SonarQube #SoftwareTesting

Die regelmäßige statische Analyse des Programmcodes ist in vielen Teams fester Bestandteil des Entwicklungsprozesses. Mit Hilfe von Tools wie SonarQube wird regelmäßig erhoben, inwiefern die eigenen Arbeitsergebnisse den eigenen Qualitätsstandards entsprechen. Gerade in wartungsintensiven Projekten oder bei der Übernahme von Legacy-Systemen fördern diese Analysen des Öfteren wenig Erfreuliches zu Tage. Doch schlechter Code kann uns helfen, zu besseren Entwicklern zu werden.

Technical-Debt, Mudholes, Blocker, Major-Issues usw. – bei der Codeanalyse gibt es ein breites Spektrum an Metriken und mitunter schlechten Nachrichten für uns. Doch abseits der vermeintlich – nüchternen sachlich technischen Analyse kann uns die statische Codeanalyse einen Einblick in die Organisations-
und Kommunikationsstrukturen eines Entwicklungsteams ermöglichen. Als Resultat können daraus Ansätze entstehen um bestehende organisatorische, kommunikative und/oder menschliche Probleme an der Wurzel anzugehen und das volle Potenzial eines Teams auszuschöpfen. Ein Blick über den technischen Tellerrand:

Das Gesetz von Conway – eine Renaissance Der Grundgedanke für den hier dargelegten Interpretationsansatz ist keineswegs neu. Melvin Conway formulierte ihn bereits 1968 wie folgt¹: „Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization‘s communication structure.“

Die IT-Architektur einer Organisation und deren Software spiegeln demnach also die Organisations- und Kommunikationsstrukturen des Unternehmens wieder. Diese als Conway’s Law bekannt gewordene These hat im Zuge der Diskussion über Microservice-Architekturen und agile Entwicklung in den letzten Jahren eine starke Renaissance erlebt, erklärt sie doch viele der durch diese Trends angestoßenen Veränderungen und Umstrukturierungen auf technischer wie organisatorischer Ebene.

Als Gegenentwurf zu großen oder gar monolithischen Systemen und Schnittstellen kapseln Microservices Funktionalität in kleinen unabhängigen Komponenten. Diese Komponenten werden so zugeschnitten, dass sie eine klar definierte beherrschbar komplexe Aufgabe in der Organisation erfüllen². Aufgrund dieser Prämisse richtet sich die IT-Architektur stärker an den tatsächlichen Unternehmensstrukturen aus, in denen ja auch jeweils spezifische Rollen und Aufgabenbereiche existieren.

Auf der organisatorischen Ebene ermöglichen Microservices aufgrund der Unterteilung anhand des Fachkontextes die effiziente Neustrukturierung von Teams in kleinere unabhängige Einheiten. Somit kann auch der organisatorische und kommunikative Overhead, den große Teams oder starke Abhängigkeiten mit sich bringen, reduziert werden³. Im Gegenzug muss das für einen oder mehrere Services zuständige Team interfunktional besetzt sein, um alle anfallenden Aufgaben (weitgehend) unabhängig bewältigen zu können. Funktionsübergreifend besetzte und autonom agierende Teams sind konstituierende Prinzipien der agilen Entwicklung, eine Microservice-Architektur begünstigt also den Einsatz agiler Methoden während die agile Entwicklung oft eine Grundvoraussetzung zur erfolgreichen Einführung von Microservices darstellt⁴.

Innerhalb der IT-Architektur des gesamten Unternehmens sind Entwicklungsteams – unabhängig ob nach fachlichen oder technischen Zuständigkeiten ausgerichtet – für einzelne Softwaresysteme und/oder –komponenten, wie z.B. Microservices, zuständig56. Sie erstellen, erweitern und warten diese weitgehend selbständig innerhalb der vorgegebenen Standards – oftmals mit großem gestalterischem Spielraum. Angenommen, das Gesetz von Conway gilt auch für den organisatorischen Mikrokosmos eines Teams oder einer Abteilung, spiegelt der dort erstellte Programmcode also die Organisationsstrukturen und Kommunikationsprozesse der agierenden Personen und Gruppen wider.

Von der Metrik zur Entwicklungskultur?

Im Programmcode zeigt sich die Handschrift eines Teams bzw. seiner Mitglieder. Hier werden Standards und alltägliche Vorgehensweisen sichtbar. Die statische Codeanalyse macht solche Strukturen über die kontinuierliche Erhebung und Dokumentation von Metriken und deren Visualisierung sichtbar. Sie kann uns
wertvolle Indikatoren dafür liefern, was in einem Softwareprojekt gut läuft und was nicht. Darin liegt nach Conway auch immer eine Aussage über das dazugehörige Team und seine Strukturen. Die Analyse kann uns also auch Hinweise geben, wo Stärken liegen und wo noch Unterstützung benötigt wird, sich individuell und gemeinschaftlich weiter zu entwickeln. Gerade für in Schieflage geratene Komponenten und Projekte ist die Schaffung und Verankerung eines gemeinsamen Qualitätsbewusstseins von großer Bedeutung.

Dabei ist das Entwickeln und Etablieren einer gemeinsamen Entwicklungskultur, d.h. von technischen Standards, abgestimmten Prozessen und den Kommunikationswegen und -formen, ein anspruchsvoller Veränderungsprozess für ein Team. Dieser Prozess bindet die Teammitglieder langfristig und beeinflusst diese nachhaltig. Vor diesem Hintergrund ist es umso wichtiger zu wissen, wo Stärken, Potenziale und Besonderheiten in einem Team liegen. Eine solche Veränderung ermöglicht einen deutlich nachhaltigeren Ansatz zur Verbesserung der Qualität von Software, als Maßnahmen, die alleinig auf eine Reduzierung messbarer technischer Schulden abzielen. Reine technische Maßnahmen berücksichtigen die mannigfaltigen Ursachen für die Entstehung der Missstände in der Softwareentwicklung nicht, da sie in der Analyse nicht betrachtet werden. Aber wie kann ein solcher Ansatz aussehen? Dazu einige Erfahrungen aus der Praxis mit SonarQube:

Die Regeln des Spiels

Ein erster Einstiegspunkt sind die Regelwerke des Teams. Zwar bieten PMD, CheckStyle und SonarQube mit ihren vordefinierten Regelsätzen (RuleSet, QualityProfile, QualityGate) den geballten Erfahrungsschatz zahlloser Projekte auf, jedoch ist es eher unwahrscheinlich, dass diese allgemeinen Vorgaben zu 100 Prozent passgenau für die individuellen Anforderungen und technischen Spezifikationen des eigenen Projektes sind. Hat ein Team also keine Anpassungen am jeweiligen Regelwerk vorgenommen, stellt sich die Frage, ob die Mitglieder überhaupt schon einmal gemeinsam über Standards und Best-Practices im Team gesprochen haben. Wird überhaupt auf Ergebnisse der Codeanalyse geachtet? Wird diese als wertvolle und konstruktive Ergänzung wahrgenommen oder als irrelevantes bis lästiges Kontrollinstrument? Fragen Sie ihr Team doch einmal.

Das King-Of-My-Castle-Syndrom

Weist ein Projekt eine hohe Anzahl an Code-Duplications auf, also Programmzeilen und -blöcken, die mehrfach in gleicher Form in einem Projekt existieren, kann dies auf verschiedene Ursachen hinweisen. Eine Ursache, die uns in der Praxis immer wieder begegnet, bezeichnen wir als das King-Of-My-Castle-Syndrom: Jedes Teammitglied betreut innerhalb des Teams seine eigene Softwarekomponente und nur diese. Wer eine Klasse erschafft, hat die alleinige Hoheit über diese, Änderungen durch andere Entwickler sind verpönt. Somit wird, falls Teile einer Komponente von einem anderen Teammitglied wiederverwendet werden wollen, dieser Code kopiert und in der eigenen Komponente, d.h. im eigenen Hoheitsbereich, eingefügt und angepasst. Dies erscheint einfacher, als eine Debatte mit dem Kollegen zu führen.

Die Gründe für die Entstehung solcher Konstellationen sind vielfältig und komplex. Oftmals spielen (informelle) Hierarchien und (mangelnde) Wertschätzung eine Rolle. Hier gibt es keine Patentlösung! Hier gilt es, mit allen Beteiligten eine gemeinsame Entwicklungskultur zu entwickeln, die solche Konstrukte nicht mehr benötigt. Ein langfristiger Prozess, der mit Team-Building Prozessen beginnt und über den Aufbau von Respekt, Vertrauen und vor allem einer wertschätzenden Kommunikationskultur zu Teams führt, die mit Spaß, Kreativität und Verständnis qualitativ und funktional angemessene den Kundenwünschen entsprechende Software entwickeln.

So einfach wie möglich – aber nicht einfacher

Komplexität und die dazugehörigen Metriken wie Cyclomatic-Complexity muss nichts Schlechtes sein. Sie kann sich aus technischen und fachlichen Anforderungen und Gegebenheiten erklären. Komplexität ist aber oftmals ein Indikator dafür, unter welchem Druck die Teammitglieder stehen. In den seltensten
Fällen stellt die erste funktionierende Version einer Komponente in der Entwicklung den technisch und organisatorisch sauberen „großen Wurf“ dar. Vielmehr wird sich diesem durch stetiges Refactoring und Reviews angenähert. Dabei wird die Komplexität der einzelnen Komponenten in der Regel reduziert und so auch die Metriken verbessert. Refactorings und Reviews sind meistens die ersten Opfer von Zeitdruck und Terminstress in Softwareprojekten – solange die funktionalen Anforderungen erfüllt sind, erhalten neue Features die höhere Priorität.

Insofern sind schlechte Komplexitätsmetriken ein Anlass, die Frage nach der Aus- und Belastung im Team zu stellen. Ist diese hoch, sollte die Planungen überdacht und Puffer für Refactorings in die Schätzungen der eigenen Arbeitspakete aufgenommen werden. Ist diese niedrig, kann das bedeuten, dass schlichtweg das Bewusstsein für den Nutzen von Refactorings und Komplexitätsreduzierung fehlt. Dann ist es wahrscheinlich sinnvoll über Weiterbildungsmaßnahmen zu sprechen.

Zurück in die Zukunft

Eine Metrik ist immer eine Momentaufnahme. Gerade in agilen Teams mit kurzen Entwicklungszyklen kann dies irreführend sein. Es lohnt sich daher, die Entwicklung der Metriken im zeitlichen Verlauf zu betrachten. SonarQube bietet über die TimeMachine-Ansicht die Möglichkeit, sich die Entwicklung von Kennzahlen visualisieren zu lassen. Sind hier Auffälligkeiten oder Entwicklungen zu beobachten, haben diese mit ziemlicher Sicherheit eine Verbindung zu organisatorischen oder individuellen Entwicklungen im Team.

Eine kontinuierliche Senkung der Rules-Compliance? Lag hier eine Stressphase vor? Hat jemand das Team verlassen? Eine Steigerung der LCOM4-Werte? Kann das Team die Komplexität noch handhaben? Braucht es ggf. Unterstützung durch einen Architekten oder bedarf es einer Neuorganisation der Komponenten? Auch für die Interpretation der zeitlichen Verläufe von Metriken gibt es keine einfachen Checklisten, aber umso mehr lohnt es sich, diese genauer zu betrachten, bevor unter dem Eindruck einer Momentaufnahme die falschen Maßnahmen abgeleitet werden.

Der Blick über den Tellerrand

Richtig betrachtet und begleitet kann die statische Codeanalyse wichtige Hinweise dafür geben, wie die Arbeit im Entwicklungsteam läuft, wo die Stärken und Schwächen liegen und wo Potenzial existiert, um die einzelnen Mitglieder und das gesamte Team gezielt zu unterstützen und zu fördern. Dabei sind schlechte Nachrichten oftmals diejenigen, die auch das größte Potenzial für Veränderungen aufweisen. Die Aufdeckung der darunterliegenden Ursachen und deren Milderung kann große Verbesserungen bewirken. Dabei zeigt sich aber immer wieder: Technische Probleme zu lösen ist in der Regel die kleinere Herausforderung auf dem Weg zu hoher Softwarequalität.

Was also tun, wenn die Teams kommunikative oder organisatorische Schwächen haben, die die Softwarequalität negativ beeinflussen? Die gute Nachricht ist: Es kann geholfen werden. Für jedes Team und jede Organisation gibt es die passende Vorgehensweise zur Verbesserung der Kommunikation, Veränderung des Konfliktverhaltens und Ausrichtung der Organisation im Team. Dabei sind Teambuilding Maßnahmen, Teamkodex-Workshops, Kommunikationstrainings und andere Maßnahmen nur Anregungen und Möglichkeiten aus einem noch viel größeren Portfolio. Wichtig ist, dass alles was für und mit dem Team unternommen wird, zu den Menschen passt. Das Ziel ist klar: die Verbesserung der Softwarequalität und die Schaffung eines Qualitätsbewusstseins im Team. Die These, die wir vertreten ist, dass ein gut eingespieltes, zielgerichtet kommunikatives und sachgerecht organisiertes Team bessere Qualität liefert.

Autor – Björn Meschede

Björn Meschede hat Wirtschaftsinformatik studiert und ist als Software Engineer und Projektleiter im Einsatz. In der viadee betreut er die interne Clean Code-Ausbildung für erfahrene wie neue KollegInnen.