Code-Metriken auf dem Prüfstand

Wie lässt sich die Qualität von Code bestimmen? Welche Kriterien sollen dafür hinzugezogen werden?
Eine mögliche Antwort könnte sein: "So gut wie die Abnahme-Testresultate des Kunden"... Stimmt, aber das würde erstens bedeuten, dass die Qualität des Codes erst gegen Ende des Projekts hin gemessen würde und dies auch nur als Momentaufnahme. Und zweitens, ein Abnahme-Test kann aus Zeit/Budget-Gründen nie das Gesamtsystem testen. Obwohl das eigentliche Testing einen sehr wichtigen Beitrag zum Erfolg eines Projektes beiträgt, ist es - was die Qualität des Codes betrifft - nicht unbedingt alles.

Eine der zentralen Herausforderungen, welche sich bei der Entwicklung von Software stellt, ist die, dass das gesamte System eigentlich nie in den Blick zu bekommen ist. Ein Entwickler sieht immer nur einen sehr kleinen Ausschnitt davon im Editor seiner Entwicklungsumgebung. Um es zu vergleichen... wie gut würde wohl ein Auto/Haus/Brücke/etc., wenn jeder der Beteiligten während des gesamten Entwicklungszeitraums den zu konstruierenden Gegenstand immer nur durch eine kleine Öffnung von sagen wir 20cmx20cm sehen würde? Ich möchte nicht als erster über die Brücke... :-) Und genau hier unterscheidet sich die Konstruktion von Software von der Konstruktion von anderen realen Dingen.

Die Frage, die sich also weiter stellt ist: "Wie bekomme ich eine einheitlichere Sicht auf die gesamte Codebasis, welche ein Softwaresystem ausmacht?"... und das bitte so, dass es die Entwickler in keinster Art und Weise stört. Genau in diese Presche springen Werkzeuge, welche Metriken und Codeüberprüfungen über den entwickelten Code erstellen. Sonar von Sonarsource ist so ein Werkzeug, welches a) Opensource ist und b) für Java-Projekte verwendet werden kann. Bei Namics haben wir im Januar ein Pilotprojekt gestartet, bei welchem von Beginn weg Code-Metriken erfasst und ausgewertet wurden. Diese Erfassung erfolgt automatisch und zeitgesteuert durch den Bamboo-Server , welcher als Continuous Integration Server bei Namics fungiert. Und es werden nicht nur Code-Metriken erfasst. Sonar bietet auch die Möglichkeit, neben Metriken den Code auch auf allgemein bekannte Programmierfehler hin zu überprüfen (Abschliessende Features siehe http://www.sonarsource.org/features/).

Das Fazit nach fast sechs Monaten fällt für mich durchwegs positiv aus. Die anfängliche Skepsis gegenüber einem weiteren Werkzeug, welches im Softwareentwicklungsprozess integriert ist, hat sich definitv "in Luft aufgelöst". Wir haben die Codemetriken mind. nach jedem dreiwöchigen Sprint im Team (mit dem Kunden) angeschaut und Massnahmen ergriffen wo notwenig. Gefunden haben wir einiges... Neben klassischen Programmierfehler (z.B. in einer Klasse equals() nicht jedoch hashCode() implementiert) haben wir auch zyklische Abhängigkeiten in Java-Packages entdeckt, welche sich mit der Zeit in einem grösseren Entwicklungsteam einschleichen.

Qualität beginnt auf unterster Stufe und das ist der Code, welcher im Projekt geschrieben wird. Und über die Zeit (z.b. Codebasen, in welchen über mehrere Jahre entwickelt wird) fällt jedes System tendenziell auseinander (siehe zweite Regel der Thermodynamik). Dieser Entropy des Codes kann mit Werkzeugen durchaus etwas entgegengehalten, die Tatsache jedoch nicht aufgehalten werden (nicht umsonst werden Softwaresysteme immer wieder neu geschrieben). Mittels Metriken und Codestyle-Checks lässt sich jedoch eine gute Basis für gesunden Code und die weiteren höherliegenden Qualitäts-Massnahmen legen.

Wer interesse an Sonar hat, kann unter http://nemo.sonarsource.org Beispielprojekte einsehen.