Die Glaskugel hat ausgedient, wir machen Software Analytics

Die Folien zu meinem Vortrag "Die Glaskugel hat ausgedient, wir machen Software Analytics" auf dem Dev Day 2019 in Dresden

2. Wir sind ein Dresdner IT-Beratungsunternehmen, gegründet im Jahre 2008. Unsere Schwerpunkte liegen in den Bereichen Softwareentwicklung, Architektur-beratung und Training. Gemeinsam mit unseren Kunden entwerfen und implementieren wir fachlich passgenaue Lösungen auf Basis der Java-Technologien. buschmais GbR Inhaber Torsten Busch, Frank Schwarz, Dirk Mahler und Tobias Israel Adresse Leipziger Str. 93 01127 Dresden info@buschmais.com www.buschmais.de
4.  Eine Medaille – Zwei Seiten ◼ Hohe Komplexität, aufwendig zu pflegen ◼ Bewährtes Rückgrat betrieblicher Abläufe
5.  Geschäftliche Rahmenbedingungen ändern sich kontinuierlich ◼ Mitbewerber, Geschäftsmodelle, …  Kann das System folgen?
6.  Grundlegende qualitative Eigenschaften ◼ Skalierbarkeit, Performanz, Sicherheit, Wartbarkeit, ...  Manifestierung in Code und Prozessen ◼ Technologien, Strukturen, Muster, Test-Strategie, ...  Änderungen? Aufwändig und riskant!
7.  Notwendigkeit der (kontinuierlichen) Anpassung  Begrenztes und unsicheres Wissen ◼ Risiko für Planung, Implementierung und Refaktorisierung ◼ Kann zu Angst vor Änderungen führen  Kontinuierliche Verschlechterung der Situation als Resultat
8. Dokumentierte Architektur <> Gefühlte Architektur <> Reale Architektur
9. Neu-Implementierung Zerlegung in Microservices Restruktukrierung des Mononlithen
11.  Open-Source e-Commerce System „shopizer“ ◼ Warenkorb ◼ Katalog ◼ Suche ◼ Bestellung ◼ Shop-Administration  Fork: https://github.com/buschmais/shopizer
13.  Szenario: Katalog sorgt für hohe Systemlast zu Spitzenzeiten ◼ Gesamtes System muss skaliert werden Allokation theoretisch unnötiger Ressourcen ◼ Wettkampf um verfügbare Ressourcen Behinderung anderer Funktionalitäten ◼ Lastbedingte Ausfälle betreffen gesamtes System
14.  Lösung ◼ Herauslösen des Katalogs  Problem(e) ◼ Wieviel (und welcher) Code ist betroffen? ◼ Welche Schnittstellen existieren bzw. müssen geschaffen werden? ◼ Welche Daten müssen repliziert werden? ◼ Welches Vorgehen ist das richtige? ◼ …
15. https://spongebob.fandom.com/wiki/List_of_time_cards
16. https://imgflip.com/memegenerator/Skeptical-Baby
17. https://builder.cheezburger.com/Builder/RenderPreview/65f84df1-bae0-4cb8-9602-5205a7caf98d
19.  Data Analytics für Software Systeme ◼ Extraktion und Zusammenführung von Informationen aus Source Code Statischen und dynamischen Eigenschaften Entwicklungshistorien ◼ Schlussfolgern von neuen Informationen zum Aufbau von Wissen
20.  Dokumentation von Erkenntnissen ◼ Unterstützung von Planung und Refaktorisierung ◼ Referenz für (neue) Entwickler ◼ Kommunikationsgrundlage für Entwickler und Entscheider
21. https://www.kino.de/serie/hoer-mal-wer-da-haemmert-1999/news/hoer-mal-wer-da-haemmert-tim-allen-bringt-neue-folgen-ins-gespraech/
22.  Tooling ◼ jQAssistant Scan der Applikation und Abbildung in Graphdatenbank ◼ Neo4j Persistierung und Abfrage von Informationen ◼ Jupyter Notebook Dokumentation der Analyseschritte und Ergebnisse
24. service :Package Product Service :CONTAINS :Type:Java Match (:Package{name: ‘‘service“})-[:CONTAINS]->(type:Type:Java) RETURN type Node Node Relationship LABEL PROPERTY LABEL VAR
26.  Schier unendliche Menge an möglichen Fragestellungen ◼ Abhängig von Ziel und Qualität sowie Quantität der vorliegenden Daten https://makeameme.org/meme/possibilities-are-endless-59fa8f
27.  Wie ist die Anwendung technisch strukturiert?  Wie ist die Anwendung fachlich strukturiert?  Wie hängen die einzelnen Fachlichkeiten zusammen?  Welcher Code wird am häufigsten geändert?
28. Vorbereitung der Anwendung
29. <plugin> <groupId>com.buschmais.jqassistant</groupId> <artifactId>jqassistant-maven-plugin</artifactId> <version>1.6.0</version> <executions><execution> <goals> <goal>scan</goal> <goal>analyze</goal> </goals> </execution></executions> <.../> </plugin>
30. mvn clean install jqassistant:server → localhost:7474
31. https://www.memecreator.org/meme/lets-get-to-work81
32. Wie ist die Anwendung technisch strukturiert?
33.  Technischen Architekturelemente (z.B. Layer)  Abhängigkeiten zwischen technischen Architekturelementen  Umsetzung der technischen Architektur im Code  Aussagekraft der Ergebnisse
34.  Live-Demo ◼ Abhängigkeit zwischen maven- Modulen ◼ Zuordnung von Artefakten zu Layern (Presentation, Domain, Data Layer) <<maven>> sm-shop <<maven>> sm-core <<maven>> sm-core-modules <<maven>> sm-core-model
35.  Learning Outcomes ◼ die Anwendung folgt einer klassischen 3-Schichten-Architektur ◼ die Richtungen der Abhängigkeiten wurden korrekt implementiert ◼ es konnten 100% des Codes zu technischen Schichten zugeordnet werden
36. Wie ist die Anwendung fachlich strukturiert?
37.  Implementierte Subdomänen  Fachliche Architekturelemente (z.B. Module)  Umsetzung der fachlichen Architektur im Code  Aussagekraft der Ergebnisse
38.  Wo ist eine gute fachliche Strukturierung am ehesten zu erwarten? ◼ Spring-Services ◼ Paketnamen (service, konkrete Fachlichkeiten wenn bekannt) ◼ Explorieren der Anwendung in IDE
39.  Live-Demo ◼ Fachliche Packages (Subdomänen) ◼ Zuordnung von Klassen zu Subdomänen anhand Package- Namen Classes catalog common content customer merchant order payments reference search shipping shoppingcart system tax user
40.  Learning Outcomes ◼ die Geschäftslogik teilt sich in 13 fachlich motivierte Subdomänen ◼ es konnten 69% aller Klassen zu Fachlichkeiten zugeordnet werden ◼ der Katalog ist mit 140 Klassen die größte Subdomäne
41. Wie hängen die Fachlichkeiten zusammen?
42.  Existierende Abhängigkeiten zwischen Subdomänen ◼ Erlaubte und Unerwartete/Verbotene Abhängigkeiten ◼ Anzahl an Abhängigkeiten ◼ Hot Spots
43.  Live-Demo ◼ Visualisierung von Abhängigkeiten ◼ Analyse von Ein- und Ausgehenden Abhängigkeiten Kopplungsgrad Hot-Spot Klassen
44.  Learning Outcomes ◼ die Suche gehört exklusiv zum Katalog ◼ die Kommunikation zwischen Katalog und Kern ist schwach durch Interfaces entkoppelt
45.  Learning Outcomes ◼ der Katalog definiert 169 Abhängigkeiten zum Kern auf Klassenebene, 27 davon gegen Interfaces Hot Spots sind MerchantStore und Language
46.  Learning Outcomes ◼ der Kern definiert 162 Abhängigkeiten zum Katalog auf Klassenebene, 5 davon gegen Interfaces Hot Spot ist Product
47. War‘s das?
48.  Software Analytics bietet nahezu unbegrenzte Möglichkeiten  Analyse abhängig von ◼ betrachtetem Softwaresystem ◼ vorhandenen Daten ◼ Fragestellungen
49.  Weitere Analysen ◼ Ownership von Subdomänen, Fix-Commits ◼ Testcoverage, Teststruktur ◼ Defektdichten ◼ Toter Code ◼ Analyse von Laufzeitdaten ◼ ...
50.  Bewertung der Ergebnisse notwendig ◼ Tiefergehende Analysen für kritische Stellen ◼ Relevanz und Priorisierung ◼ Planung von Refaktorisierung und Implementierung ◼ Management von Technical Debt
51.  2-Tages Workshop  Strukturiert vom Monolithen zum Modulithen und Microservices  Interaktiv am Beispiel eines e- Commerce Shopsystems  Nächster Termin: November 2019 https://www.buschmais.de/seminare/lasst-uns-einen-monolithen-zerlegen/
53. Fragen bitte an: Stephan Pirnbaum buschmais GbR Inhaber Torsten Busch, Frank Schwarz, Dirk Mahler und Tobias Israel stephan.pirnbaum@buschmais.com http://buschmais.de/ Dresden, 21.05.2019