Technische schulden abbauen

790 Aufrufe

Veröffentlicht am

Vortrag auf dem Architecture Gathering in München

Veröffentlicht in: Software
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
790
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
86
Aktionen
Geteilt
0
Downloads
22
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Technische schulden abbauen

  1. 1. 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
  2. 2. 25.10.2015 //// Seite 2WPS - Workplace Solutions GmbH
  3. 3. 25.10.2015 //// Seite 3WPS - 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
  4. 4. 25.10.2015 //// Seite 4WPS - Workplace Solutions GmbH 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
  5. 5. 25.10.2015 //// Seite 5WPS - Workplace Solutions GmbH 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
  6. 6. 25.10.2015 //// Seite 6WPS - Workplace Solutions GmbH 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
  7. 7. 25.10.2015 //// Seite 7WPS - Workplace Solutions GmbH 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
  8. 8. 25.10.2015 //// Seite 8WPS - Workplace Solutions GmbH Strukturelle Einfachheit der Architektur = Zeitgewinn! Einfach, einheitliche Architektur HierarchieModularität Muster- konsistenz
  9. 9. 25.10.2015 //// Seite 9WPS - Workplace Solutions GmbH Strukturelle Einfachheit der Architektur = Zeitgewinn! Einfach, einheitliche Architektur HierarchieModularität Muster- konsistenz
  10. 10. 25.10.2015 //// Seite 10WPS - Workplace Solutions GmbH Muster auf Architekturebene: Vier Module Modul Grün Modul Lila Modul Orange Modul Blau
  11. 11. 25.10.2015 //// Seite 11WPS - Workplace Solutions GmbH Musterkonsistenz: Was finden wir? Ist die Abbildung der Architektur in der Struktur des Codes zu erkennen?
  12. 12. 25.10.2015 //// Seite 12WPS - Workplace Solutions GmbH Muster sinnvoll eingesetzt
  13. 13. 25.10.2015 //// Seite 13WPS - Workplace Solutions GmbH 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
  14. 14. 25.10.2015 //// Seite 14WPS - Workplace Solutions GmbH Gute umgesetzte Mustersprache ☺ 90% des Sourcecodes lässt sich den Mustern zuordnen ☺ 0,1% Verletzungen in den Mustern
  15. 15. 25.10.2015 //// Seite 15WPS - Workplace Solutions GmbH Entdeckung einer Mustersprache ☺ 80% des Sourcecodes lässt sich den 23 Mustern zuordnen ☺ 4% Verletzungen in den Mustern
  16. 16. 25.10.2015 //// Seite 16WPS - Workplace Solutions GmbH Strukturelle Einfachheit der Architektur = Zeitgewinn! Einfach, einheitliche Architektur HierarchieModularität Muster- konsistenz
  17. 17. 25.10.2015 //// Seite 17WPS - Workplace Solutions GmbH Modularität: Entwurf nach Zuständigkeiten Hohe Kohäsion und lose Kopplung Responsibility Driven Design Separation of Concern Single Responsibility Principle
  18. 18. 25.10.2015 //// Seite 18WPS - Workplace Solutions GmbH 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“
  19. 19. 25.10.2015 //// Seite 19WPS - Workplace Solutions GmbH 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
  20. 20. 25.10.2015 //// Seite 20WPS - Workplace Solutions GmbH Strukturelle Einfachheit der Architektur = Zeitgewinn! Einfach, einheitliche Architektur HierarchieModularität Muster- konsistenz
  21. 21. 25.10.2015 //// Seite 21WPS - Workplace Solutions GmbH 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
  22. 22. 25.10.2015 //// Seite 22WPS - Workplace Solutions GmbH 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
  23. 23. 25.10.2015 //// Seite 23WPS - Workplace Solutions GmbH Fachliche Schichtung misslungen Technische Schichtung Keine fachliche Schichtung Wenige Schichten- verletzungen Fast alle 90 fachlichen Komponenten brauchen sich gegenseitig
  24. 24. 25.10.2015 //// Seite 24WPS - Workplace Solutions GmbH Zyklische Strukturen sichtbar machen, bevor …. 119 Klassen aus 4 Komponenten + 28 weitere Klassen
  25. 25. 25.10.2015 //// Seite 25WPS - Workplace Solutions GmbH sie immer weiter verklumpen! 327 Klassen aus 8 Komponenten brauchen sich gegenseitig
  26. 26. 25.10.2015 //// Seite 26WPS - Workplace Solutions GmbH Der Zwang zur Zyklenfreiheit 80% des Sourcecodes 9 Komponenten = 17 Subsysteme
  27. 27. 25.10.2015 //// Seite 27WPS - Workplace Solutions GmbH Grundregeln struktureller Einfachheit für Architektur Einheitliche Architektur HierarchieModularität Muster- konsistenz Einheitlich und durchgängig Zyklenfreiheit auf allen Ebenen Zuständigkeit Kopplung Größenverhältnisse Schnittstellen
  28. 28. 25.10.2015 //// Seite 28WPS - Workplace Solutions GmbH 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
  29. 29. 25.10.2015 //// Seite 29WPS - Workplace Solutions GmbH 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
  30. 30. 25.10.2015 //// Seite 30WPS - Workplace Solutions GmbH Vorgehen bei der Architekturanalyse und Verbesserung
  31. 31. 25.10.2015 //// Seite 31WPS - Workplace Solutions GmbH 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
  32. 32. 25.10.2015 //// Seite 32WPS - Workplace Solutions GmbH 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
  33. 33. 25.10.2015 //// Seite 33WPS - Workplace Solutions GmbH 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

×