Dr. Walter BischofbergerCode wartbar: Qualität messen, Metriken.

Dr. Walter Bischofberger Code wartbar: Qualität messen, Metriken

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

• Prüfung– 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• 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 BeziehungVerbotene Beziehung


Schichtenarchitekturen

Ober-fläche

Fach-logik

Daten-haltung

Interface

Strikte Schichtung durchbrochen (optional)

Aufwärts-referenz: Immer illegal

Illegale Benutzungsbeziehungen:


Anwendung von Schichtenarchitekturen

Vertikale Schichtenz.B. für Produktlinien

Verfeinern einer Schicht

Prozess- und Library-Schichtenmodelle

Hauptschichtenmodell


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 [email protected]


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


• 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

Wichtig für praktischen Einsatz III


Werkzeugfamilie für Monitoring

Reposi-tory

(RDBMS)

SotographClient

Swing-GUIErstellen der Architektur undMetrik ModelleVisualisierungWhat-if-analysenAd-hoc-abfragen

Sotograph

HTML-GUISchneller interaktiver Zugriffauf Information über Metrikenund Regelverletzungen,ihre Veränderung über dieZeit und Hineinzoomen biszum Quelltext

Web Browser

HTML and PDF ReportsSchnelle Übersicht über dieVeränderung relevanterQualitätsaspekte für Gruppenvon 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


www.software-tomography.com

Software-Tomography GmbHCottbus, München, Zug

Dr. Walter BischofbergerCode wartbar: Qualität messen, Metriken.

Documents

Transcript of Dr. Walter BischofbergerCode wartbar: Qualität messen, Metriken.