Metriken allgemein
Im IEEE-Standard 1061 sind Softwaremetriken wie folgt beschrieben:
“Eine Softwaremetrik ist eine Funktion, die eine Software-Einheit in einen Zahlenwert abbildet. Dieser berechnete Wert ist interpretierbar als Erfüllungsgrad einer Qualitätseigenschaft der Software-Einheit.”
Jetzt stellt sich die Frage: Wozu benötigen wir Softwaremetriken überhaupt? Diese Frage lässt sich relativ leicht beantworten: Metriken werden benötigt, um Software und deren Qualität messbar zu machen. Hat man nun diese konkreten Werte vorliegen, kann man die Produkte verschiedener Anbieter anhand bestimmter Kriterien miteinander vergleichen, um eine Kaufentscheidung zu erleichtern. Ein weiterer Anwendungsfall für Softwaremetriken ist, dass sich mit ihnen der aktuelle Stand eines Projekts dokumentieren lässt. Werden Metriken über einen längeren Zeitraum gesammelt, erlauben sie Rückschlüsse auf die Entwicklung in einem Team und einem Projekt.
Das Thema Softwaremetriken ist nicht wirklich neu und auch nicht sonderlich spektakulär. Softwaremetriken sind seit vielen Jahren der Gegenstand von Forschung an verschiedensten Universitäten und damit sowohl praktisch als auch theoretisch sehr gut dokumentiert. Die Probleme treten allerdings schon auf, wenn man den ersten Schritt von der Theorie in die Praxis wagt: Für welche Programmiersprachen stehen welche Metriken zur Verfügung?
Etwas Recherche im Internet zeigt, dass es für Java, C und C++ Werkzeuge zur Erfassung von Softwaremetriken wie Sand am Meer gibt. Diese Tatsache ist allerdings auch nicht weiter verwunderlich, da die Forschungsarbeiten in erster Linie auf diesen Sprachen aufbauen und auch die Notwendigkeit eines lückenlosen Qualitätsmonitorings in diesen Bereichen in großem Maß vorhanden ist.
In unserer täglichen Arbeit sind Metriken im PHP Umfeld relevant. Auch hier existiert ein Satz an Werkzeugen, der die wichtigsten Metriken erfasst. Eine Anforderung an Messwerkzeuge ist, dass diese für den Entwickler keinen unnötigen Aufwand verursachen und die Metriken automatisiert erzeugt werden. Zu diesem Zweck generieren Werkzeuge wie beispielsweise phpunit, phpmd und phpcs Ausgaben in xml und lassen sich damit in eine Continuous Integration Plattform wie Jenkins integrieren. Ist dies erreicht, werden die Werkzeuge bei jedem Commit ins Versionskontrollsystem ausgeführt und es stehen allen am Projekt Beteiligten detaillierte Informationen über die Qualität des Quellcodes zur Verfügung.
Javascript Metriken
Da Javascript zunehmend an Bedeutung in der Entwicklung von Webapplikationen gewinnt, besteht auch hier Bedarf an Qualitätssicherung. Um eine möglichst hohe Qualität im Bereich Javascript durchzusetzen, müssen einige Voraussetzungen erfüllt sein. Das Wichtigste, was hier zu nennen wäre, ist die strikte Trennung von Darstellung und Logik. In der Praxis bedeutet dies: HTML stellt die Struktur der Seite und deren logischen Aufbau dar, CSS wird für die Darstellung und das Layouting verwendet und Javascript beinhaltet die Frontendlogik. Diese drei Bereiche sollten strikt getrennt und in jeweils eigenen Dateien abgelegt werden. Durch dieses Vorgehen können die einzelnen Teilaspekte unabhängig voneinander betrachtet werden.
LOC Metriken
Die einfachste Kategorie von Metriken, die in Javascript zur Verfügung stehen, sind die sogenannten LOC-Metriken (Lines of Code). Bei diesen Metriken werden die Zeilen des Quellcodes gezählt. Ein Tool, mit dem diese Metriken erfasst werden können, ist CLOC. Hier wird neben der reinen Anzahl an Zeilen unterschieden zwischen eigentlichen Codezeilen, Kommentaren und Leerzeilen und auf wie viele Dateien diese verteilt sind.
In Verbindung mit Konventionen, die für das Projekt vereinbart werden, wie beispielsweise die maximale Zeilenlänge oder höchstens ein Statement pro Zeile, machen LOC Metriken Sinn.
Unittests
Einen weiteren Satz von Werkzeugen bilden die Unittest-Frameworks. Unittests werden verwendet, um Bausteine von Software, die sogenannten Units, zu prüfen. Voraussetzung, um Unittests zu erstellen, ist eine sinnvolle objektorientierte Architektur der Anwendung.
Die erste Metrik, die für Unittests zur Verfügung steht, ist die Anzahl der Tests. Diese kann von einigen wenigen Tests bis hin zu mehreren Tausenden reichen. Die Zahl der Tests für sich gesehen ist allerdings kein Qualitätsmerkmal. Pro Unit, die getestet wird, sollten mehrere Tests existieren. Die minimale Anforderung ist ein Test für den positiven Fall und einer für den Fehlerfall. Je nach Logik in der Einheit, kann es sein, dass mehrere Fälle abgetestet werden müssen, um sicherzustellen, dass die gewünschte Funktionalität reibungslos abläuft.
Als Framework für die Unittests kann beispielsweise qunit verwendet werden. Ursprünglich entstand dieses Werkzeug für die Qualitätssicherung von jquery, kann allerdings unabhängig davon verwendet werden. Zur Automatisierung und Integration in eine Continuous Integration Plattform wie Jenkins wird jsTestDriver verwendet. Für dieses Tool existiert ein Adapter, der bestehende qunit Tests in jsTestDriver lauffähig macht.
Die Qualität von Unittests lässt sich kaum messen. Das einzige Mittel, das eine Aussage über die Qualität der Tests erlaubt, ist die Testabdeckung. Die Testabdeckung beschreibt, wie viel des Quellcodes wirklich durch die Tests abgedeckt ist, also, ob alle if-Statements berücksichtig sind und ob sämtliche Cases in Switch-Statements geprüft werden. Eine Testabdeckung von 100% bedeutet, dass sämtlicher Quellcode durch die Unittests einmal ausgeführt wurde. Aber auch eine hundertprozentige Testabdeckung stellt nicht sicher, dass sämtliche Kombinationen der Applikationslogik geprüft werden. Hier ist es notwendig, dass sich die Entwickler Gedanken über die auftretenden Fälle machen, Testpläne erstellen und diese gezielt durch Unittests absichern.
Jetzt kommen wir zu einem Werkzeug, das in keinem Javascript-Projekt fehlen darf: jslint. Dieses Programm durchsucht den Quellcode nach möglichen Problemen. Hierunter fallen sowohl die korrekte Einrückung des Quellcodes, als auch ein Komma zu viel am Ende einer Arraydefinition oder Zuweisungen in if-Statements statt einem logischen Operator.
Jslint
Jslint ist sowohl über ein Webformular als auch offline verfügbar. Da die Implementierung vollständig in Javascript erfolgte, ist es problemlos möglich, dieses Tool auf jedem Rechner über die Kommandozeile auszuführen, man benötigt lediglich eine Javascript Engine.
Im alltäglichen Gebraucht hat es sich als praktisch erwiesen, jslint als Pre-Commit Hook einzubinden und jeden Commit abzuweisen, der fehlerhaftes Javascript beinhaltet. Mit jslint4java generiert jslint xml-Ausgaben und kann damit auch in eine Continuous Integration Plattform wie Jenkins integriert werden.
CPD und Komplexität
Einen Schritt weiter geht das Javascript Plugin für die Qualitätsmanagement Plattform Sonar. Mit diesem Plugin werden neben den Prüfungen von jslint auch Codeduplikation und Komplexität gemessen.
Doppelter Code ist in vielen Projekten ein Problem, da aus Gründen der Zeitersparnis einfach Code kopiert wird und nicht sauber ausgelagert und von verschiedenen Stellen referenziert wird. Die Copy-Paste-Detection vergleicht allerdings nicht Codeblöcke Wort für Wort miteinander, sondern auf Ebene des Abstract Syntax Trees. Es nützt also nichts, einfach nur Variablen umzubennen oder Whitespaces einzufügen.
Zur Bewertung der Komplexität benutzt das Sonar Javascript Plugin die zyklomatische Komplexität des Quellcodes. Diese Metrik wird beeinflusst durch die Anzahl der Anweisungen und die Kontrollflüsse zwischen diesen. Weist Quellcode eine zu hohe Komplexität auf, ist er schwer zu lesen. Aus dieser Tatsache folgt ein erhöhter Wartungsaufwand und eine länger andauernde Einarbeitungsphase.
Metriken im Alltag
Zusammenfassend lässt sich sagen, dass die Qualitätssicherung im Bereich Javascript momentan noch in den Kinderschuhen steckt. Allerdings ist hier eine rasante Entwicklung zu beobachten. Vor allem im Bereich der Continuous Integration und Continuous Inspection ist eine erfreuliche Tendenz festzustellen. Immer mehr Werkzeuge lassen sich in Plattformen integrieren und ermöglichen so die regelmäßige Prüfung von Javascript Quellcode in einem Projekt.
Allgemein lässt sich festhalten, dass eine Metrik für sich alleine gesehen in den seltensten Fällen wirklich aussagekräftig ist. Kombinationen verschiedener Metriken oder Metrikgruppen hingegen erlauben Rückschlüsse auf die Qualität der Applikation.
Hier ein kurzes Beispiel, um diesen Sachverhalt zu verdeutlichen: Nimmt man eine Funktion, kann man über die LOC-Metrik herausfinden, aus wie vielen Zeilen diese Funktion besteht. Dieser Wert an sich erlaubt kaum eine Aussage, außer, dass eine große Anzahl von Zeilen nicht erstrebenswert ist, da sich diese Funktion dann tendenziell um mehr als eine Sache kümmert. Zieht man die zyklomatische Komplexität zu Rate, kann man schon qualifiziertere Aussagen treffen. Eine umfangreiche Funktion mit einer hohen Komplexität stellt ein Problem dar und sollte in kleinere Einheiten unterteilt werden; eine lange Funktion mit geringer Komplexität deutet auf eine prozedurale Funktion hin, die ebenfalls verbesserungswürdig ist. Sinnvoll sind demnach relativ kurze Funktionen mit moderater Komplexität.
Neben dem reinen Qualitätsaspekt kann durch Metriken auch die Performance des gesamten Teams oder einzelner Entwickler gemessen werden. Hier beginnt die Messung schon bei der Anzahl an Commits oder Lines of Code, die ein Entwickler erstellt. Auch hier gilt, jede Metrik kritisch zu hinterfragen. Interessanter sind dann Kombinationen wie beispielsweise die Anzahl der Zeilen pro Commit. Commits mit einer großen Anzahl von Zeilen sind meist problematisch, da sie dem Prinzip atomarer Commits widersprechen.
Die Metriken eines Projekts sollten allen am Projekt Beteiligten zur Verfügung stehen. Nur durch einen offenen Umgang lassen sich die Vorteile der Softwaremessung ausnutzen. Stehen dem Team alle Informationen über die Qualitätsaspekte der erstellten Software zur Verfügung, können die einzelnen Entwickler gezielt an ihren Schwächen arbeiten und das Projekt gemeinsam stabilisieren und den maximalen Nutzen aus ihren Fähigkeiten ziehen.
Last week I had the chance to attend an Agile Developer Skills Workshop in Berlin. The 3 day workshop is, next to a Scrum Master or PO Certification, a prerequisite for the Certified Scrum Developer, short CSD. I was very excited about the ADS wor