Code wartbar: Qualität messen, Metriken

Präsentation zum Thema: "Code wartbar: Qualität messen, Metriken"—  Präsentation transkript:

1 Code wartbar: Qualität messen, Metriken

2 Inhalt Qualitätsbegriff Typische Probleme Ansätze zum Vermeiden dieser

3 Qualität

4 Typische Probleme Implementationsebene
Handwerklich schlechte Codierung riesige, komplexe Methoden unsorgfältige Fehlerbehandlung unleserliche Formatierung Reuse by Editor Falsche Verwendung der Technologie

5 Typische Probleme Designebene Schlecht strukturierte Klassenknäuel
Gottklassen

6 Typische Probleme Architekturebene Fehlende Architektur
Degenerierte Architektur

7 Big Ball of Mud Pattern A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct- tape and bailing wire, spaghetti code jungle. We’ve all seen them. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Brian Foot and Joseph Yoder,

8 Ansätze zur Verbesserung
Foote and Yoder: One of mud's most effective enemies is sunshine. > Expose your code to daylight!

9 Ansätze zur Verbesserung II
Kommunikation, Ausbildung, Kontrolle Code Reading, Pair Programming Regelprüfung auf Implementationsebene Software Metriken Regelprüfung auf Design- und Architekturebene

10 Regelprüfung auf Code-Ebene
Regelbeispiele Abstract types should not have constructors Assemblies should have valid strong names Avoid empty interfaces Avoid excessive parameters on generic types Avoid namespaces with few types Avoid out parameters Collections should implement generic interface Consider passing base types as parameters

11 Regelprüfung auf Code-Ebene II
In der IDE Evtl. auch in einem Monitoring-Werkzeug zur zentralen Überwachung Erfahrung Gut zum Kennenlernen einer neuen Kultur Einigung auf Regelsatz im Team häufig schwierig Findet bei erfahrenen Entwicklern kaum Probleme Kann in seltenen Fällen relevante Probleme identifizieren

12 Regelprüfung auf Code-Ebene III
Einfacher Einstieg mit FxCop von Microsoft (gratis) Code analysis tool that checks .NET assemblies for conformance to the Microsoft .NET Framework Design Guidelines. It uses reflection, MSIL parsing, and call graph analysis to inspect assemblies for more than 200 defects in the following areas: naming conventions, library design, localization, security, and performance. The package includes both GUI and command line versions of the tool, as well as the SDK to create your own rules. Mehr als 100 vordefinierte Regeln

13 Software Metriken Typische Kategorien mit Beispielen Größe Kopplung
Anzahl öffentliche Methoden ohne Getter und Setter Anzahl Zeilen einer Methodenimplementation Kopplung Anzahl verwendeter Artefakte Komplexität Cyclomatic Complexity, größte Verschachtelungstiefe Bad Smells Gottklassen, unbenutzte Artefakte

14 Software Metriken II Erfahrung
Liefert Werte, die interpretiert werden müssen Identifiziert viele Probleme, die keine sind Gut geeignet zum Identifizieren von Extremfällen Gut geeignet als Input für Qualitätsanalysen Metriken können erfolgreich zu Regeln befördert werden. Z.B. keine Methodenimplementierung darf mehr als 100 Zeilen haben. Metriken sind hauptsächlich als Zusatzinformation nützlich.

15 Software Metriken III Einfacher Einstieg mit Vil
Einfach bedienbare Metrikberechnungsengine Gratis für Assemblies mit < 100 Klassen Sinnvolle Standardmetriken Vil ermöglicht einen schnellen Einstieg. Wer den Metrikansatz seriös verfolgen will sollte sich nachher professionellere Werkzeuge anschauen.

16 Architekturebene Was kann man messen?
Zyklische Beziehungen auf allen Abstraktionsebenen Grosse duplizierte Code-Blöcke Strukturelle Architekturkonformität der Implementierung

17 Zyklische Beziehungen
Wieso sind zyklische Beziehungen problematisch? Artefakte die zyklisch gekoppelt sind können nicht einzeln getestet werden. Artefakte die in verschiedenen Zyklen gebraucht werden spielen dabei häufig mehrere Rollen, was sie schlecht verständlich macht. Artefakte die in verschiedenen Zyklen gebraucht werden können nicht mehr einfach ausgetauscht werden.

18 Zyklenbeispiel JDK 1.5: 1315 Klassen in 229 Packages hängen alle direkt oder indirekt von einander ab

19 Duplizierter Code Wieso ist duplizierter Code problematisch?
Je mehr Code desto schwieriger wird es die Übersicht zu behalten Fehler müssen an verschiedenen Stellen mehrfach geflickt werden Erfahrung in riesigen Projekten zeigt bis zu 70% des Codes sind Duplikate

20 Architekturkonformität
Voraussetzung um diese Messen zu können Explizite Repräsentation der Architektur

21 Abstraktionsebene Namespace/Verzeichnis /Paket

22 Abstraktionsebene Subsystem

23 Subsystemschnittstellenverletzung

24 Grapharchitekturen Erlaubte Beziehung Verbotene Beziehung

25 Schichtenarchitekturen
Strikte Schichtung durchbrochen (optional) Ober-fläche Interface Fach- logik Aufwärts-referenz: Immer illegal Daten- haltung Illegale Benutzungsbeziehungen:

26 Anwendung von Schichtenarchitekturen
Hauptschichtenmodell Prozess- und Library- Schichtenmodelle Vertikale Schichten z.B. für Produktlinien Verfeinern einer Schicht

27 Architekturprüfung Einfacher Einstieg mit "Sotograph for Architects"
Mächtige intuitive Architekturmodellierung Virtuelles Reengineering Strukturelles Verstehen Zyklenanalyse Während der Prerelease-Phase gratis Anfragen an

28 Werkzeugübersicht

29 Wichtig für Praktischen Einsatz
Monitoring Einfach und schnell Prüfen von relativ wenigen zentralen Regeln Trendunterstützung Prüfung in der IDE wo sinnvoll Visualisierung der Entwicklung über die Zeit für die Erfolgskontrolle Tiefenanalysen So viel Information wie möglich Erklären der Ursachen von Problemen Visualisierung im Kontext der Gesamtanwendung

30 Wichtig für praktischen Einsatz II
Reengineeringplanung Virtuelles refactoring Überwachung der Umsetzung Externe Spezialisten können eingefahrene Ideen hinterfragen

31 Wichtig für praktischen Einsatz III
Voraussetzungen Low-level Regelprüfung Muss in der IDE funktionieren Metriken Trend, Reports, Erklärungen Architekturprüfung Umgang mit Problemen, die nicht sofort behoben werden können Unterscheidung alte vs. neue Probleme

32 Werkzeugfamilie für Monitoring
Reposi-tory (RDBMS) Sotograph Client Swing-GUI Erstellen der Architektur und Metrik Modelle Visualisierung What-if-analysen Ad-hoc-abfragen HTML-GUI Schneller interaktiver Zugriff auf Information über Metriken und Regelverletzungen, ihre Veränderung über die Zeit und Hineinzoomen bis zum Quelltext Web Browser HTML and PDF Reports Schnelle Übersicht über die Veränderung relevanter Qualitätsaspekte für Gruppen von Softwaresystemen Sotoweb Reporting Add-ons Sotoreport

33 Nutzen des Qualitätsmonitoring
Ohne Architekturmonitoring Publizierte Studien zeigen Einsparungen im Bereich von 10-30% der Wartungskosten Mit Architekturmonitoring Die Einsparungen bei Erweiterungen müssten langfristig deutlich größer sein

34 Software-Tomography GmbH
Cottbus, München, Zug