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.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Andreas Ebbert-Karroum
18.11.2020 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Andreas Ebbert-Karroum
Agile Principal Consultant
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.