Technische schulden abbauen

WPS - Workplace Solutions GmbH //// Hans-Henny-Jahnn-Weg 29 //// 22085 HAMBURG

Dr. Carola Lilienthal

[email protected]@cairolaliwww.wps.de

Technische Schulden in Architekturen abbauen

25.10.2015 //// Seite 2WPS - Workplace Solutions GmbH


Zwei Architekturziele für Langlebigkeit

Architekturziel 1: Wartbarkeit

• schnelle Fehleranalyse

• schnelle Anpassungen

• Analysierbarkeit und Verständlichkeit

• Reduktion von Komplexität

Architekturziel 2: Flexibilität

• Varianten von Geschäftsprozessen

• Geänderte Anforderungen

• Microservices und Skalierbarkeit

• Baukastenprinzip


Technischen Schulden = Architektur-Erosion

Grad derWartbarkeit

Neue Funktionalität pro Zeiteinheit

Korridor geringer technischer Schulden

Refactorings

Regelmäßige Architektur-Erneuerung

Architektur-Erosion

Wartung und Erweiterung


Maßnahmen gegen technische Schulden

� Festlegen von verbindlichen Architekturzielen

� Durchgängige Architekturprinzipien und Architekturstile

� Automatisches Testen und Refactoring

� Weiterbildung der Architekturen und Entwickler

� Regelmäßige Architekturanalyse und -Erneuerung


Architekturanalyse: Was ist das?

Findet sich die geplante Architektur (Soll-Architektur) in der Strukturen der implementierten Software (Ist-Architektur) wieder?

Plan mit

Klassen =

Soll-Architektur Ist-Architektur

≠ Sourcecode

DirectoriesDirectoriesPackagesNamespaces

Subsysteme KomponentenModule

Schichten


Erfahrungen und Erkenntnisse

� Typische Eigenschaften der Architektur nach Größen und Sprache

� Strukturelle Einfachheit und Einheitlichkeit ist der Schlüssel zum Erfolg

� Ohne Architektur-Erneuerung sammeln sich technische Schulden an

Erkenntnisse


Strukturelle Einfachheit der Architektur = Zeitgewinn!

Einfach, einheitliche Architektur

HierarchieModularitätMuster-

konsistenz





konsistenz


Muster auf Architekturebene: Vier Module

Modul

Grün

Modul

LilaModul

Orange

Modul

Blau


Musterkonsistenz: Was finden wir?

� Ist die Abbildung der Architektur in der Struktur des Codes zu erkennen?


Muster sinnvoll eingesetzt


Muster in Architekturen: Entwurfsmuster und Mustersprachen

User Interface

Domain

Application

Fachliches ModulFachliches Modul

Window

GUI

Model

ViewControl

ValueObject

Service

BusinessObject

Sch

ich

tun

g d

urc

h M

uste

r


Gute umgesetzte Mustersprache

☺ 90% des Sourcecodes lässt sich den Mustern zuordnen

☺ 0,1% Verletzungen in den Mustern

��

��


Entdeckung einer Mustersprache

☺ 80% des Sourcecodes lässt sich den 23 Mustern zuordnen

☺ 4% Verletzungen in den Mustern





konsistenz


Modularität: Entwurf nach Zuständigkeiten

�Hohe Kohäsion und lose Kopplung

�Responsibility Driven Design

�Separation of Concern

�Single Responsibility Principle


Modularität: Ausgewogene Größenverhältnisse

Typische Metriken:

� LOC pro Methode, Klasse, Package, Komponenten

� Duplizierter Code

� Zyklomatische Komplexität

� Ist das System auf den verschiedenen Ebenen ausgewogen?

� Welche Code-Abschnitte fallen durch ihre Größe besonders auf?

Anti-Pattern„Godclass“


Beispiel: Größenverhältnis und Kopplungsgrad

� Große Steuerungsklassen benutzen bis zu 100 – 500 andere Klassen

� Ausgewogene Größenverhältnisse führen zu geringerer Kopplung





konsistenz


User Interface

Domain

Application

Hierarchien in Architekturebene: Schichten und Module

Fachliches Modul B

Fachliches Modul B

Fachliches Modul A

Fachliches Modul A

Fachliche Schichtung

Tech

nis

ch

e S

ch

ich

tun

gFachliches

Modul CFachliches

Modul C


Zwei Dimensionen einer Architektur

Technische Schichtung Fachliche Schichtung

Leicht zu behebende

Verletzungen

Schwer zu behebende

Verletzungen

Eine Komponente verursacht die

Probleme

Eine Komponente verursacht die

Probleme


Fachliche Schichtung misslungen

Technische Schichtung Keine fachliche Schichtung

Wenige Schichten-

verletzungen

Fast alle 90 fachlichen

Komponenten brauchen sich gegenseitig


Zyklische Strukturen sichtbar machen, bevor ….

119 Klassen aus 4 Komponenten+ 28 weitere Klassen


sie immer weiter verklumpen!

327 Klassen aus 8 Komponentenbrauchen sich gegenseitig


Der Zwang zur Zyklenfreiheit

80% des Sourcecodes

9 Komponenten = 17 Subsysteme


Grundregeln struktureller Einfachheit für Architektur

Einheitliche Architektur


konsistenz

� Einheitlich und durchgängig

� Zyklenfreiheit auf allen Ebenen

� Zuständigkeit� Kopplung� Größenverhältnisse� Schnittstellen


Kostenfreie Werkzeuge

• SonarQube:

• Leitstand für Qualitätsmetriken

• Plattform für vielfältige Plugins

• JDepend:

• wenige Metriken

• einfache Abhängigkeitsanalyse

• JDepend + Google Architecture Rules:

• einfache Architekturbeschreibung

• Ndepend/CDepend:

• Metriken

• Abhängigkeitsanalyse

• XRadar:

• Analyse von Java-Projekten via maven

• Reports bezüglich Komplexität und Architekturverletzungen

• Moose

• Code City


Kommerzielle Produkte

� Axivion Bauhaus: Java, .Net, C/C++, Ada, VB und Cobol

� Lattix: Java, .Net, C/C++, Ada, Delphi und DB-Systeme

� Structure101: Java, C++, Ada

� SotoArc und Sonargraph: Java, .Net, C/C++, ABAP, PHP

• TeamScale

• Software-

Diagnostics


Vorgehen bei der Architekturanalyse und Verbesserung


Phase 1: Aufräumen

Schrittweise Weiterentwicklung der Architektur

Phase 2: Verbessern Phase 3: Erhalten

Phase 1: AufräumenAbgleich Soll-/Ist-Architektur

fehlende Architektur-konzepte ergänzen

Phase 2: VerbessernArchitektur diskutieren

und verbessernArchitekturregeln

festlegen

Phase 3: ErhaltenIm Architekturkorridor

bleibenLanglebigkeit fördern

Initialer

Workshop

Verletzungen behebenStrukturen einziehen

Analyse-Workshop

Anpassungen an neue Architektur-

Regeln

Nach-

sorgekleinere

Reparaturen


Leitstand für Verbesserungen im laufenden Betrieb

� Die Architekturziele sind im ganzen Team präsent und werden verfolgt.

� Softwarewartung und –Änderung ist einfacher und kostengünstig.

� Die Software ist stabil, flexibel und langlebig.

� Neue Mitarbeiter können nach kurzer Zeit produktiv mitentwickeln.

Ergebnis

TatsächlichesProblem?24%

34%

44%

54%

64%

74%

84%

94%

v1.0 v1.1_b1 v1.1_b2 v1.1_b3 v1.1 v1.2_b1 v1.2 v2.0_b1 v2.0_b2 v2.0

Architekturqualität

Feinentwurfsqualität

Implementierungsqualität

Testabdeckung


Vielen Dank für Ihre Aufmerksamkeit!

Dr. Carola LilienthalMitglied der

Geschäftsleitung

[email protected]

www.wps.de

+49 170 184 77 11

Diplom-Informatikerin

@cairolali

Technische schulden abbauen

Software

Transcript of Technische schulden abbauen