Rescue the Mud-olith

In der letzten Dekade hat die Komplexität von Software immer stärker
zugenommen. Oftmals war der Beginn harmlos: eine Hand voll Entwickler,
eine Kerndomäne, das Leben war einfach. Doch dann passierte etwas
Schreckliches: Das Produkt wurde erfolgreich. Und mit diesem Erfolg wurde die Entwicklungsmannschaft größer und größer, Subdomäne um Subdomäne kam hinzu und mehr und mehr Features wurden angefragt.

Mittlerweile gibt es viele dieser "historisch gewachsenen" Projekte und
die Arbeit an ihnen ist nicht einfach. Einerseits sind sie die "Cash
Cows" mit dutzenden oder hunderten an Personenjahren, welche in die
Entwicklung investiert wurden. Andererseits sind sie mittlerweile der
typische "Big Ball of Mud". Patterns werden inkonsistent verwendet,
alles scheint von allem abzuhängen und neue Features oder Bugfixing
verschlingen wahnsinnige Mengen an Budget.

Wir wissen wo wir hinwollen: modulare Systeme, die es erlauben, Teile
unabhängig voneinander weiterzuentwickeln. Aber wie kommen wir vom
aktuellen Stand aus dort hin? Wenn sich Tausende von falschen
Abhängigkeiten eingeschlichen haben? Und wir kontinuierlich Bugs fixen
und Features entwickeln müssen? Wir können die Entwicklung nicht für ein Jahr komplett unterbrechen um die kaputten Strukturen zu reparieren. In diesem Vortrag erzählen wir über unsere Erfahrungen bei der Weiterentwicklung eines > 5 Mio. LOC Monolithen an welchem ca. 60
Entwickler parallel arbeiten. Wir werden Wege aufzeigen um solch einen
"schwer navigierbaren Frachter" in eine bessere Zukunft zu steuern.
Der Vortrag wird nicht nur Methodik erläutern, sondern auch ganz konkret anhand der Open-Source-Library ArchUnit (https://www.archunit.org) Muster vorstellen, die man in einem derartigen Umfeld einsetzen kann.

Ein Umfeld der Art, dass jede Architekturregel, die man tatsächlich
prüft, hunderte oder tausende von Verletzungen aufweist, so dass man
diese unmöglich spontan reparieren kann. Wir werden sehen, wie
man solch einen Monolithen reparieren und langsam, aber stetig, hin zu
einem "Modulithen" mit sauberen Abhängigkeiten transformieren kann. Und das, ohne dabei die tägliche Entwicklung unterbrechen zu müssen oder versehentlich die bisher gewonnenen Erfolge im Zeitdruck des nächsten Releases zu zerstören.

Der Vortrag wird einige Live-Examples enthalten, welche kurz in ArchUnit
einführen, sich dann aber konkret mit detaillierten Patterns für die
Restauration von gewachsenen Systemen beschäftigen.

Transcript

1. Rescue the Mud-olith Rescue the Mud-olith Oder: Wie geht man mit Legacy-Software Oder: Wie geht man mit Legacy-Software richtig um? richtig um? & Nürnberg, 2019-09-25 Peter Gafert Daniel Götz
2.   Vorstellung Vorstellung
3. Peter Gafert Peter Gafert Principal Consultant @ TNG Technology Consul ng GmbH Start Mi e 2011 ursprünglich Diplom-Mathema ker begleitet im Alltag häufig Legacy-Projekte / Migra onen
4. Daniel Götz Daniel Götz Senior Consultant @ TNG Technology Consul ng GmbH Start Anfang 2015 eigentlich promovierter theore scher Teilchenphysiker Analyse und Arbeit an mehreren Legacy-Systemen fasziniert davon, dass Code zwangsläufig zu Legacy-Code wird
5.   Motivation Motivation   Shoppolith – ein generiertes Legacy- Shoppolith – ein generiertes Legacy- System System
6.   Disclaimer Disclaimer Mud-oliten restaurieren ist (sehr) schwer das System ist zu groß um es zu begreifen und zu verwoben um Auswirkungen abschätzen zu können wir können keine Silver-Bullet liefern, sondern nur eine Breitensicht mit verschiedenen Werkzeugen und Methodiken um solch ein Problem anzugehen!
7.   Ziel des Vortrags Ziel des Vortrags   Ausgangszustand: Ausgangszustand: Großes Legacy-System: Big Ball of Mud Feature-Entwicklung und Bugfixes werden zunehmend aufwändiger, teurer und langsamer   Fragen: Fragen: Wie analysiert man solch ein historisch gewachsenes System? Wie kommt man vom BBoM zu einem modularen System?   Tools: Tools: ArchUnit Elas c Stack/Kibana aim42 etc.
8.   Randbedingungen Randbedingungen Wir werden uns in diesem Vortrag rein auf freie Tools konzentrieren Alles was wir zeigen kann man direkt in seinem Projekt einsetzen Keine Garan e, dass man nicht mit kommerziellem Tool X alles viel komfortabler erreichen könnte 
9. Drei Schritte: Drei Schritte:   Analyse Analyse   Bewertung Bewertung   Umsetzung Umsetzung
10.   Analyse Analyse Zurechtfinden im System Feststellen des Ist-Zustands Daten sammeln: Wo besteht Handlungsbedarf?
11. Open Source Library ( ) Elegante Fluent-API zum definieren von Architekturregeln im Code auf Unit-Test-Ebene basierend auf Bytecodeanalyse (ASM) h ps:/ /www.archunit.org
13. Elastic Stack Elastic Stack Elas csearch (Suchindizes, REST-API) Kibana (Visualisierung) mi lerweile ganzes Universum h ps:/ /www.elas c.co/
14. Fachliche Struktur von Fachliche Struktur von   Shoppolith Shoppolith Klassischer, gewachsener Shop Subdomains als Top-Level-Packages abgebildet Visualisieren der Abhängigkeiten z.B. mi els ArchUnit
15.   Shoppolith: Teilweise Vereinfacht Shoppolith: Teilweise Vereinfacht Subdomains sind klar erkennbar Im "rich gen Leben" muss man o die fachlichen Subdomains zuerst iden fizieren Struktur passt i.A. weniger gut zu den Subdomains als bei Shoppolith Im ersten Schri müsste man für die Strukturanalyse ein Mapping vornehmen
16.   Live-Analyse: Live-Analyse:   Shoppolith Shoppolith
17. Fachliche Struktur von Fachliche Struktur von   Shoppolith Shoppolith   Ergebnis: Ergebnis:  viele Abhängigkeiten einige stark ausgeprägt, andere weniger  Shoppolith war wohl nicht immer ein Mudolith, sondern ha e so etwas wie eine Soll-Architektur?
18.   Database Strukturanalyse Database Strukturanalyse gleiches lässt sich auch auf DB-Ebene durchführen Tabellen nach Subdomains clustern Foreign Keys als Dependencies zeichnen
19.   Ticket-System (1/2) Ticket-System (1/2) Ticket-System =  Bug-Tracker Mapping: Tickets  Code-Basis Möglich, wenn Commits bspw. in der Commit-Message eindeu g Tickets referenzieren: BUG-145: fixed wrong mapping of order number; now the correct customer will be billed
20.   Ticket-System (2/2) Ticket-System (2/2) Was findet man damit heraus? Was findet man damit heraus? Wo treten (die meisten) Bugs auf? Welche Codestellen/Subdomains sind Bo lenecks? Vergleich mit allgemeiner Commit-Häufigkeit (siehe Domain- Diagramm): Was sind die kri schsten fachlichen Komponenten?
21.   User Feedback User Feedback Welche Workflows führen User überhaupt wirklich durch? Wie ist die User Experience? Wo sind Flaschenhälse? Falls man an den Enduser nicht herankommt: Support/Kundenservice!
22.   Development-Daten Development-Daten Welche Build-Schri e führen Entwickler durch? Welche der CI-Server? Wo sind Entwickler blockiert / verlieren Zeit? Tools wie Gradle Enterprise liefern hier großen Wert
23.   Database Locks Database Locks Blocking Report anlegen kon nuierlich Daten über Waits / Deadlocks tracken
24.   Usecases bewerten Usecases bewerten Mit welchen fachlichen Vorgängen wird das meiste Geld verdient? Was sind die Kernfachvorgänge? Wieviel Gewinn verliert man wenn Vorgang X für Y Minuten nicht funk oniert?
25.   Usecases in Elasticsearch Usecases in Elasticsearch
26.   Analyse – Fazit Analyse – Fazit   Wichtig: Daten über das System sammeln Wichtig: Daten über das System sammeln Sta sche Daten aus Codeanalyse Daten über Nutzung des Systems in Produk on   Daten in Zahlen oder Diagrammen belegen! Daten in Zahlen oder Diagrammen belegen!  Warum eigentlich?
27.   Bewertung Bewertung
28. Architecture Improvement Method Architecture Improvement Method Open Source Framework um systematisch Softwaresysteme und Open Source Framework um systematisch Softwaresysteme und deren Architektur zu verbessern deren Architektur zu verbessern Katalog vieler Ideen, die aus prak schen Erfahrungen und Erprobungen entstanden sind! Erdacht, erstellt und gepflegt von Gernot Starke Die folgenden Ideen stammen im Wesentlichen aus aim42! h ps:/ /www.aim42.org/ h ps:/ /aim42.github.io/ h ps:/ /github.com/aim42/aim42
29. Vorgehen Vorgehen Unterscheiden zwischen Unterscheiden zwischen   Problem und Problem und   Lösung Lösung Entwickler arbeiten lösungsorien ert und haben bei  Problemen meist direkt  Lösungen im Kopf Zunächst auf Zunächst auf   Probleme beschränken Probleme beschränken  Sammeln in einer "Issue-List" Dann Dann   Lösungsvorschläge erarbeiten und sammeln Lösungsvorschläge erarbeiten und sammeln Separat für jedes  Problem Dabei  out-of-the-box denken!
30. Kosten als Geldbeträge ausdrücken Kosten als Geldbeträge ausdrücken Probleme und Lösungen unabhängig voneinander in  Geldbeträgen schätzen! Wie schätzt man  Probleme als  Geldbeträge?
31. Beispiel: Memory Leaks Beispiel: Memory Leaks  Shoppolith muss wegen Memory-Leaks einmal am Tag neugestartet werden Wieviele Einnahmen en allen dadurch, dass  Shoppolith nicht erreichbar ist? Muss ein Sysadmin wegen des Neustarts mi en in der Nacht regelmäßig teure Nachtschichten einlegen? Falls ja, wieviel kosten diese Nachtschichten?
32. Beispiel: Schlechte Architektur Beispiel: Schlechte Architektur Einbau eines neuen Features dauert eine Woche sta einen Tag Anzahl Entwickler x 4 (unnö ge) Tage x  Tagessatz pro Entwickler
33. Unsicherheiten Unsicherheiten Was tun wenn eine Schätzung schwer fällt?  Intervalle angeben! Unsicherheit = größeres Intervall
34. Auch Auch   Lösungen entsprechend Lösungen entsprechend schätzen! schätzen!
35. Bewerten Bewerten   Priorisieren der Priorisieren der   Probleme Probleme Für jedes Problem sind die (geschätzten)  Kosten bekannt  einbeziehen!   Lösungsvorschläge der Probleme betrachten Lösungsvorschläge der Probleme betrachten Gibt es Quick-Wins? (güns g und schnell erledigt) Ren ert sich eine Lösung wirklich? Nur verbessern, wenn die  Kosten der Lösung nicht die des Problems übersteigen!
36. Argumentieren (1/2) Argumentieren (1/2) Zur Problembehebung benötigt man Zur Problembehebung benötigt man   Budget! Budget! Budget erhält man meist vom Budget erhält man meist vom   Management, Management, nicht nicht von von   Entwicklern Entwicklern  Management versteht meist nicht die technischen Details von Architektur- und So wareproblemen Ist auch nicht deren Aufgabe! Dafür verstehen sie  Geld!
37. Argumentieren (2/2) Argumentieren (2/2) Was also tun? Was also tun?  Priorisierte Issue-List präsen eren, mitsamt aller  Zahlen Schätzungen und deren Grundlagen explizit erläutern Scha Diskussionsgrundlage! Schätzung kann mit Stakeholdern ggf. noch präzisiert werden
38. Kosten-Nutzen Kosten-Nutzen   Visualisierung in Kibana Visualisierung in Kibana
39.   Umsetzung Umsetzung   Kontinuierlicher Verbesserungsprozess Kontinuierlicher Verbesserungsprozess   Ebenen Ebenen   Technisch Technisch   Organisatorisch Organisatorisch
40.   Kontinuierlich verbessern Kontinuierlich verbessern   Verbesserungsprozess muss in Organisation integriert werden! Verbesserungsprozess muss in Organisation integriert werden!   Darauf achten, dass kontinuierlich Business Value entsteht Darauf achten, dass kontinuierlich Business Value entsteht In der Regel muss die Feature-Entwicklung ste g weiterlaufen   Einplanen in laufende Feature-Entwicklung Einplanen in laufende Feature-Entwicklung z.B. Aufräumen wenn man eh daran vorbeikommt gezielt Subdomains entkoppeln Teil des Budgets für regelmäßige Migra on Richtung Soll- Architektur aufwenden Beispiel: Pro Sprint 10 Architekturverletzungen aufräumen
41.   Technische Verbesserungen Technische Verbesserungen   Strukturmigration mit ArchUnit Strukturmigration mit ArchUnit
42.   Fortschritt kontinuierlich bewerten Fortschritt kontinuierlich bewerten   z.B. Abbau von Frozen Rules z.B. Abbau von Frozen Rules
43.   Organisatorische Verbesserungen Organisatorische Verbesserungen   Beispiel: Communities of Practice Beispiel: Communities of Practice Team aus "normalen" Entwicklern sollten sich aus verschiedenen Teams zusammensetzen  mehr Überblick über das Gesamtsystem Regelmäßiges Budget, z.B. 2 Personentage pro Person pro zweiwöchigem Sprint kann gemäß Priorität an Modularisierung u.ä. arbeiten
44.   Organisatorische Verbesserungen Organisatorische Verbesserungen   Kontinuierliches Feedback Kontinuierliches Feedback Architekturtests im CI-Build mitlaufen lassen Eine Person (Architekt, ro erendes Mitglied der Community of Prac ce) sollte einen Überblick über Architekturtests haben und Entwicklern beratend zur Seite stehen Architektur lebt und sollte sich mit der So ware weiterentwickeln!
45.   Organisatorische Verbesserungen Organisatorische Verbesserungen   Conway's Law beachten Conway's Law beachten organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.
46.   Organisatorische Verbesserungen Organisatorische Verbesserungen   Conway's Law: Negativbeispiel Conway's Law: Negativbeispiel Entwicklungsbereich bestehend aus 50 Entwicklern Gruppiert in Scrum-Teams mit je 4 – 8 Mitgliedern Aber: Eine Komponente wird von einer einzelnen Person entwickelt, die in einem benachbarten Gebäude sitzt Ergebnis Ergebnis Komponente des einzelnen Entwicklers weicht stark vom Rest ab, befolgt viele Architekturregeln nicht Weitreichende Konsequenzen: Architektur, Build, Deployment, etc.
47.   Fazit Fazit Analyse Analyse Zahlen sammeln, Analysen mit Daten belegen Sta sch (Codeanalyse) und dynamisch (Produk onsdaten) Bewerten Bewerten Probleme und Lösungen unabhängig in Geld schätzen, Intervalle drücken Unsicherheiten aus Priorisieren und mit Management disku eren Umsetzung Umsetzung Kon nuierlich im laufenden Alltag verbessern Technische Ebene: z.B. Architekturtests mit ArchUnit im CI Organisatorische Ebene: z.B. mit Communi es of Prac ce