Tom Hombergs adesso AG

Wie so oft, gibt es auch beim Thema Codequalität keinen goldenen Weg, der garantiert zum Erfolg führt.

Codequalität ist allen Entwicklern ein Begriff, dennoch wird sie nur in wenigen Projekten nachvollziehbar gemessen und verfolgt. Warum ist das so? Wie misst man Codequalität überhaupt? Und wie gestaltet man den Einstieg in das Thema, sodass man Codequalität als belastbares Ziel im Projekt verfolgen kann? Dieser Artikel gibt ein paar Denkanstöße, wie man Codequalität für sich definieren und ein Bewusstsein für Codequalität im Projekt schaffen kann.

Codequalität wird meist anhand von diversen Metriken gemessen, die durch eine Analyse des Quellcodes oder des bereits kompilierten Bytecodes hervorgehen. Diese Analyse wird statische Codeanalyse genannt, da sie durchgeführt wird, ohne dass der Code tatsächlich ausgeführt wird. Durch statische Codeanalyse lassen sich verschiedene Metriken berechnen. Diese reichen von einfachen Code-Style-Metriken wie „Wie viele Leerzeichen darf ich zur Einrückung benutzen?“ über Komplexitätsmetriken wie „Wie tief sind meine if-Anweisungen verschachtelt?“ bis hin zu offensichtlichen Programmierfehlern wie „Wird eine Exception verschluckt?“. Die in der Java-Welt gängigsten Tools für statische Codeanalyse sind Checkstyle, FindBugs und PMD. Alle drei sind schon lange auf dem Markt und gut in Entwicklungsumgebungen und Build-Werkzeuge integriert, sodass Metriken aller Art nur ein paar Zeilen Konfigurationscode entfernt sind. Mit SonarQube gibt es auch ein relativ einfach einzurichtendes Codequalitätsdashboard, das aus einem Continuous-Integration-System automatisiert aktualisiert werden kann. Trotzdem werden diese Metriken häufig nicht ausgewertet oder gar nicht erst erhoben.

Ein Grund dafür ist sicherlich, dass die Metriken, die aus einer solchen Analyse herausfallen, in den meisten Fällen Verstöße gegen die eine oder andere Regel sind, also negative Auffälligkeiten im Code. Die Schwächen im eigenen Code möchte man nicht jedes Mal vorgesetzt bekommen, wenn man kompiliert oder den Build-Prozess startet. Es wäre also grundsätzlich sinnvoll, wenn aus einer statischen Codeanalyse auch positive Metriken herausfallen, aber das ist ein Thema für eine eigene Abhandlung. Selbst wenn man die Eitelkeit beiseite legt und sich mit den negativen Metriken befasst, wird man spätestens in einem mittelgroßen Projekt meist aufgrund der schieren Menge der Verstöße ausgebremst, wenn man nicht von Projektbeginn an penibel alle Verstöße entfernt hat (Kasten: Broken-Windows-Theorie).

Noch dazu wird jede Metrik von jedem Entwickler anders gewichtet. Dem einen sind die Magic Numbers im Code völlig egal, während die andere penibel darin ist, diese aus dem Code zu entfernen. Je nach Projektkontext kann es auch sein, dass bestimmte Metriken irrelevant sind. Duplizierter Code wird im Allgemeinen als negativ angesehen. Dabei kann er z. B. in einer Microservices-Architektur durchaus absichtlich eingeführt werden, um die einzelnen Services nicht zu eng miteinander zu koppeln.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 10.17 - "Java 9"

Alle Infos zum Heft
579810703Codequalität als Projektziel: Geht das überhaupt?
X
- Gib Deinen Standort ein -
- or -