Statische Code-Analyse zur Qualitätsmessung IT-Architektur-Workshop München, 28. November 2012 Dr. Karl-Heinz Wichert
Agenda Statische Code-Analyse Messen 2
Was ist statische Code-Analyse? Wikipedia: Statische Code-Analyse [ ] ist ein statisches Software- Testverfahren. Der Quelltext wird hierbei einer Reihe formaler Prüfungen unterzogen, bei denen bestimmte Sorten von Fehlern entdeckt werden können, noch bevor die entsprechende Software (z. B. im Modultest) ausgeführt wird. [ ] Die Analyse kann durch manuelle Inspektion erfolgen, aber auch automatisch durch ein Programm. Im Folgenden beschränken wir uns weitgehend auf automatische statische Code-Analyse durch Programme. 3
Beispiele für Analyse-Werkzeuge Compiler: Compile-Fehler, -Warnungen Checkstyle: Code-Layout Findbugs, PMD: Fehler und bad smells CPD, ConQAT: Clone-Detection SonarJ: Architektur-Konformität Eigenentwicklungen 4
Statische Code-Analyse in der Entwicklungsumgebung 5
Hinweise zur Nutzung von Einzelfall-Analyse Alle Entwickler im Team sollten die gleichen Werkzeuge und Konfigurationen benutzen Konfiguration laufend prüfen und modifizieren Fehler und Warnungen unterscheiden: Fehler: Muss beseitigt werden, kein supress warning erlaubt. Kriterium: Schadenshöhe und Vermeidbarkeit bei false positives Warnung: Entwickler entscheidet über Handhabung. Vermeiden. Eher wenige, scharfe Prüfungen in die Standard-Konfiguration Zusätzlich gelegentliche Analysen mit mehr Prüfungen und anschließender Bereinigung Statische Code-Analyse ist kein Wundermittel. Insbesondere gilt: Abwesenheit von Befunden garantiert keinen guten Code! 6
7
Was ist faul an diesem Code? Welches Analyse-Werkzeug warnt vor solchem Code? 8
Musterlösung /* remove leading "= " */ public static String cutleadingequalitysign(final String instring) { final String pattern = "= "; } if (instring.startswith(pattern)){ } return instring.substring(pattern.length()); else return instring; 9
Grenzen der statischen Code-Analyse Beispiele Was wird analysiert Code-Kommentare Ist ein Kommentar vorhanden? Hat er eine bestimmte Länge? Sind alle Parameter kommentiert? Code-Struktur Sind die Klassen klein? Sind die Methoden kurz? Ist die zykl. Komplexität gering? Ist die Parameterliste kurz? Was wird nicht analysiert Code-Kommentare Ist der Kommentar richtig? Enthält er mehr als triviale Info? Ist der Kommentar verständlich? Code-Struktur Sind die Abstraktionen fachlich und technisch sinnvoll? Sind die Namen prägnant? Sind die Parameter spezifisch? Test-Abdeckung Wie viel Code wird durchlaufen? Test-Abdeckung Entdeckt der Testfall Fehler? 10
Agenda Statische Code-Analyse Messen 11
Statische Analyse kann zwei Ziele verfolgen (Einzelfall-) Analyse Jeder Befund wird für sich betrachtet Einzelfall-Entscheidung über jeden Befund durch den/die Entwickler Möglichst direkte Integration der Analyse-Werkzeuge in die Entwicklungsumgebung In der Regel Vereinbarung über verwendete Werkzeuge und Prüfungen im Team Unterstützung der Entwickler in ihrem Qualitätsbemühen Messung Bestimmung der Codequalität oder Teilaspekten davon durch eine automatische Messung mit Code-Analyse-Werkzeugen Aggregation von Einzel-Befunden der statischen Code-Analyse auf eine Note, eine (Ampel-)Farbe, einen Skalenwert, In der Regel durch konfigurierbare Software-Qualitätsmessstände Steuerung von Softwarequalität durch objektive Messgrößen 12
Warum messen? You can t control what you can t measure Tom DeMarco, 1986 13
Messen in der IT Die drei interessanten Messgrößen Aufwand: Kosten, Zeit Größe: funktionaler Umfang, Leistungsfähigkeit Qualität: extern (Anwendersicht) und intern (Entwicklersicht) Ohne Messungen von Größe und Qualität ist ein klassischer industrieller Fertigungsprozess nicht möglich. Welchen Beitrag kann statische Code-Analyse leisten? 14
Kann man mit statischer Code-Analyse Größe und Qualität messen? Die Antwort hängt davon ab, wen man frägt: Forschung und Wissenschaft: Tool-Hersteller: Fallstudien: Agile Community: Im Prinzip ja Ja Egal Hauptsache es wird gemessen Nein 15
Das empfiehlt die Wissenschaft Qualitätsmodelle Qualitätsindikatoren: Messbare Sachverhalte (Software-Metriken) 16
Das sagen die Produkthersteller Viele freie, kommerzielle und firmeneigene Software- Messstände sind mittlerweile auf dem Markt Oft mit vorimplementiertem Qualitätsmodell und Konfigurationsmöglichkeit Mess-Sensoren sind die üblichen Analyse-Werkzeuge (NCSS, PMD, Findbugs, Clone-Detection, ) oder Varianten davon Qualitätsbewertung meist auf einer Verhältnisskala mit zeitlichem Trend und Modul-Differenzierung Qualitätsmodelle werden oft kalibriert durch Referenzmessungen an Software bekannter(!?) Qualität 17
(Schein-) Korrelation? Messbare Qualitätsgrößen Fähigkeit und Motivation der Entwickler Korrelation? Nicht messbare Qualitätsgrößen Spurious correlation: Messung zerstört die Korrelation! 18
Alles unter Kontrolle? 19
Fallstudien Disclaimer: Geringe Statistik, Aussage evtl. nicht repräsentativ Ausgangspunkt ist meist Code mit massiven Qualitätsmängeln Gestiegenes Qualitätsbewusstsein bei IT-Leitung oder massive Wartungsprobleme initiieren ein Qualitätsprogramm Management will messbare Ergebnisse für die Investition IT-Leitung und Team vereinbaren Messgrößen und berichten die Erfolge an das Management Messgrößen sind orientiert an leichter Messbarkeit. Bsp: Anzahl Compiler-Warnungen. Siehe spurious correlation Vorgehen ist trotzdem oft erfolgreich, da alle Beteiligten Qualitätsverbesserung wollen und die Messlatte niedrig liegt Kein Beweis, dass Qualitätsmessung funktioniert! 20
Die agile Community ist Spielverderber Martin Fowler: Introducing measured management without good measures leads to its own problems. Robert Austin* made an excellent discussion of this. He points out that when measuring performance you have to get all the important factors under measurement. Anything that's missing has the inevitable result that the doers will alter what they do to produce the best measures, even if that clearly reduces the true effectiveness of what they do. * Robert Austin: Measuring and Managing Performance in Organizations, Dorset House (June 1996) 21
Und was sagt Tom DeMarco heute? Immer noch: You can t control what you can t measure Aber: Kontrolle ist nicht so wichtig! 22
Fazit Statische Code-Analyse ist ein gute Hilfe für Entwickler zur Vermeidung mancher Qualitätsprobleme und Fehler Zum automatischen Messen von Qualität ist die Abdeckung durch geeignete Metriken vollkommen ungenügend Messen ohne geeignete Messgrößen ist nicht industriell, sondern irrational und schädlich Gute Software-Qualität entsteht durch ein motiviertes Team und ein geeignetes Vorgehen: Die Qualitätsverantwortung liegt beim Entwickler-Team Es wird nur fertige, hochwertige Software geliefert Schnelles Feedback durch kurze Zyklen 23
Ihre Fragen? Dr. Karl-Heinz Wichert Karl-Heinz.Wichert@iteratec.de Tel. 089 61 45 51-0 iteratec GmbH Inselkammerstr. 4 82008 München-Unterhaching www.iteratec.de 24