ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Quality Management in large Java projects"

Technisches Quality Management in grossen Java Projekten Toolunterstützte statische Codeanalyse zur Verbesserung der Wartbarkeit grosser Java Codebases Joachim Trost, Credit Suisse AG

Inhalt
Einleitung
Basis und Elemente des Technical Quality Management (TechQM)
Qualitätskategorien, deren Metriken und Regeln
Verwendete Tools
Qualitätstrends von Managed Code Bases
Stärken und Schwächen des technischen Quality Managenents mittels statischer Codeanalyse
Ausblick

Referent, Organisation
Joachim Trost
verheiratet, 3 Kinder, CH seit 1989
Dipl. Physiker (seit 1984)
Technische IT, C, C++, Unix (seit 1979)
Java, EJB, Finanzsektor, seit 1998
Credit Suisse AG seit 2001
Solution Architect in der Credit Risk Officer (CRO) IT mit Schwerpunkt Code- und Designqualität, toolbasierte Code Reviews
Enge Kooperation mit der zentralen Architektur der CS IT CH und dem IT Efficiency Program

Applikationslandschaft Quelle: Presentation "Swiss Application Landscape Current State and Outlook", Credit Suisse, KSC Stephan Hug

Applikationslandschaft Quelle: Presentation "Swiss Application Landscape Current State and Outlook", Credit Suisse, KSC Stephan Hug Beispiele für Java Applikationen

Basis und Elemente des TechQM TechQM techn. Code Reviews statische Code Analyse Dev. Prozess QM e.g. CMMI Development Unit Testing Unit Integr. Testing Design Reviews Funktionale Code Reviews Funktionale u. Produktions Tests IT Operations QM e.g. ITIL

Basis und Elemente des TechQM Java TechQM Guidelines and Rules Dependency Analysis Design Code Mapping Verification Low Level Coding Rules Verification Antipattern Erkennung Java Application Plattform (JAP), IT Architecture Standards and Guidelines

Untersuchte Qualitätskategorien
Handwerkliche Qualität
Low Level Regeln
Antipattern
Dependencies
Dependency Cycles
statische Abhängigkeiten (Compile Time) versus dynamische Abhängigkeiten (Runtime)
Komplexität
lokale Komplexität
übergreifende Komplexität – Dependency Zyklen, Reflection, Annotations, verwendete Frameworks, Dependency Injection, Patternmania
Duplicated Code
Robustheit, Änderbarkeit, Wartbarkeit
Design-Code-Mapping

NICHT Untersuchte Qualitätskategorien
Funktionale Aspekte
Performance (statisch nur teilweise möglich)
Laufzeitverhalten
Benutzeroberfläche

Gemessene Regeln, Metriken, Bad Smells
Mengen - LOCs, # Classes, #Commentlines, #Javadoc Comments, #Methods etc.
Komplexität - Cyclomatic Complexity, Dependency Cycles
Javadoc – Existenz, formale Korrektheit
Exception Handling
Formatierung, Codestruktur
findbugs bad smells
CommonWeaknessEnumeration (CWE) bad smells und Antipattern
Dependency Zyklen auf Klassen-, Package- und Subsystemebene
Disclaimer:
Keine komplexen oder abstrakten Metriken
Messungen sind meist nur Hinweise und müssen durch den Reviewer, Architekt oder Entwickler interpretiert werden

Strukturierung der Messungen
Severities
3 Hauptseverities auf welche die toolspezifischen Severities gemappt werden
Warnwerte
mehrstufige Warnwerte für Qualitäts-, Grössen- und Komplexitätsmetriken
Aggregationen
Method, Class, Package, Subsystem, System/Applikation
Ermöglicht erst einen effizienten Überblick und die Handhabung der Messergebnisse grosser Code Bases

Typische Findings
Javadoc
mengenmässig mit Abstand die grösste Kategorie
Klassen-Interface-Javadoc und Interface-Methoden-Javadoc prioritär
Handwerkliche Qualität
Formatierung, Lesbarkeit
"verdächtige" Codefragmente, lokale Antipattern
Interface Contract Probleme
potentielle NullPointerExceptions
Null-Parameter, Wertebereiche
Exceptionhandling
Catch Exception oder Throwable
Informationsverlust während der Fehlerbehandlung
Exceptions als Teil der regulären Flow of Control
Empty Catch Blocks
Resourceleaks
Grösse, Komplexität
Duplicated Code Blocks
Grobgranulare Komponenten mit vielen Abhängigkeitszyklen
fragwürdige Verwendung von Reflection

Soll-Ist-Vergleich von Design und Codebase
"Tangible Design" notwendig
Designmodell das direkt auf Codeartefakte, also Buildkomponenten, Javapackages, Javafiles, gemappt werden kann.
Spezifikation über Subsysteme und deren erlaubten bzw. verbotenen Beziehungen
Referenzdesign mit Sotoarc legt erlaubte und verbotene Beziehungen fest
Modellierung des Designmodell (non-UML) aufbauend auf Codeartefakten
geschachtelte Subsystem und Layer sowie deren Beziehungen (erlaubt oder verboten).
Ohne Referenzdesign immer noch Struktur- und Dependencyanalyse möglich und wertvoll

Soll-Ist-Vergleich von Design und Codebase

Zyklenanalyse

Tools
Checkstyle, PMD (integriert in Sotograph)
Sotograph, Sotoarc (aktueller Haupttool)
findbugs (experimentell)
Klocwork (als Ergänzung zu Sotograph im Aufbau)
Coverity (Evaluation anstehend)

Tools – Sotograph, Sotoarc
http://www.software-tomography.ch/
Hauptmerkmale
Integration von Checkstyle, PMD
Ablage der Messungen in einer SQL-Datenbank
Speicherung und Auswertungen von Trenddaten
3 Benutzerschnittstellen
Webinterface Sotoweb zur Navigation in den Metriken, Regelverletzungen
FatClient Sotograph zur weitergehenden Auswertung und Verwaltung
FatClient Sotoarc zur graphischen Dependency und Designanalyse
gut dokumentiertes Datenmodell für direkte Auswertungen auf der SQL-Datenbank (MySQL)
Nutzung als Analyse- und Archivierungswerkzeug, d.h. Messungen anderer Tools werden ebenfalls in der Sotograph-DB abgelegt.

Tools – findbugs
http://findbugs.sourceforge.net/
Hauptmerkmale
Erkennung eines umfangreichen proprietären Satzes von "Bug Pattern", also AntiPattern http://findbugs.sourceforge.net/bugDescriptions.html
Patternscope ist auf ein File begrenzt
Momentan experimentelle Nutzung als Reviewwerkzeug
Komplexität der erkannten AntiPatterns ist höher als die von Checkstyle, PMD

Tools – Klocwork
http://www.klocwork.com/products/documentation/
Hauptmerkmale
Erkennen komplexer Antipatterns gemäss CWE http://cwe.mitre.org/
eigenes, leistungsfähiges Issuemanagement
momentan in der Pilotphase
ergänzt Sotograph und findbugs um die Erkennung wesentlich komplexerer Antipattern über mehrere Klassen hinweg.

Qualitätstrend bei gemanagten Code Bases

Stärken
Sehr frühe Erkennung von Regelverletzungen und Antipattern möglich
ohne Laufzeitumgebung möglich
Erhöht handwerkliche Qualität
Ergänzt und vereinfacht das Testing
Erhöht Wartbarkeit und Änderbarkeit
"Zero Defect"-Strategie von Projektbeginn an erfordert minimalen Mehraufwand
Refactorings mit aufwändigen Regressiontests entfallen
Fehlerkosten werden minimiert

Schwächen
Design-Code-Mapping erfordert relativ hohen Designaufwand
UML ist hier nicht ausreichend
Design muss permanent nachgeführt werden
Interface Barriere, Reflection - Dynamic Analysis notwendig
Je komplexer die Regeln, je grösser die Gefahr von False Positives.
Nutzennachweis schwierig
Akzeptanzprobleme – künstlerische Freiheit versus ingenieurmässiges Vorgehen
Macht keine direkte Aussage über funktionale Qualität

Fazit, Erfahrungen
Zero Fault Strategie von Anfang an ist optimal - nachträgliche Qualitätsverbesserung ist teuer - Legacysyndrom
Handwerkliche Qualität korreliert mit höherwertigen Qualitätsaspekten
Regressiontesting, (Unittests, Continous Integration) ist kritisch; auch für einfache Refactorings
Flächendeckendes Messen einiger wenigen Qualitätsindikatoren zur Korrelation mit Wartungskosten
Messen und Kommunizieren ist wichtiger als formelle Kontrolle
Tech QM ist nicht automatisierbar – Code Reviews, Issue Management sind notwendig
Payback erfolgt mittelfristig, nicht kurzfristig
Handwerkliche Qualität degeneriert genauso wie Design im Laufe des Unterhalts einer Applikation
KISS, vorallem für langlebige Applikationen

Ausblick
Flächendeckendes Messen von Qualitätsindikatoren
Buildbreaking Rules
Ausbau der Coding- und Designrichtlinien
Toolintegration
Dynamic Analysis

Anhang

Abstract
Der Vortrag wird die folgenden Punkte beleuchten:
Vorstellung der CS Organisationseinheit "Zentrale Architektur" und deren Verantwortungsbereich
Überblick über die Projektlandschaft der Credit Suisse (Applikationsdomäne, Grösse, Alter, technische Besonderheiten)
Darstellung der grundlegenden Architekturkonzepte und Qualitätsrichtlinien in diesen Projekten Organisatorische und prozessorientiere Massnahmen in der CS zur Sicherstellung dieser Qualitätsrichtlinien
Vorstellung der Metriken, Messungen und Prüfungen, um diese Qualitätsrichtlinien zu überwachen
Konzepte: Wie funktioniert Soll/Ist Abgleich für Software-Architekturen
Technische Funktionsweise eingesetzterTools
Für ausgewählten Metriken: Erläuterung warum gerade diese gemessen werden und welche Aussagekraft die Resultate haben
Anhand von ein oder zwei Projekten der CS: Konkrete Erklärung der gefundenen Regelverletzungen wie zyklische Strukturen, duplizierte Codeblöcke, zyklomatische Komplexität mit Codebeispielen Beschreibung des in den Projekten etablierten Trendmonitorings
Darstellung der Erfolge der Qualität sichernden Massnahmen: verbesserte Codestruktur und Architekturkonformität, reduzierter Wartungsaufwand, besserer Wiederverwendbarkeit
Ausblick: Welche weiteren Massnahmen sind für die Zukunft bei der CS geplant.

Die Prozesse des TechQM Project Application TechQM Management & Architecture Measure Approve Resolve Report

Qualitätstrend bei gemanagten Code Bases

Code Bases im Vergleich

ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Quality Management in large Java projects"

by Aberla

Accessibility

Categories

Upload Details

Usage Rights

Statistics

ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Quality Management in large Java projects" Presentation Transcript