Technische schulden abbauen

WPS - Workplace Solutions GmbH //// Hans-Henny-Jahnn-Weg 29 //// 22085 HAMBURG
Dr. Carola Lilienthal
Carola.Lilienthal@wps.de
@cairolali
www.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 der
Wartbarkeit
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
DirectoriesDirectories
Packages
Namespaces
Subsysteme
Komponenten
Module
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ät
Muster-
konsistenz

Architektur
Muster-
konsistenz

Muster auf Architekturebene: Vier Module
Modul
Grün
Modul
Lila
Modul
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
View
C
o
n
t
r
o
l
ValueObject
Service
BusinessObject
SchichtungdurchMuster

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

Architektur
Muster-
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

Architektur
Muster-
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
TechnischeSchichtung
Fachliches
Modul C
Fachliches
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 Komponenten
brauchen sich gegenseitig

Der Zwang zur Zyklenfreiheit
80% des Sourcecodes
9 Komponenten = 17 Subsysteme

Grundregeln struktureller Einfachheit für Architektur
Einheitliche Architektur
Muster-
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äumen
Abgleich Soll-/Ist-Architektur
fehlende Architektur-
konzepte ergänzen
Phase 2: Verbessern
Architektur diskutieren
und verbessern
Architekturregeln
festlegen
Phase 3: Erhalten
Im Architekturkorridor
bleiben
Langlebigkeit fördern
Initialer
Workshop
Verletzungen
beheben
Strukturen
einziehen
Analyse-
Workshop
Anpassungen an
neue Architektur-
Regeln
Nach-
sorge
kleinere
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ächliches
Problem?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 Lilienthal
Mitglied der
Geschäftsleitung
cl@wps.de
www.wps.de
+49 170 184 77 11
Diplom-Informatikerin
@cairolali

Technische schulden abbauen

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (17)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Technische schulden abbauen

Ähnlich wie Technische schulden abbauen (20)

Mehr von Carola Lilienthal

Mehr von Carola Lilienthal (7)

Technische schulden abbauen