Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Die Glaskugel hat ausgedient, wir machen Softwa...

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

Stephan Pirnbaum

May 21, 2019
Tweet

More Decks by Stephan Pirnbaum

Other Decks in Programming

Transcript

  1. 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 [email protected] www.buschmais.de
  2.  Eine Medaille – Zwei Seiten ◼ Hohe Komplexität, aufwendig

    zu pflegen ◼ Bewährtes Rückgrat betrieblicher Abläufe
  3.  Grundlegende qualitative Eigenschaften ◼ Skalierbarkeit, Performanz, Sicherheit, Wartbarkeit, ...

     Manifestierung in Code und Prozessen ◼ Technologien, Strukturen, Muster, Test-Strategie, ...  Änderungen? Aufwändig und riskant!
  4.  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
  5.  Open-Source e-Commerce System „shopizer“ ◼ Warenkorb ◼ Katalog ◼

    Suche ◼ Bestellung ◼ Shop-Administration  Fork: https://github.com/buschmais/shopizer
  6.  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
  7.  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? ◼ …
  8.  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
  9.  Dokumentation von Erkenntnissen ◼ Unterstützung von Planung und Refaktorisierung

    ◼ Referenz für (neue) Entwickler ◼ Kommunikationsgrundlage für Entwickler und Entscheider
  10.  Tooling ◼ jQAssistant Scan der Applikation und Abbildung in

    Graphdatenbank ◼ Neo4j Persistierung und Abfrage von Informationen ◼ Jupyter Notebook Dokumentation der Analyseschritte und Ergebnisse
  11.  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
  12.  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?
  13.  Technischen Architekturelemente (z.B. Layer)  Abhängigkeiten zwischen technischen Architekturelementen

     Umsetzung der technischen Architektur im Code  Aussagekraft der Ergebnisse
  14.  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
  15.  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
  16.  Implementierte Subdomänen  Fachliche Architekturelemente (z.B. Module)  Umsetzung

    der fachlichen Architektur im Code  Aussagekraft der Ergebnisse
  17.  Wo ist eine gute fachliche Strukturierung am ehesten zu

    erwarten? ◼ Spring-Services ◼ Paketnamen (service, konkrete Fachlichkeiten wenn bekannt) ◼ Explorieren der Anwendung in IDE
  18.  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
  19.  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
  20.  Live-Demo ◼ Visualisierung von Abhängigkeiten ◼ Analyse von Ein-

    und Ausgehenden Abhängigkeiten Kopplungsgrad Hot-Spot Klassen
  21.  Learning Outcomes ◼ die Suche gehört exklusiv zum Katalog

    ◼ die Kommunikation zwischen Katalog und Kern ist schwach durch Interfaces entkoppelt
  22.  Learning Outcomes ◼ der Katalog definiert 169 Abhängigkeiten zum

    Kern auf Klassenebene, 27 davon gegen Interfaces Hot Spots sind MerchantStore und Language
  23.  Learning Outcomes ◼ der Kern definiert 162 Abhängigkeiten zum

    Katalog auf Klassenebene, 5 davon gegen Interfaces Hot Spot ist Product
  24.  Software Analytics bietet nahezu unbegrenzte Möglichkeiten  Analyse abhängig

    von ◼ betrachtetem Softwaresystem ◼ vorhandenen Daten ◼ Fragestellungen
  25.  Weitere Analysen ◼ Ownership von Subdomänen, Fix-Commits ◼ Testcoverage,

    Teststruktur ◼ Defektdichten ◼ Toter Code ◼ Analyse von Laufzeitdaten ◼ ...
  26.  Bewertung der Ergebnisse notwendig ◼ Tiefergehende Analysen für kritische

    Stellen ◼ Relevanz und Priorisierung ◼ Planung von Refaktorisierung und Implementierung ◼ Management von Technical Debt
  27.  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/
  28. Fragen bitte an: Stephan Pirnbaum buschmais GbR Inhaber Torsten Busch,

    Frank Schwarz, Dirk Mahler und Tobias Israel [email protected] http://buschmais.de/ Dresden, 21.05.2019