Die Folien meines Vortrags von den Chemnitzer Linux Tagen 2012 zum Thema Software-Metriken mit Open Source Tools

1. Die Macht der Zahlen
Software-Metriken mit Open Source Werkzeugen
Gerrit Beine
mail@gerritbeine.com
1

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
2

3. Wie alles begann...
3

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!
4

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 // ...
5

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!
6

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

8. Was lernen wir daraus?
Wer nur 80% anstrebt erreicht davon auch nur 80%!
(Insgesamt sind das dann 64%)
8

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
9

10. Warum nur Open Source Werkzeuge?
10

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
11

12. Der Maintainability Index
Die Formel ● MI < 65: sehr schlechte Qualität
● 65 < MI < 85: mittlere Qualität
● 85 < MI: sehr gute Qualität
MI=
171 − 5, 2 × ln(aveV ) ● Für ein Projekt ermittelter Wert (mit
− 0, 23 × aveVG2 proprietärem Tool): 165
− 16, 2 × ln(aveLOC)
● Das muss ein gutes Projekt sein!
● Von Hand berechnet: 28
12

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!
13

14. Tools & Tipps
14

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
15

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
16

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
17

18. Beispiel einer PMD-Regel
18

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>
19

20. Beispiel Martin-Metriken
20

21. Verteilung der Abstraktheit
21

22. Verteilung der Instabilität
22

23. Martin-Distanz
23

24. Auswählen von Metriken
24

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
25

26. Kommunikation & Anwendung von Metriken
26

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
27

28. Viel Spaß noch!
Gerrit Beine
Stadtparking 18
08523 Plauen
http://www.gerritbeine.com/
28