Gewachsene Systeme kontinuierlich und agil verbessern – praktische Auswege aus der Legacy-Hölle

Wir leben in einer Zeit, in der so manch altes Softwaresystem nicht mehr einfach durch ein neues ersetzt werden kann. Dennoch begegnen viele Entwickler den wichtigen, sogenannten „Legacy-Systemen“ mit einer gewissen ablehnenden Haltung. In diesem Workshop stellen wir vor, wie Entwickler und Softwarearchitekten mit agilen, systematischen Ansätzen und modernen Werkzeugen ihren (klaren) Kopf behalten können. Wir zeigen, wie gewinnbringende Maßnahmen identifiziert werden können, um Software wirtschaftlich und nachhaltig zu verbessern. Wir stellen Analysetechniken vor, welche uns mit Zahlen-Daten-Fakten Mittel gegen verkrustete Strukturen und überholte Entscheidungen liefern. Zusätzlich demonstrieren wir live, wie Software datenorientiert analysiert und schmerzfrei nachdokumentiert werden kann. Wir identifizieren spielerisch Risiken und Chancen, bewerten unsere Entwicklungsaktivitäten ganz neutral und machen technische Umbauarbeiten für Nicht-Techniker nachvollziehbar.

Transcript

1. Gewachsene Systeme kontinuierlich und agil verbessern – Praktische Wege aus der Legacy- Hölle Gernot Starke Fellow @gernotstarke Markus Harrer Senior Consultant @feststelltaste 11.03.2019 MÜNCHEN, SOFTWARE ARCHITECTURE SUMMIT
2. The biggest room in the world is the room for improvement. Helmut Schmidt Bundesarchiv, B 145 Bild-F048644-0032 / Wegmann, Ludwig / CC-BY-SA 3.0
3. Gewachsene Systeme
4. Was wir lernen
5. Bachelor-Studium Informatik Mathematik • Erste Semester: Analysis, Lineare Algebra, Stochastik • Weiterführende Semester: Integraltransformation, Wahrscheinlichkeitstheorie, Statistik Informatik • Erste Semester: Softwareentwicklung, IT-Systeme, Technische Informatik • Weiterführende Semester: Betriebssysteme, Netzwerke, Algorithmen und Datenstrukturen, Software Engineering, Theoretische Grundlagen Quelle: https://www.bachelor-studium.net/bachelor-studium-informatik
6. Bachelor-Studium Informatik Mathematik • Erste Semester: Analysis, Lineare Algebra, Stochastik • Weiterführende Semester: Integraltransformation, Wahrscheinlichkeitstheorie, Statistik Informatik • Erste Semester: Softwareentwicklung, IT-Systeme, Technische Informatik • Weiterführende Semester: Betriebssysteme, Netzwerke, Algorithmen und Datenstrukturen, Software Engineering, Theoretische Grundlagen Quelle: https://www.bachelor-studium.net/bachelor-studium-informatik In der Ausbildung nahezu Neuentwicklung
7. Womit wir arbeiten
8. Die Realität In der Softwareentwicklung sind heutzutage Wartung Capers Jones : The Economics of Software Maintenance in the Twenty First Century
9. Wartungsarbeiten • Erweiterungen • Kunden-Support und -Meetings • Reverse-Engineering • Fire-Fighting • Debugging • Performance-Optimierungen
10. Was nicht so gut funktioniert
11. Typischer Software-Lebenszyklus
12. Der ewige Konflikt Zu teuer. Zu viele Fehler. Zu hohe Aufwände. Zu lange Time-to-Market. Zu hohe technische Schuld. Zu wenig Verbesserung. Technologie zu schlecht. Zu wenig Innovation. Zu wenig Budget. Zu wenig Zeit. Management Techniker
13. Management Techniker Kommunikationsbarriere Risikoappetit Konsequenzen
14. Wege aus der Legacy-Hölle
15. aim42 im Überblick
16. aim42 One-Slider Architecture Improvement Method aim42 liefert… …konkrete Probleme („Schmerzen“) …Prioritäten („Schmerzkosten“) …Vorschläge für Abhilfen https://aim42.github.io/
17. aim42 • Besteht aus jahrelang gesammelten Projekterfahrungen • + wissenschaftlichen Belegen • Entsteht seit 2014 • Initiiert von Gernot Starke • Wird aktiv weitergepflegt • Bisher 67 Praktiken niedergeschrieben • Open-Source auf GitHub • Jede(r) kann mitmachen https://aim42.github.io/
18. aim42 Vorgehen Eine iterative Methode zur Architekturverbesserung analysieren identifiziere Probleme und Lösungsansätze bewerten schätze Kosten der Probleme und der Maßnahmen verbessern führe wichtige Maßnahmen durch Unterstützende Themen Probleme, Maßnahmen und deren Abhängigkeiten managen
19. aim42 im agilen Tagesgeschäft A E I Tagesgeschäft Tagesgeschäft Tagesgeschäft t Ta A A E I E I I A E I A Sprint 1 Sprint 2 Sprint 3
20. Systematisches und agiles Verbessern
21. Maßnahme Maßnahme Problem Problem aim42 Grundbegriffe Kosten Maßnahme Problem Ursache verursacht hat behebt verursacht behebt analysieren
22. Eiserne Regel Kosten Maßnahme Maßnahme Problem Problem Maßnahme Problem evaluieren
23. Priorisierung Maßnahme Maßnahme Problem Problem Maßnahme Problem evaluieren Ziele und Randbedingungen
24. Beauftragung Problem Problem Problem verbessern Maßnahme Maßnahme Maßnahme Ticket Ticket Ticket Ticket Ticket
25. • Weniger riskant, aber anstrengender Inkrementell statt Big Bang Kosten Wert Risiko Big Bang inkrementell Idee von https://blog.crisp.se/wp-content/uploads/2013/08/20130820-What-is-Agile.pdf übergreifend
26. aim42 Phasen im Detail
27. Phase 1: Analyze
28. „Wenn ich eine Stunde habe, um ein Problem zu lösen, dann beschäftige ich mich 55 Minuten mit dem Problem und 5 Minuten mit der Lösung.“ Albert Einstein https://commons.wikimedia.org/wiki/File:Albert_Einstein_Head_cleaned.jpg
29. Problem: Viele Quellen für Probleme • Das System • Software • Struktur, Implementierung • Technologie, Frameworks, • (externe + interne) Schnittstellen • Hardware & Infrastruktur • Dokumentation • Die Prozesse • Entwicklungs- und Anforderungsprozesse • Test und QS • Inbetriebnahme, Rollout, DevOps & Co. • Betrieb/Administration • Die Organisation • Management • Budgeting
30. Breiten- und Tiefensuche
31. Breitensuche hilft ganzheitlich „Nicht nur dort suchen, wo auch das Licht hinfällt…“
32. Iterative Breitensuche Iteration 2 Iteration 1 Breitensuche Stakeholder Code Kontext Qualität Daten Prozesse
33. Typische Quellen für Issues
34. Der Ursache nachgehen! Kombinierte Breiten- und Tiefensuche • Zuhören, nachfragen, ergründen • Tiefensuche mit „Warum?“ • Breitensuche mit „Was noch?“ • Gefundene Hotspots vornehmen ↓ Warum? ← Was noch? →
35. Kontextanalyse
36. Kläre generell, worum es geht! • Ein Systemkontext- Diagramm hilft bei Analysen • Schneller Überblick, wie das System aktuell arbeitet • Gut geeignet, um Risiken und Chancen zu verorten
37. Interviews
38. Stakeholder kennen viele Probleme
39. Stakeholder kennen aber auch Verbesserungschancen!
40. Stakeholder-Interviews • Einfach mit den Leuten reden • Gesprächsführung über Fragebögen Stakeholder-zentriert themenfokussiert
41. Beispiel Vorab-Fragebogen
42. Qualitative Analyse
43. Welche Qualitätsziele sind gefährdet? Soll-Ist-Vergleich • Soll: konkrete Qualitätsziele • Ist: Lösungsansätze • Code, Konzepte, Entscheidungen... https://jaxenter.de/knigge-softwarearchitekten-qualitaetsverbesserer-53107 Genauer: Vergleich von Anforderungen mit Lösung oder Lösungsansätzen
44. Kategorien von Qualitätszielen Hierarchisches Qualitätsmodell In dieser Form zu unspezifisch für „echte“ Arbeit... nach ISO 25010
45. Qualität greifbar machen Prio Merkmal Szenario 1 Performance Konfigurator zeigt mögliche Bestandteile + Ergänzungen < 5 sek an 1 Operability Konfiguratoren (Privatkunden) unter iOS & Android lauffähig 2 Performance Angebotspreis ermittelt < 10 sek 2 Changeability Neue Produktkategorie < 30T live ... <u.v.a.m.> Maßnahmen in Architektur Kein Caching möglicher Ergänzungen Mehrere Quellen von Daten für Bestandteile Ergänzungen teilweise durch falsche Daten in optischem Archiv behindert Konfiguration komplett in Flash Angebotspreis abhängig von Historie d. Kunden, d.h. oft Zugriff auf optisches Archiv notwendig <u.v.a.m.> 1 2 3 4
46. Quantitative Analyse
47. Die Vermessung von Software Indikatoren suchen • Codemetriken • Laufzeitmetriken • Chronologische Metriken • Community-Metriken • Organisatorische Metriken • Fehler / Baustein • Änderungsaufwand / Baustein • Dauer von x / Baustein (x=Test, Dev...) Auswertung CPU-Auslastung während Programmablaufs
48. Effektive Code-Analysen Abgleich unterschiedlicher Beobachtungen/Messungen • Mehrere Sichten auf die Software werfen • Messungen im Kontext betrachten • Nachvollziehbare, wiederholbare Analysen vornehmen =>Vom Problem über die Daten zur Erkenntnis!
49. Softwarearchäologie
50. Archäologen versuchen, die Hinterlassenschaften der Leute zu finden, die vor uns waren, und den Sinn dahinter zu verstehen. übersetzt aus „Archaeology at work“, English Heritage Education Service https://upload.wikimedia.org/wikipedia/commons/3/3d/Indianajones4.jpg
51. Beispiel Hot-Spot-Analyse Hot-Spot: komplexer Code, der häufig geändert wird Kombination von statischer und chronologischer Analyse Hot-Spot-Landkarte (Enclosure Diagram) aus Adam Tornhill: Software Design X-Rays
52. Linux Kernel • Einige Kopfmonopole • Hohe Entwicklerstreuung • Viel Abstimmungsarbeit Beispiel Wissensverteilung mit Daten aus dem Git-Repository
53. Beispiel Änderungsabhängigkeit mit Daten aus dem Git-Repository AddCommentRequestModel ChangeCommentRequestModel CommentData GetCommentRequestModel GetCommentResponseModel GetCommentsRequestModel GetCommentsResponseModel GetRangedCommentsRequestModel TimeDiffRequestModel TimeDiffResponseModel CommentResource CommentsResource Comment CommentGateway CommentSorter DynamoDbCommentGateway NotSoManyCommentsAvailable InMemoryCommentStorage PojoComment AddComment AddCommentRequestModel 0,00 0,29 0,50 0,18 0,29 0,00 0,29 0,29 0,50 0,50 0,76 0,81 0,50 0,59 1,00 1,00 1,00 0,65 0,59 0,80 ChangeCommentRequestModel 0,29 0,00 0,29 0,13 0,50 0,29 0,50 0,00 0,65 0,29 0,83 0,73 0,29 0,42 1,00 1,00 1,00 0,75 0,42 0,86 CommentData 0,50 0,29 0,00 0,59 0,29 0,50 0,29 0,29 0,50 0,00 0,76 0,81 0,00 0,59 1,00 1,00 1,00 0,65 0,59 0,80 GetCommentRequestModel 0,18 0,13 0,59 0,00 0,42 0,18 0,42 0,13 0,59 0,59 0,81 0,69 0,59 0,33 1,00 1,00 1,00 0,71 0,33 0,83 GetCommentResponseModel 0,29 0,50 0,29 0,42 0,00 0,29 0,00 0,50 0,29 0,29 0,67 0,73 0,29 0,42 1,00 1,00 1,00 0,50 0,42 0,71 GetCommentsRequestModel 0,00 0,29 0,50 0,18 0,29 0,00 0,29 0,29 0,50 0,50 0,76 0,81 0,50 0,59 1,00 1,00 1,00 0,65 0,59 0,80 GetCommentsResponseModel 0,29 0,50 0,29 0,42 0,00 0,29 0,00 0,50 0,29 0,29 0,67 0,73 0,29 0,42 1,00 1,00 1,00 0,50 0,42 0,71 GetRangedCommentsRequestModel 0,29 0,00 0,29 0,13 0,50 0,29 0,50 0,00 0,65 0,29 0,83 0,73 0,29 0,42 1,00 1,00 1,00 0,75 0,42 0,86 TimeDiffRequestModel 0,50 0,65 0,50 0,59 0,29 0,50 0,29 0,65 0,00 0,50 0,76 0,81 0,50 0,59 1,00 1,00 1,00 0,65 0,59 0,80 TimeDiffResponseModel 0,50 0,29 0,00 0,59 0,29 0,50 0,29 0,29 0,50 0,00 0,76 0,81 0,00 0,59 1,00 1,00 1,00 0,65 0,59 0,80 CommentResource 0,76 0,83 0,76 0,81 0,67 0,76 0,67 0,83 0,76 0,76 0,00 0,47 0,76 0,62 1,00 0,88 1,00 0,67 0,62 0,62 CommentsResource 0,81 0,73 0,81 0,69 0,73 0,81 0,73 0,73 0,81 0,81 0,47 0,00 0,81 0,54 1,00 0,91 1,00 0,73 0,54 0,54 Comment 0,50 0,29 0,00 0,59 0,29 0,50 0,29 0,29 0,50 0,00 0,76 0,81 0,00 0,59 1,00 1,00 1,00 0,65 0,59 0,80 CommentGateway 0,59 0,42 0,59 0,33 0,42 0,59 0,42 0,42 0,59 0,59 0,62 0,54 0,59 0,00 1,00 0,80 1,00 0,42 0,00 0,67 CommentSorter 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 0,00 1,00 1,00 0,65 1,00 1,00 DynamoDbCommentGateway 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 0,88 0,91 1,00 0,80 1,00 0,00 1,00 0,82 0,80 0,90 NotSoManyCommentsAvailable 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 0,00 0,50 1,00 1,00 InMemoryCommentStorage 0,65 0,75 0,65 0,71 0,50 0,65 0,50 0,75 0,65 0,65 0,67 0,73 0,65 0,42 0,65 0,82 0,50 0,00 0,42 0,71 PojoComment 0,59 0,42 0,59 0,33 0,42 0,59 0,42 0,42 0,59 0,59 0,62 0,54 0,59 0,00 1,00 0,80 1,00 0,42 0,00 0,67 AddComment 0,80 0,86 0,80 0,83 0,71 0,80 0,71 0,86 0,80 0,80 0,62 0,54 0,80 0,67 1,00 0,90 1,00 0,71 0,67 0,00 Legende Code abhängig Code unabhängig
54. https://www.youtube.com/watch?v=XAxseWdu5YA
55. Weitere Analysen
56. Analyse von Bestandsdaten 1. Struktur 2. Typen 3. Zugriffe • Read / write 4. Volumen • auch von Query-Results + Indizes 5. Korrektheit 6. Schutzbedarf 7. Verteilung/Dezentralisierung 8. Duplikation/Redundanz 9. Durchsatz -> Laufzeitanalyse Struktur / Typen ungeeignet für das Problem? Wonach ist Persistenz optimiert, read oder write? Haben wir besonders viel? Ist etwas besonders groß? Haben wir falsche Daten? Haben wir sensible Daten? Halten wir Daten mehrfach?
57. Analyse von Tests • Finden bestehende Tests relevante Fehler? • Gibt es (automatisierte) Tests: • Unit-, Integrationstests • Akzeptanztests • Sonstige ... • Infrastrukturtests • Chaos Monkey... • Laufen die Tests auch?
58. Prozessanalyse • Anforderungsprozesse • erheben, klären, managen • Entwicklungs- /Entwurfsprozesse • Architektur, Implementierung, Dokumentation • Betrieb • Deployment, Rollout, Administration, Monitoring • Management • Team- und Taskmanagement, Risikomanagement
59. Pre-Mortem Hands-On
60. Pre-Mortem Workshop Organisation • Relevante Stakeholder in einen Raum sammeln • 1-2 Stunden Workshop durchführen Nutzen • Risiken zum Projekt entspannt ermitteln • Möglichkeiten zur Problemumgehung identifizieren Kernidee: Sich selbst in die eigene Zukunft versetzen https://aim42.github.io/#Pre-Mortem
61. Pre-Mortem Effekt Umsetzung Sich selbst in ein fatales Zukunftsszenario versetzen • „Das Projekt ist katastrophal gescheitert!“ Wirkung • Perspektivenwechsel => raus aus dem „Hier & Jetzt“ • Positive Nutzung negativer Stimmen
62. Hands-On: Pre-Mortem Zukunftsszenario • Sie befinden sich zwei Jahre in der Zukunft • Sie arbeiten an einem Big-Data-System • Nicht alles läuft rund • Es wurde verfrüht live gegangen => Ihr Projekt ist katastrophal gescheitert!
63. Hands-On: Pre-Mortem Die „heutige“ Schlagzeile http://www.onlinewahn.de/generator/z-maker.htm
64. Hands-On: Pre-Mortem Interview • Eine mögliche Unterhaltung im Pre-Mortem- Workshop sehen Sie im folgenden Aufgabe • Ergründen Sie, woran es lag! • Bilden Sie Gruppen mit 3-4 Personen • Schreiben Sie pro Zettel ein Stichpunkt auf • Priorisieren Sie die Probleme von 1 (hoch) - X • Nach 5 Minuten sammeln wir ein
65. Hands-On: Pre-Mortem (5 Minuten) Fragen, die Ihnen helfen • Welche negativen Ereignisse gab es? • Was waren falsche Annahmen und Entscheidungen? • Warum ist das passiert? • Wieso haben wir das nicht kommen sehen? • Was hat noch dazu geführt? „Let's deploy to production“ http://bit.do/aimprod
66. Phase 2: Evaluate
67. Problemliste Issue List Sammlung an Probleme und Risiken • Häufigkeit und -auswirkungen geschätzt ID Issue Description Frequency min Value max Value Improvements Bezeichner Name Kurze Beschreibung Wie oft tritt das Issue auf? Minimaler Wert Maximaler Wert Links zum den Improvements
68. Lösungsansätze Improvement Backlog ID Verbesserung Beschreibung Min. Kosten Max. Kosten Behebt Probleme Bezeichner Kurzer Name Kurzer, aussage- kräftiger Text Geschätzte, minimale Kosten Geschätzte maximale Kosten Verknüpfung zu den adressierten Problemen Sammlung an möglichen Maßnahmen • Umsetzungskosten geschätzt
69. Kostenschätzung • Intervallgrößen nutzen • Unsicherheit in Zahlen ausdrücken • Annahmen explizit machen • Besser: Messen und beobachten Beispiel • Server muss täglich vom Betrieb neugestartet werden • Dauer 30 Min. an 5 Arbeitstagen bei 4 Wochen • 30 Min. × 5 Tage × 4 Wochen = 10 h Aufwand/Monat
70. Aufgabenpriorisierung • Qualitätsziele anhand der Geschäftsziele (bzw. des Risikoappetits) priorisieren • Qualitätsmerkmale austarieren • Ziele über Qualitätsszenarien greifbar und überprüfbar machen https://www.innoq.com/de/articles/2012/04/quality-driven-software-architecture/
71. Phase 3: Improve
72. Zusammenhänge grundsätzlich geltende Regeln kurz-/mittelfristige, taktische Verbesserungen langfristig geplant und durchgeführt
73. Kategorien langfristiger Ansätze «category» Long-Term Improvement Approach «category» Rewrite «category» Restructure «category» Data Migration «category» Improve Modularization «category» Brainsize (Scale-Down) «category» Improve Domain Focus System neu entwickeln Daten erhalten und in neue Formate überführen. Code neu schreiben oder grundlegend überarbeiten System oder Teile verkleinern System in Teilen überarbeiten Verantwortlichkeiten (im Code ) besser verteilen und klarer trennen. Fachlichkeit deutlicher von Technik trennen
74. Wertgetriebene Verbesserungen «category» Long-Term Improvement Approach Strangulate Bad Parts (aka „Switch“) «category» Rewrite Keep Data, Toss Code «category» Change By Split «category» Restructure Bridge-to- New-Town Chicken Little Butterfly Improve Cohesion «category» Data Migration Isolate Core Domains «category» Brainsize (Scale-Down) Big Bang (Cold Turkey) Change By Extraction Decconfigure Refactor Database «category» Value Based Improvement Change by Abstraction «category» Improve Modularization Split Along {CRITERION} «category» Improve Domain Focus Domain Context Bubble Strategies
75. aim42 in Action
76. Phase 1: Analyse Demos
77. Software Analytics
78. Datengetriebene Analyse Laden Filtern Joinen Aggregieren (reicht gefühlt in 80% der Fälle)
79. Der Notebook-Ansatz
80. Live-Demo Softwarearchäologie • Git • Jupyter Notebook • Python • pandas • matplotlib
81. Live-Demo System-Performance • vmstat • Open Zippy Analysis Platform For Data In Software • Jupyter Notebook • Python • pandas • matplotlib
82. Phase 2: Evaluate Beispiel
83. Beispiel Windräder
84. „Evaluate“ für Windräder Genauer: Steuerungssoftware
85. Exkurs: Turm-Dynamik (1) Viele Eingangssensoren • Wind (primär Strömung, Querströmung etc.) • Rotoren: Anstellwinkel, -geschwindigkeit • Wellenbildung im Turm (Ellipsoid) ... von http://www.cae-wiki.info/wikiplus/index.php/Windkraftanlagen-Turm_Dynamik
86. Exkurs: Turm-Dynamik (2) • (Manche) Wellen innerhalb des Turms verursachen Schäden an Rotor, Getriebe, Elektrik, Gebäude, Fundament • Software kann über Anstellwinken + div. Mechanismen die Wellen reduzieren, verringert damit aber auch erzeugte Strommenge • Berechnung mancher Wellenarten nur über Zeitsimulation möglich • Sehr rechenaufwändig • Bisherige SW/HW kann das nicht leisten
87. Issue: „SW kann keine Zeitsimulation“ Root-Cause-Analyse Ursachen: • Hardware/CPU zu knapp bemessen • Speicher zu knapp • Bisherige Modularisierung lässt Integration entsprechender Simulationsframeworks kaum zu
88. Konsequenzen „keine Zeitsimulation“ • Keine Möglichkeit gegen destruktive XY-Wellen zu steuern • Optionen dafür wären: variable Gewichte im Turm, Rotor-/Getriebeparameter, elektr. Widerstand o. ä.) • Bisherige Abhilfe: • Gesamtanlage auf physische Kompensation von XY- Wellen ausgelegt
89. Herleitung der Problemkosten (1) „keine Zeitsimulation“ => Turm 1,3x stärker auslegen • Erhöhter Stahl-/Betonverbrauch: • Anlagen-Gesamtgewicht 2500t, • Fundament 3000t • Einsparpotential: > 1200t Generator+Rotor wiegen über 100t
90. Herleitung der Problemkosten (2) „keine Zeitsimulation“ => Turm 1,3x stärker auslegen • Einsparpotential: > 1200t Beton • (grobe) Schätzung all-in Kosten Beton: 100€/Tonne • 1200t x 100€ = 120.000€ pro Anlage • Enthält: Material- und Lieferkosten • Enthält nicht: Schwerlastabgaben, kürzere Liefer-/Bauzeiten, Kosten von Stahlbewehrung Ca. 100 Anlagen pro Jahr Es gab dann größere Hardware…
91. Phase 3: Improve Demos
92. Das (r|w)ichtige Verbessern
93. Not all parts of a system will be well designed. Eric Evans
94. Isolate Core Domain(s) Vorgehen 1. Identifiziere „Domain“ bezogene Teile 2. Isoliere / Modularisiere und schütze diese Teile 3. Wende Refactoring, CleanCode, Einführung von Schnittstellen etc. auf diese Core Domains an Risiken • Prämisse: Wir bekommen nicht ALLE Teile wirklich verbessert • Domäne ist zu sehr mit dem Rest verwoben – Isolation nicht möglich • Benötigt gutes Verständnis für Domäne + vorhandenen Code «category» Improve Modularization «category» Restructure
95. Isolate Core Domain(s) 1 1. Identifiziere Core Domain(s) 2 3 2. Schütze Core Domain(s) vor externen „Eingriffen“ 3. Verbessere Core Domain(s)
96. Isolate Core Domain(s) • Fachliche Struktur von Bounded Context(s) identifizieren • Im Code sukzessive durch „verschieben“ von Anwendungsteilen verbessern • Einzelne Bounded Contexts durch Anti Corruption Layer (aka Adapter, Wrapper, Fassaden) isolieren
97. Improve Cohesion «category» Restructure Vorgehen 1. Identifiziere „zusammengehörige“ Teile 2. Isoliere / Modularisiere diese Teile 3. Wende Refactoring, CleanCode, Einführung von Schnittstellen etc. auf zusammengehörige Teile an Voraussetzungen Explizite Kohäsionskriterien! Risiken Feature- versus Komponententeams: Zuordnung erfolgt nach „Kenntnissen“ der Teams
98. Improve Cohesion 1 1. Identifiziere zusammengehörige Fragmente 2 3 «category» Restructure 2. Isoliere Fragmente 3. Verbessere Fragmente
99. Dev Build Source Code Graph Byte Code jQAssistant Neo4j Graph-DB Isolate Core Domain & ImproveCohesion Beispiel mit jQAssistant und Neo4j
100. :Class :Method :Field findings 2 changes 5 :Entity usage 100% name birthDate https://github.com/buschmais/spring-petclinic Die Softwarelandschaft als Graph Business Subdomain
101. types 16 findings 17 changes 15 usage 70% types 5 findings 39 changes 51 usage 80% Die Softwarelandschaft als Graph https://github.com/buschmais/spring-petclinic
102. Live-Demo Isolate Core Domain & Improve Cohesion • jQAssistant • Neo4j
103. Zusammenfassung
104. Management Techniker Kommunikationsbarriere Risikoappetit Konsequenzen
105. Management Techniker Risikoappetit Konsequenzen Qualitätsszenarien Breitensuche Tiefensuche Problemkosten Lösungskosten Software Analytics … …
106. Zusammenfassung Legacy Code ist und bleibt ein spannendes Thema! aim42 unterstützt bei der anspruchsvollen Arbeit!
107. Danke! Fragen? www.innoq.com innoQ Deutschland GmbH Krischerstr. 100 40789 Monheim am Rhein Germany +49 2173 3366-0 Ohlauer Str. 43 10999 Berlin Germany Ludwigstr. 180E 63067 Offenbach Germany Kreuzstr. 16 80331 München Germany Gewerbestr. 11 CH-6330 Cham Switzerland +41 41 743 01 11 Albulastr. 55 8048 Zürich Switzerland innoQ Schweiz GmbH Markus Harrer markus.harrer@innoq.com @feststelltaste Gernot Starke gernot.starke@innoq.com @gernotstarke
108. Anhang: Empfehlungen
109. Empfehlungen Internet • Architecture Improvement Method aim42 (Website): https://aim42.org • Architecture Improvement Method aim42 (Guide): http://aim42.github.io • Object-Oriented Reengineering Patterns OORP (PDF): http://scg.unibe.ch/download/oorp/ • Legacycode.rocks (Website, Podcast und mehr): https://legacycode.rocks • Dylan Beattie (Video): http://videos.ncrafts.io/video/275529979 • Adam Tornhill (Video): https://www.youtube.com/watch?v=SdUewLCHWvU
110. Empfehlungen Literatur • Michael Feathers: Effektives Arbeiten mit Legacy Code • Adam Tornhill: Software Design X-Ray • Christian Bird, Tim Menzies, Thomas Zimmermann: The Art and Science of Analyzing Software Data • Tim Menzies, Laurie Williams, Thomas Zimmermann: Perspectives on Data Science for Software Engineering • Wes McKinney: Python For Data Analysis Software • Python Data Science Distribution: https://anaconda.com • jQAssistant: https://github.com/JavaOnAutobahn/spring-petclinic • GitHub-Repo: https://github.com/feststelltaste/software-analytics • Tutorial: https://feststelltaste.de/mini-tutorial-git-log-analyse-mit-python-und-pandas
111. www.innoq.com SERVICES Strategy & technology consulting Digital business models Software architecture & development Digital platforms & infrastructures Knowledge transfer, coaching & trainings FACTS ~125 employees Privately owned Vendor-independent OFFICES Monheim Berlin Offenbach Munich Zurich CLIENTS Finance Telecommunications Logistics E-Commerce Fortune 500 SMBs Startups