Vor- und Nachteile der LCOM4-Metrik in Sonar

Keine Kommentare

Wir benutzen in unseren Projekten Sonar, um Qualitätsprobleme in unseren Sourcen schon früh erkennen zu können. Eine wichtige Metrik ist dabei LCOM4: Lack of Cohesion of Methods IV. Das heißt, es soll gemessen werden, wie sehr Methoden und Felder eine Klasse zusammenhängen. Je größer der Zusammenhang, desto besser. Ideal wäre also eine LCOM4-Metrik von eins. Hat eine Klasse eine LCOM4 > 1, steht sie unter Verdacht, das Single Responsibility Principle zu verletzen. Die Klasse ist also eventuell für mehr als eine Sache verantwortlich, und könnte für ein sauberes Design in mehrere Klassen aufgeteilt werden. So weit zur Theorie.

In der Praxis ergeben sich einige Schwierigkeiten. Dies wird auch schon dadurch deutlich, dass die 4 in LCOM4 für den vierten Versuch steht, eine solche Metrik zu etablieren. Sonar ist zwar mittlerweile so schlau, Aspekte wie toString(), logger oder getter- und setter-Methoden korrekt zu berücksichtigen. Trotzdem erreichen mich aus den Projekten immer wieder Klagen, dass die LCOM4-Metrik ungerechtfertigter Weise zu hoch sei. Handlungsdruck entsteht, wenn der Build rot wird, weil die LCOM4-Metrik im Schnitt über alle Klassen einen Schwellwert übersteigt (in unseren Projekten liegt der bei 1,5). Wenn ich dann in die Teams gehe, um dem Problem auf den Grund zu gehen und Hilfestellung bei Designfragen anzubieten, stehen wir oft vor der gleichen Situation: Es wird ein Framework verwendet, welches eine Klasse durch Ableitung dazu zwingt bestimmte Methoden zu implementieren. Diese Methoden sind in der abgeleiteten Klasse zwar zusammenhanglos, machen aber im Kontext des Frameworks durchaus Sinn. Ein Prominentes Beispiel aus den Projekten ist das Web-Framework Vaadin.

Also, der Build ist rot, weil zu viele Klassen eine zu hohe LCOM4 haben. Der Build muss so schnell wie möglich wieder grün werden. Was ist zu tun? Falsch wäre es jetzt ein Dummy-Feld in den betroffenen Klassen einzuführen, nur um die Metrik aufzuhübschen. Eine Metrik bedarf immer der Interpretation und des Kontextes. Und derartige Maßnahmen, die ausschließlich dazu dienen die Metrik wieder „grün“ zu bekommen, das Design der Sourcen aber effektiv verschlechtern, sind auf lange Sicht gesehen kontraproduktiv.

Wie sähe also eine angemessene Reaktion auf eine schlechte LCOM4-Metrik aus? Richtig, das Team diskutiert, ob das Design der Klasse tatsächlich verbessert werden könnte, oder ob ein „Meßfehler“ vorliegt. Im Falle einer Designoptimierung sind die Konsequenzen hoffentlich klar 🙂 Ein Meßfehler lässt sich in Sonar leider noch nicht so leicht behandeln:

  • Die LCOM4-Metrik wird mit dem internen Werkzeug Squid gemessen. Dadurch entfällt die Möglichkeit die Klasse isoliert aus Messgängen mit PMD, Findbugs, etc. herauszunehmen
  • Ein Ausschluss mit einem Zeilenkommentar //NOSONAR geht nur für Regeln, die an einer konkreten Zeile hängen, nicht für Metriken.
  • Man könnte jetzt hergehen, und die ganze Klasse aus allen Messungen ausschließen, damit gießt man aber das Kind mit dem Bade aus.
  • Schön wäre es, Klassen mit einem hohen LCOM4-Wert reviewen zu können. Das geht aber nicht mit Metriken, sondern ebenfalls nur mit Regeln.
  • … und eine entsprechende Regel gibt es (noch) nicht.

So schwierig kann das ja nicht sein, sagte ich mir, und habe die Regel kurzerhand selbst implementiert. Damit sieht das ganze jetzt so aus. Hier sieht man, wie die Regel konfiguriert werden kann:

Wird der Schwellwert von einer Klasse überschritten, wird eine Regelverletzung generiert. Diese kann nur im Team geprüft und eventuell als „false-positive“ markiert werden.

Ich würde mich freuen, wenn der kleine Fix zügig den Weg ins reguläre Sonar findet. Wer experimentierfreudig ist, kann die angehängte SNAPSHOT-version herunterladen. Bei mir funktionierte die problemlos mit einem aktuellen Sonar 2.14. Viel Erfolg.

Tags

Andreas Ebbert-Karroum

Andreas Ebbert-Karroum ist Agile Principal Consultant bei codecentric und Product Owner von CenterDevice.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.