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

  • 843 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
843
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Technisches Quality Management in grossen Java Projekten Toolunterstützte statische Codeanalyse zur Verbesserung der Wartbarkeit grosser Java Codebases Joachim Trost, Credit Suisse AG
  • 2. 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
  • 3. 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
  • 4. Applikationslandschaft Quelle: Presentation "Swiss Application Landscape Current State and Outlook", Credit Suisse, KSC Stephan Hug
  • 5. Applikationslandschaft Quelle: Presentation "Swiss Application Landscape Current State and Outlook", Credit Suisse, KSC Stephan Hug Beispiele für Java Applikationen
  • 6. 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
  • 7. 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
  • 8. 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
  • 9. NICHT Untersuchte Qualitätskategorien
    • Funktionale Aspekte
    • Performance (statisch nur teilweise möglich)
    • Laufzeitverhalten
    • Benutzeroberfläche
  • 10. 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
  • 11. 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
  • 12. 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
  • 13. 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
  • 14. Soll-Ist-Vergleich von Design und Codebase
  • 15. Soll-Ist-Vergleich von Design und Codebase
  • 16. Zyklenanalyse
  • 17. Tools
    • Checkstyle, PMD (integriert in Sotograph)
    • Sotograph, Sotoarc (aktueller Haupttool)
    • findbugs (experimentell)
    • Klocwork (als Ergänzung zu Sotograph im Aufbau)
    • Coverity (Evaluation anstehend)
  • 18. 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.
  • 19. 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
  • 20. 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.
  • 21. Qualitätstrend bei gemanagten Code Bases
  • 22. Qualitätstrend bei gemanagten Code Bases
  • 23. Qualitätstrend bei gemanagten Code Bases
  • 24. 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
  • 25. 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
  • 26. 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
  • 27. Ausblick
    • Flächendeckendes Messen von Qualitätsindikatoren
    • Buildbreaking Rules
    • Ausbau der Coding- und Designrichtlinien
    • Toolintegration
    • Dynamic Analysis
  • 28. Anhang
  • 29. 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.
  • 30. Die Prozesse des TechQM Project Application TechQM Management & Architecture Measure Approve Resolve Report
  • 31. Qualitätstrend bei gemanagten Code Bases
  • 32. Code Bases im Vergleich
  • 33. Code Bases im Vergleich
  • 34. Code Bases im Vergleich