Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

Gewachsene Systeme kontinuierlich und agil verb...

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.

Markus Harrer

March 11, 2019
Tweet

More Decks by Markus Harrer

Other Decks in Technology

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. 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
  4. 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
  5. Die Realität In der Softwareentwicklung sind heutzutage Wartung Capers Jones

    : The Economics of Software Maintenance in the Twenty First Century
  6. 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
  7. aim42 One-Slider Architecture Improvement Method aim42 liefert… …konkrete Probleme („Schmerzen“)

    …Prioritäten („Schmerzkosten“) …Vorschläge für Abhilfen https://aim42.github.io/
  8. 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/
  9. 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
  10. 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
  11. • 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
  12. „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
  13. 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
  14. 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? →
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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!
  20. 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
  21. 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
  22. Linux Kernel • Einige Kopfmonopole • Hohe Entwicklerstreuung • Viel

    Abstimmungsarbeit Beispiel Wissensverteilung mit Daten aus dem Git-Repository
  23. 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
  24. 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?
  25. Analyse von Tests • Finden bestehende Tests relevante Fehler? •

    Gibt es (automatisierte) Tests: • Unit-, Integrationstests • Akzeptanztests • Sonstige ... • Infrastrukturtests • Chaos Monkey... • Laufen die Tests auch?
  26. Prozessanalyse • Anforderungsprozesse • erheben, klären, managen • Entwicklungs- /Entwurfsprozesse

    • Architektur, Implementierung, Dokumentation • Betrieb • Deployment, Rollout, Administration, Monitoring • Management • Team- und Taskmanagement, Risikomanagement
  27. 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
  28. 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
  29. 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!
  30. 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
  31. 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
  32. 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
  33. 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
  34. 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
  35. 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/
  36. 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
  37. 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
  38. Live-Demo System-Performance • vmstat • Open Zippy Analysis Platform For

    Data In Software • Jupyter Notebook • Python • pandas • matplotlib
  39. 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
  40. 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
  41. 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
  42. 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
  43. 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
  44. 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…
  45. 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
  46. 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)
  47. 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
  48. 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
  49. Improve Cohesion 1 1. Identifiziere zusammengehörige Fragmente 2 3 «category»

    Restructure 2. Isoliere Fragmente 3. Verbessere Fragmente
  50. Dev Build Source Code Graph Byte Code jQAssistant Neo4j Graph-DB

    Isolate Core Domain & ImproveCohesion Beispiel mit jQAssistant und Neo4j
  51. :Class :Method :Field findings 2 changes 5 :Entity usage 100%

    name birthDate https://github.com/buschmais/spring-petclinic Die Softwarelandschaft als Graph Business Subdomain
  52. 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
  53. Zusammenfassung Legacy Code ist und bleibt ein spannendes Thema! aim42

    unterstützt bei der anspruchsvollen Arbeit!
  54. 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 [email protected] @feststelltaste Gernot Starke [email protected] @gernotstarke
  55. 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
  56. 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
  57. 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