Code wartbar: Qualität messen, Metriken

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

Qualität

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

Typische Probleme Designebene Schlecht strukturierte Klassenknäuel Gottklassen

Typische Probleme Architekturebene Fehlende Architektur Degenerierte Architektur

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, http://www.laputan.org/mud/

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

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

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

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

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 http://www.gotdotnet.com/team/fxcop/

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

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.

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. http://www.1bot.com/

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

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.

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

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

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

Abstraktionsebene Namespace/Verzeichnis /Paket

Abstraktionsebene Subsystem

Subsystemschnittstellenverletzung

Grapharchitekturen Erlaubte Beziehung Verbotene Beziehung

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

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

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 info@software-tomography.com

Werkzeugübersicht http://sharptoolbox.com/categories/code-analysers-standards-verifiers

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

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

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

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

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

Software-Tomography GmbH Cottbus, München, Zug www.software-tomography.com