Since this post accompanies a talk in German, it is written in German, too.
Es gibt mittlerweile statische Analysewerkzeuge wie Sand am Meer. Dazu gehört die Berechnung verschiedener Komplexitätswerte, die Erkennung von dupliziertem Code und die Prüfung der Architektur sowie von Codierrichtlinien. Es gehört mittlerweile schon fast zum guten Ton eines oder mehrere dieser Werkzeuge im Rahmen der Continuous Integration einzusetzen. Viele der Tools sind kostenlos nutzbar und schnell eingerichtet. Trotzdem schafft es kaum ein Team auf dieser Basis die Qualität tatsächlich zu verbessern. Viele im Team wissen nicht wo die Ergebnisse abgerufen werden können, die meisten Warnungen sind nicht hilfreich, fachliche Änderungen lassen ohnehin keine Zeit da sie immer wichtiger sind, sogenannte ‘Aufräumaktionen’ provozieren noch zusätzliche Bugs und sowieso: Hat ja bisher auch funktioniert. Klingt vertraut? Warum erscheint statische Analyse für die meisten Teams als reine Zeitverschwendung während einige wenige Teams große Vorteile daraus ziehen?
Unsere Erfahrung aus mehr als sieben Jahren in denen wir verschiedenste Teams begleitet haben zeigt, dass es zwar nicht den einen alleinigen Grund gibt, es aber immer wieder die selben Faktoren sind, die dazu führen das der Schritt vom reinen Messen zur echten Qualitätsverbesserung nicht gelingt. Zu diesen Faktoren zählen: * Zielgerichtetes Messen: Die hilfreichen müssen von den nutzlosen oder gar schädlichen Metriken getrennt und die Analyse entsprechend konfiguriert werden. So etwas wie der ‘Maintainability Index’ oder auch schon die zyklomatische Komplexität sind mehr als fraglich. * Unmittelbares Feedback: Analysen die einmal in der Nacht laufen und deren Ergebnisse sich auf irgendwelchen HTML-Seiten verstecken lassen sich nicht gut berücksichtigen. Durch neue inkrementelle Analysen sind Ergebnisse in wenigen Sekunden verfügbar. * Explizite Qualitätsziele: Wahlloses Aufräumen im Code kostet Zeit und provoziert neue Bugs. Stattdessen sollten aktuelle Probleme behoben und Legacy-Probleme ignoriert werden. * Prozessintegration: Wenn keiner verantwortlich ist und keine Zeit für Qualitätsverbesserung reserviert wird, kann keine Verbesserung eintreten. Es muss festgelegt werden wer sich wann um die Qualität kümmert.
In dieser Session diskutiere ich den Sinn und Unsinn von statischen Analysen ung gehe auf die zentralen Faktoren ein. Dabei spiegelt dies nicht nur irgendeine Meinung wieder, sondern basiert auf einer Vielzahl wissenschaftlicher Untersuchungen sowie langjährigen Beobachtungen aus der Praxis. Wer dieser Session aufmerksam folgt ist danach in der Lage nicht nur zu messen, sondern die Qualität seines Code kontinuierlich zu verbessern.