1

Die Macht der Zahlen

Software-Metriken mit Open Source Werkzeugen

Gerrit Beinemail@gerritbeine.com

2

Ziel des Vortrags

● Pro und Contra von Softwaremessungen abwägen● Vorstellungen vermitteln, darüber

● was Metriken im positiven Sinne bewirken können und

● was Metriken in Projekten anrichten können

● Einige Tools vorstellen, die sich gut zur Erstellung von Metriken eignen● Einen Überblick schaffen und zum Einsatz von Metriken motivieren

● Was nicht im Vortrag behandelt wird● Laufzeitmetriken, Testmetriken und Anforderungsmetriken

● Details zu den vorgestellten Metriken

● Details zu den vorgestellten Tools

3

Wie alles begann...

4

Wie alles begann...

● Gegeben sei ein Projekt mit relativ hoher Mitarbeiterfluktuation● Neue Mitarbeiter benötigen lange, um sich einzuarbeiten● Die erste Frage: Warum?● Die Antwort: Weil alles so kompliziert ist!● Die Lösung: Wir dokumentieren!

● Aber Moment...● Dokumentieren ist aufwändig und kostet Zeit● Niemand macht es gerne● Die bessere Lösung: Wir dokumentieren nur die Public API!

5

Und dann geschah Folgendes...

1 // ... 2 3 /** 4 * Delegates to privateMethod 5 */ 6 public void doSomething() { 7 this.doSomethingReally(); 8 } 9 10 private void doSomethingReally() {11 12 }13 14 // ...

6

Wir geben nicht auf

● Die Erkenntnis: So wird das nix!● Der nächste Schritt: alle Methoden müssen dokumentiert werden!

● Aber Moment...● Die 80/20 Regel sagt, dass wir eh nur 80% schaffen!● Die bessere Lösung: 80% aller Methoden müssen dokumentiert werden!

7

Jetzt passierte dies:

1 // ... 2 3 /** 4 * Return X 5 */ 6 public int getX() { 7 return this.x; 8 } 9 10 /**11 * Return Y12 */13 public int getY() {14 return this.Y;15 }16 17 // ...18 19 public void doSomethingExtremeComplex() {20 21 }22 23 // ...

8

Was lernen wir daraus?

Wer nur 80% anstrebt erreicht davon auch nur 80%! (Insgesamt sind das dann 64%)

9

Wie es weiter ging...

● Beschluss, dass alle Klassen, Schnittstellen, Methoden und Attribute zu 100% dokumentiert werden müssen.

● Aber Moment...● Auf den Inhalt kommt es an!● Was eine Methode macht, kann ein Entwickler selbst sehen.● Das Warum ist entscheidend● Also statt Prosa-Text einen Link auf die User Story oder das Requirement, die die Methode,

Klasse... begründen

● Erreicht: 93% Dokumentation (gemessen)● Neue Entwickler waren nach zwei Wochen fit

10

Warum nur Open Source Werkzeuge?

11

Warum nur Open Source Werkzeuge?

● Der wichtigste Grund: Transparenz● Außerdem: Verfügbarkeit

● Metriken, die nicht verstanden werden (können), werden in Frage gestellt● Metriken, die nicht jeder selbst anwenden kann, sind zu schwerfällig

● Open Source Werkzeuge sind frei verfügbar und machen transparent was sie tun

12

Der Maintainability Index

Die Formel

M I =171 5, 2 × ln(aveV )−

0, 23 × aveVG2− 16, 2 × ln(aveLOC)−

● MI < 65: sehr schlechte Qualität● 65 < MI < 85: mittlere Qualität● 85 < MI: sehr gute Qualität

● Für ein Projekt ermittelter Wert (mit proprietärem Tool): 165

● Das muss ein gutes Projekt sein!

● Von Hand berechnet: 28

13

Maintainability Index

● Die Anwendung enthält nur 35 Entitäten● Die Sicht links ist die Package-Ebene● Die durchschnittliche Anzahl von

Abhängigkeiten pro Package ist 35

● Was ist der Maintainability-Index in dem Fall wert?

● Das Bild versteht jeder, die 165 nicht!

14

Tools & Tipps

15

Tools & Tipps

● Vergesst die LOC – Lines of Code interpretiert jeder anders!● Stattdessen besser: NCSS – Non Commenting Source Statements als Meßgrundlage

● Interessante Fakten● avg NCSS / Klasse

● avg NCSS / Methode

● avg Complexity / Methode

● avg Warnings / NCSS

● avg Errors / NCSS

● Abdeckungsgrad der API-Dokumentation

● Wichtig dabei sind die Trends!

● Metriken immer mit Code Reviews verbinden

16

Wie ermittelt man diese Werte?

● Unter Java● PMD (http://pmd.sourceforge.net/)

Source Code Analyse, Regelbasiert, Komplexität und Fehlersuche

● FindBugs (http://findbugs.sourceforge.net/)Byte Code Analyse, Musterbasiert, Fehlersuche

● JavaNCSS (http://www.kclee.de/clemens/java/javancss/)Source Code Analyse, Fakten sammeln

● CheckStyle (http://checkstyle.sourceforge.net/)Source Code Analyse, Regelbasiert, Komplexität und Konventionen

● JDepend (http://clarkware.com/software/JDepend.html)Byte Code Analyse, Abhängigkeiten, Martin-Metriken

● OOMetrics & DependencyFinder (http://depfind.sourceforge.net/)Byte Code Analyse, Abhängigkeiten, Martin-Metriken, Chidamber & Kemerer

● Sonar (http://www.sonarsource.org/)Qualitäts-Management, integriert etliche der genannten Werkzeuge

17

Wie ermittelt man diese Werte?

● Unter PHP● PHP Depend (http://pdepend.org/)

Pendant zu JDepend

● PHP Mess Detector (http://phpmd.org/)Pendant zu PMD bzw. CheckStyle, haupsächlich an PMD angelehnt

● PHP_CodeSniffer (http://pear.php.net/package/PHP_CodeSniffer)Pendant zu CheckStyle

● Unter Perl● use strict; use warnings;

● Perl::Critic (siehe Vortrag von Renée Bäcker aus dem letzten Jahr)

● Perl::Metrics, Perl::Metrics::Lite, Perl::Metrics::Simple

18

Beispiel einer PMD-Regel

19

new DateTime() mit PMD verbieten

1 <rule name="DontUseNewDateTime" 2 message="Use of new DateTime() is not allowed" 3 class="net.sourceforge.pmd.rules.XPathRule"> 4 <description> 5 New DateTime object should be created using DateTimeFactory 6 </description> 7 <properties> 8 <property name="xpath"> 9 <value>10 <![CDATA[11 //VariableDeclarator[../Type[@Array='false']]12 //AllocationExpression/ClassOrInterfaceType[@Image='DateTime'] |13 //Statement//AllocationExpression/ClassOrInterfaceType[@Image='DateTime']14 ]]>15 </value>16 </property>17 </properties>18 <priority>3</priority>19 <example>20 <![CDATA[21 /* example code */22 ]]>23 </example>24 </rule>

20

Beispiel Martin-Metriken

21

Verteilung der Abstraktheit

22

Verteilung der Instabilität

23

Martin-Distanz

24

Auswählen von Metriken

25

Auswählen von Metriken

● Auswahl ist im Allgemeinen nicht trivial● Nicht jede Metriken passt zu jedem Projekt oder Entwickler

● Gute Strategie ist GQM (Goal – Question – Metric)● Zuerst Ziel festlegen

● Dann konkrete Frage(n) formulieren

● Schließlich Metrik(en) auswählen, die diese formale Antwort gibt

● Eine gute Einführung liefert Wikipedia: http://de.wikipedia.org/wiki/Goal_Question_Metric

26

Kommunikation & Anwendung von Metriken

27

Kommunikation & Anwendung von Metriken

● Metriken bieten Chancen und bergen Gefahren

● Metriken müssen abgestimmt und verstanden sein

● Metriken liefern immer nur Indizien

● Metriken, die mit absoluten Zahlen arbeiten, sollten immer im Trend betrachtet werden

● Abweichungen identifizieren und begründen – oder eliminieren

● Es gibt nur drei Arten von Problemen

● Bedrohende – für die gilt Null-Toleranz

● Unschönheiten – für die gilt eine Obergrenze, z.B. 8% der NCSS

● Egales – das sollte unbedingt ignoriert werden

● Tools sollten in den Entwicklungsprozess integriert werden

● Continuous Integration z.B. in Jenkins & Co.

● Ins Source Code Repository, z.B. über den pre-commit Hook von Subversion

28

Viel Spaß noch!

Gerrit Beine

Stadtparking 18

08523 Plauen

http://www.gerritbeine.com/