ddc-Cologne: Software verbessern mit aim42

Software verbessern, aber richtig: Methodisches Vorgehen bei Modernisierung, Transformation oder Optimierung von Software.

Transcript

1. Software verbessern, aber richtig Dr. Gernot Starke
2. Disclaimer (aka: bad news): The following talk is free of Microservices and Lambdas
3. Dr. Gernot Starke innoQ Fellow Software architectures Design, Development Evolution, Transformation, Dokumentation Reviews, Audits Analyse und Optimierung von Entwicklungsprozessen +49 177 – 728 2570 gernot.starke@innoq.com http://arc42.de http://aim42.org
5. Velocity & Bugs in normalem System 17 0 Q1-11 Q2-11 Q3-11 Q4-11 Q1-12 Q2-12 Q3-12 Q4-12 Q1-13 Q2-13 Q3-13 Q4-13 Q1-14 Q2-14 Q3-14 Q4-14 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 new features or fixes delivered production bugs
6. Reale Welt: Geldschulden Schulden nur auf Antrag. Rückzahlung a priori geklärt. Obergrenze für Verschuldung. Klare Regeln für Risikobewertung. Schulden explizit in Bilanz. Software: technische Schulden Schulden zufällig aufgenommen. Rückzahlung völlig offen. Beliebige Schuldenhöhe. Kaum Kriterien für Risikobewertung. Schulden implizit und oft unbekannt. Hilfe, Schulden!
7. Meine Versprechen („Agenda“) 1. Methodisches Verbessern 2. Schlimme Probleme finden 3. Management überzeugen 4. Mittel- und langfristige Verbesserungen 5. Mit Tagesgeschäft vereinbaren
8. Der Normalfall ... Management: Zu teuer. Zu viele Fehler. Zu hohe Aufwände. Zu lange Time-to-Market.
9. Der Normalfall ... Management: Zu teuer. Zu viele Fehler. Zu hohe Aufwände. Zu lange Time-to-Market. Techniker: Zu hohe technische Schuld. Zu wenig Verbesserung. Technologie zu schlecht. Zu wenig Innovation. Zu wenig Budget. Zu wenig Zeit.
10. Meine Versprechen („Agenda“) 1. Methodisches Verbessern 2. Schlimme Probleme finden 3. Management überzeugen 4. Mittel- und langfristige Verbesserungen 5. Mit Tagesgeschäft vereinbaren analyze evaluate improve collect
11. Issue (Problem, Risk) Improvement Cost Cause cost of improvement improvements resolve cause (root) causes of issues cost of issue solve issue with improvement(s) improvement solves issue(s)
12. Issue Cost Improvement Cost > Nur verbessern, wenn Problem schlimmer ist als Lösung teuer
13. Iterativ verbessern! analyze evaluate improve collect
14. Improvement Backlog Issue List (problems, risks) analyze evaluate improve collect…
15. Meine Versprechen („Agenda“) 1. Methodisches Verbessern 2. Schlimme Probleme finden 3. Management überzeugen 4. Mittel- und langfristige Verbesserungen 5. Mit Tagesgeschäft vereinbaren Iteration 1 Breitensuche in Iterationen
16. analyze
17. Probleme in kompliziertem System suchen (0) • Geschmack, • Preis, • Aussehen, • Lage (des Restaurants) https://flic.kr/p/6xuSMU
18. Probleme in kompliziertem System suchen (1) • Geschmack, • Temperatur, • Aussehen, • Konsistenz, • Beliebtheit
19. Probleme in kompliziertem System suchen (2) Anteile an Kohlenhydrat, Protein, Fett, Vitamin Nachweis von Drogen, Schad- oder Giftstoffen, oder Radioaktivität https://flic.kr/p/bDGDMY
20. Probleme in kompliziertem System suchen (3) Transport- und Lagerung https://flic.kr/p/pnVsxu
21. Probleme in kompliziertem System suchen (4) Einkauf, Herstellung, Verpackung, Vertrieb https://flic.kr/p/dZfxi5
22. Probleme in komplizierten Systemen • Probleme einzelner Bestandteile • Probleme bei Abhängigkeiten • Probleme mit übergreifenden Regeln • Probleme mit Beteiligten • Probleme mit Prozessen • ....
23. Legende System Qualities Context & external Interfaces Existing Issues Data Documentation Runtime Behavior Requirements Code History Code Structure Development Process Infrastructure User Stakeholder hängt zusammen Security
24. Iteration 1 Breitensuche in Iterationen Stakeholder Code Kontext Qualität Daten Prozesse Iteration 2
25. Die Mikroskop-Falle Wenn Sie NUR im Code suchen, werden Sie NUR DORT Probleme finden... im Code suchen ist richtig und wichtig, aber NUR dort suchen ist fatal!
26. Die Relativitäts-Falle Des Einen Problem ist des Anderen Freund Siehe: Planning:Expect-Denial
27. Stakeholder ... wichtige Personen oder Organisationen, die: • Interesse am System haben, • von System oder Architektur betroffen sind: – damit arbeiten – daran arbeiten – davon profitieren – darunter leiden – es • betreiben • verwalten • regulieren • bezahlen ?
28. Stakeholder kennen viele Probleme ?
29. Stakeholder-Map Backlog System (Code) System (Laufzeit) User System operator IT Budget System Budget Support Issues High-Level Manager Business Manager Entwickler/ Architekten Test/QS Product Owner Visualisieren Sie IHRE Stakeholder & Artefakte
30. Für IHR System: • Erstellen Sie eine (informelle) Stakeholder- Map • Wer arbeitet • woran • mit wem, • informiert/steuert wen • Benennen Sie für 3-5 relevante Stakeholder: Person /Rolle hat welche Aufgabe(n) hat welche Ziele oder Intentionen? kann „wie“ bei Analyse mitwirken?
31. Übersicht: Systemanalyse • Qualitative Analyse (Risiken) • Quantitative Analyse („Vermessung“) • Code • Laufzeit • Datenanalyse • Kontextanalyse
32. Qualitative Analyse •Welche Qualitätsziele sind „gefährdet“? •Soll-Ist Vergleich: • Soll: konkrete Q-Ziele • Ist: Lösungsansätze • Code, Konzepte, Entscheidungen... Genauer: Vergleich von Anforderungen mit Lösung oder Lösungsansätzen
33. Qualitätsanforderungen präzisieren...
34. Qualitätsziele Q-Ziel Bedeutung / Szenarien Flexibilität • Neues csv- Importformat in <4h konfigurierbar Last / Performance • 250.000 eingelieferte Fotos innerhalb von 24h prozessiert Sicherheit • Mandant kann niemals Zugriff auf Daten anderer Mandanten erhalten Architektur-/Lösungsansatz • Konfigurationssprache für CSV-Parser (Import), auf Basis ANTLR • Syntaxgesteuerter Editor für die Sprache • Bilder als Dateien speichern, Links in DB • Lasttests im DailyBuild • Generator für (Massen- )Testdaten • Mandantenspezifische Daten grundsätzlich in (eigener) VM • Datenlieferungen grundsätzlich in mandantenspezifische Verzeichnisse (ftp-Server) • Unix-Kennungen spezifisch für Mandanten Lösungsansätze Risiken?
35. Sammeln Sie „Issues“ bezüglich relevanter Qualitätsmerkmale. • Time-to-Market • Performance • Sicherheit • Robustheit/ Stabilität • Flexibilität (zur Laufzeit) • Änderbarkeit • Komplexität • Betreibbarkeit • ...
36. Quantitative Bewertung („Vermessung“) • Codemetriken • Laufzeitmetriken • Zeit- und Ressourcenverbrauch • Organisatorische Metriken • Fehler / Baustein • Änderungsaufwand / Baustein • Dauer von x / Baustein (x=Test, Dev...)
37. Statische Codeanalyse • Größe • Kopplung • Komplexität • Duplizierter Code • Verletzung von Idiomen (Style-Checking) • Kohäsion (inhaltlicher Zusammenhang) • Konsistenz (identische Probleme ähnlich gelöst)
38. Beispiel (1) Anmerkung: je höher desto schlechter Fix me? Komplexität: 2 Kopplung: 10 Komplexität: 10 Kopplung: 30 Komplexität: 9 Kopplung: 35 Komplexität: 7 Kopplung: 20
39. Beispiel (2) Komplexität: 2 Kopplung: 10 DTFB: 0.5 Bugs: 200 Komplexität: 10 Kopplung: 30 DTFB: 2 Bugs: 20 Komplexität: 9 Kopplung: 35 DTFB: 3 Bugs: 2 Komplexität: 7 Kopplung: 20 DTFB: 8 Bugs: 15 Fix me DTFB: Days-to-Fix-Bug
40. Korrelierte Codeanalyse Abgleich unterschiedlicher Beobachtungen/Messungen Beispiele: • Fehler pro Komponente / Subsystem • Benötigte Zeit pro Bugfix pro Komponente • Benötigter Aufwand pro Feature pro Komponente
41. Korrelierte Codeanalyse (2)
42. • Analyse von Benutzerverhalten • Analyse fachlicher Abläufe • Wo und womit verbringen Benutzer Zeit? • Welche Abläufe dauern ungebührlich lange? • Korrelieren fachliche Schwierigkeit + reale Dauer? Laufzeitanalyse • Profiling Analyse von zur Laufzeit erzeugten • Daten • Nachrichten, Events Im Hinblick auf: Anzahl, Größe, Art
43. 1. Geben Sie Beispiele für Metriken, die als Indikatoren fungieren können. • Mit passablem Aufwand messbar • Indikator für was? 2. Erstellen Sie ein „Metrik-Dashboard“: Welche Metriken würden Sie erheben? • Codemetriken • Laufzeitmetriken • Test-Metriken • Business-Metriken • Aufwandsmetriken • Prozess-Metriken • ....
44. Beispiel: Saubere Schichtung... GUI Application Domain Infrastructure
45. Beispiel: Saubere Schichtung, aber... „Clean“ Code XML Configuration DB Legend: COTS Code Table-1 Table-2 Table-3 Table-4 Database Relational Data
46. Datenanalyse 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?
47. Strukturanalyse (Architekturanalyse) Schlechte Modularisierung? (Zu) hohe Kopplung? Ungünstige Schnittstellen? Schlechte Kohäsion? Inhomogen? Sales Frontend Cash Management Client Personalization Client Data / Contract User Management Inventory & Order Vouchers Rebate and Reduction Cards Sales & Contracts Archive External Partners Sales Offices & Outlets Price Management Data Warehouse Marketing & Sales Campaigns Campaigns Pricing Engine Sales Backend Optical Archive Post-Sales Optimization Security Extensions Legend: Java PHP Pyth on C/C+ + Hask ell Cob ol PL/ SQL Schlechter Code?
48. Sammeln Sie „Issues“ bezüglich: •Architektur + Modularisierung • Kohäsion • Homogenität •Schlechtem Code •Schlechter Technologie •Schnittstellen •Daten oder •Laufzeit....
49. git log --since="90 days ago" --pretty=format:"" --name-only | \ grep "[^\s]" | \ sort | uniq -c | \ sort -nr | head -10 Code („gist“): https://goo.gl/kzTgFa
50. und jetzt haben Sie... • Liste von Problemen (issue list) • Liste von Ideen für Verbesserungen (improvement backlog) Issue List (problems, risks) Improvement Backlog
51. evaluate
52. These: Wir schätzen meist nur „Aufwände“
53. Tipp: Schätzen Sie... Kosten der Problem Lösungs- aufwände Geschäfts- wert
54. Schätzen in Intervallen • schätzen Sie Intervalle, statt einzelner (exakter) Werte
55. Schätzen: Die Grundbegriffe... Begriff Bedeutung Subject Schätzgegenstand – was schätzen wir? Unit Schätzgröße, Einheit: Geld, Zeit, Aufwand, Anzahl (wovon) Parameter von welchen Größen/Faktoren ist das Ergebnis abhängig? Assumptions Annahmen, meist über einzelne Parameter Observation Beobachtung oder Messung einzelner Parameter Probability Mit welcher Wahrscheinlichkeit / Zuversicht gelten welche dieser Zahlen Estimate Assumption Unit (Measure) Parameter Observation Probability based upon how certain? can observe or measure Interval time, money, etc Subject what do we estimate? tackle uncertainty by based upon
56. Zählen, Rechnen, Expertenmeinungen 1. Zählen Sie, wann immer möglich 2. Berechnen Sie, wenn Sie nicht zählen können 3. Expertenmeinungen nur als letztes Mittel
57. Schätzen: Die Grundbegriffe... Estimate Assumption Unit (Measure) (Cost) Factor (Parameter) Observation Probability based upon how certain? can observe or measure Interval time, money, etc Subject what do we estimate? tackle uncertainty by based upon determines size influence „size“
58. Wie teuer ist es... dass der Build-Prozess jedes Mal >15 Minuten dauert? • Von commit bis vollständiges Deployment auf App-/Webserver
59. Build-Prozess (1)... Einflussgrößen („Parameter“) klären: • Wie viele Entwickler sind betroffen? • Können Betroffene in der Zwischenzeit alternative Aufgaben lösen? Doku schreiben? • Wie häufig wird Build durchgeführt?
60. Build-Prozess (2a)... In real-life: • >30 Entwickler • Zur Zeit 3-5 x täglich 30Pers * 4 * 15min => 30h Overhead täglich
61. Build-Prozess (2b)... Weitere Konsequenz: • Entwickler bauen seltener, • dadurch werden Fehler später gefunden, • Bugfix-Aufwände steigen • Von 3h/Bug auf 3.5h/Bug • Bei 15 Bugs/Tag 15Bugs * 30min => 7,5h Overhead täglich
62. Build-Prozess (2c)... „Problemkosten“: Gesamt 37.5h / Tag Annahme: Personalkosten 50-100€/h Summe: [3750€/T , 1875€/T] 15Bugs * 30min => 7,5h Overhead täglich 30Pers * 4 * 15min => 30h Overhead täglich
63. Build-Prozess (3)... Lösungsoptionen: • Seltener bauen (-> Fehlerkosten steigen) • Schnellere Hardware • Hot-Deployment/zero turnaround (JRebel) • Lizenzkosten 475$/dev -> ~14000€ • Deploymentmodell ändern • .... https://zeroturnaround.com/software/jrebel/features/
64. Beispiel (3) • Kontext: übertrieben heterogenes System • C, C++, Cobol, Java, Php, Scala, Python, Haskell • Windows, Linux, Mainframe • Ziele: • Beschleunigung „time-to-market“ • Verbesserung der Verfügbarkeit
65. Beispiel (3): Annahmen • Heterogenität betrifft alle Phasen der Entwicklung (Anforderungen bis Betrieb) • Mittlerer Aufwand pro Phase ist bekannt http://courses.cs.vt.edu/~csonline/SE/Lessons/LifeCycle/
66. Beispiel (3): Ergebnis
67. Meine Versprechen („Agenda“) 1. Methodisches Verbessern 2. Schlimme Probleme finden 3. Management überzeugen 4. Mittel- und langfristige Verbesserungen 5. Mit Tagesgeschäft vereinbaren Issue (Problem, Risk) Improvement Cost cost of improvement cost of issue solve issue with improvement(s)
68. Für (1-2) Ihrer Issues: •Finden Sie (Kosten-)Faktoren • Was beeinflusst deren „Schlimmheit“ (Kosten) •Treffen Sie Annahmen... •Schätzen Sie die Kosten dieser Issues
69. «category» Improve Processes «category» Improve Technical Infrastructure «category» Improve Analysability & Evaluability «category» Improve Architecture & Code Structure
70. Introduce Interfaces Untangle Code Remove Nested Control Structures Deprecate Obsolete Parts Improve Responsibility Improve Code Layout Move Behavior Close To Data Split Up Oversized Parts Handle If-Else Chains Interface Segregation Anticorruption Layer Hide Unmaintainable Code Extract Reusable Component Integrate Reusable Component Remove Unused Parts Eliminate Navigation Code Toggle Feature Isolate Parts (Modularize) Break Dependencies Event Interception Asset Capture Gateway Handle Too Many «category» Restructure Code «category» Improve Processes «category» Improve Technical Infrastructure «category» Improve Analysability & Evaluability Improve Engineering Improve Delivery Improve Operations Improve Flow Improve Governance Schedule Work Enable Team Improve Hardware Improve Supporting Software Automate Release Improve Test Infrastructure Improve Logging Improve Test Automation Measure «category» Improve Architecture & Code Structure Improve Modularity Improve Concepts & Consistency Extract Domain Model «category» Restructure Code Introduce better Technology Improve Use of Technology «category» Prepare Change Improve Hierarchy
71. «category» Long-Term Improvement Approach Strangulate Bad Parts Big Bang (Cold Turkey) Frontend Switch Keep Data, Toss Code Managed Evolution Change Via Split Data Migration Branch by Abstraction Chicken Little Butterfly Bridge To New Town Change By Extraction Change On Copy Value-based Improvement
72. Big-Bang Vorgehen 1. Spezifiziere neues System 2. Entwerfe und implementiere neues System 3. Nach Fertigstellung & Abnahme werden Benutzer und Clients auf neues System umgestellt Risiken • Spezifikation aufgrund der Komplexität des alten Systems lücken- oder fehlerhaft • Know-How-Flucht: Demotivierte Mitarbeiter des alten Systems • Das neue System vermeidet zwar bekannte Fehler, enthält jedoch neue! • Business erhält lange Zeit (Jahre!) keine signifikanten neuen Features • Schwierige, aufwändige Datenmigration • Bereits die Anforderungsanalyse oft sehr schwierig
73. Big Bang (aka Cold Turkey) Client Code Flawed System User 1 New System Client Code User Entwickle ein neues System parallel zu Betrieb und Pflege des alten.
74. Branch by Abstraction Vorgehen 1. Kapsele die Interaktion mit den schlechten Teilen über eine Abstraktion (Interface) 2. Lasse sämtlichen Client-Code nur noch dieses Interface verwenden 3. Erstelle einen besseren Supplier (Provider, Server) für dieses Interface 4. Entferne den alten Supplier Risiken • Entsteht auf Basis des schlechten Suppliers... Ggfs. ist die Abstraktion schlecht! Voraussetzungen • Klare Schnittstelle für bestehende Dienste definierbar
75. Branch-By-Abstraction (1) Client Code Flawed Supplier Client Code Client Code Flawed Supplier Client Code Abstraction Layer Client Code Flawed Supplier Client Code Abstraction Layer Kapsele die Interaktion mit den schlechten Teilen Lasse sämtlichen Client-Code diese Kapselung nutzen Erstelle einen besseren Supplier Client Code Flawed Supplier Client Code Abstraction Layer Abstraction Layer New Supplier 1 2 3
76. Branch-By-Abstraction (2) Vervollständige den Supplier, ggfs. entferne den alten. Client Code Flawed Supplier Client Code Abstraction Layer Abstraction Layer New Supplier Client Code Flawed Supplier Client Code Abstraction Layer New Supplier 4
77. Change By Split Vorgehen 1. Identifiziere mehrere Benutzergruppen (BG) 2. Klone gesamtes System für jede BG 3. Reduziere für jede BG, extrahiere Gemeinsamkeiten (technische Basis) 4. Optimiere für jede BG Risiken • Gemeinsamkeiten schwer zu isolieren • Mehrere Teams benötigt (1 pro Klon + Basis) Voraussetzungen • stark unterschiedliche Benutzergruppen
78. Change By Split Client Type 1 Flawed System Client Type 2 Kopiere für alle Client-Typen 1 Client Type 1 Flawed System Client Type 2 Flawed System Client Type 1 Reduced to Type 1 Client Type 2 Reduced to Type 2 Commons Reduziere und extrahiere Gemeinsamkeiten 2 Client Type 1 Reduced to Type 1 Client Type 2 Reduced to Type 2 New Commons Optimiere Gemeinsamkeiten 3
79. Change By Split (2) Client Type 1 Reduced to Type 1 Client Type 2 Reduced to Type 2 New Commons Optimiere spezifische Teilsysteme („Splits“) 4 New Type 1 System Client Type 1 Client Type 2 New Commons New Type 2 System
80. Meine Versprechen („Agenda“) 1. Methodisches Verbessern 2. Schlimme Probleme finden 3. Management überzeugen 4. Mittel- und langfristige Verbesserungen 5. Mit Tagesgeschäft vereinbaren «category» Improve Processes «category» Improve Technical Infrastructure «category» Improve Analysability & Evaluability «category» Improve Architecture & Code Structure
81. aim42.github.io aim42.org
82. Dr. Gernot Starke gernot.starke@innoQ.com http://innoq.com https://www.flickr.com/photos/foto_db/16000636092
83. Agenda https://www.flickr.com/photos/valbanese/8663968105/ by https://www.flickr.com/photos/valbanese/ Schulden eintreiben https://www.flickr.com/photos/reindertot/3352164734/ by https://www.flickr.com/photos/reindertot/ Basel https://www.flickr.com/photos/tambako/3007256159/ by https://www.flickr.com/photos/tambako/ Problems https://www.flickr.com/photos/portland_mike/6852704246/ by https://www.flickr.com/photos/portland_mike/ Broken Fence https://www.flickr.com/photos/socsci/21844740756/ by https://www.flickr.com/photos/socsci/ Circle https://www.flickr.com/photos/infomastern/14519782386/ by https://www.flickr.com/photos/infomastern/ Spectrum of Topics (Spices) https://www.flickr.com/photos/crobj/5519129659 by https://www.flickr.com/photos/crobj/ Measuring https://www.flickr.com/photos/david_mackay/5541294472/ by https://www.flickr.com/photos/david_mackay/ https://www.flickr.com/photos/mad_house_photography/4311409835/ by https://www.flickr.com/photos/david_mackay/ Evaluate / Estimation https://www.flickr.com/photos/evelynsaenz/4987334392/ by https://www.flickr.com/photos/evelynsaenz/ https://www.flickr.com/photos/jakerust/16811604186/ by https://www.flickr.com/photos/jakerust/ Long Term Improvement https://www.flickr.com/photos/legion293/4921980590/ by https://www.flickr.com/photos/legion293/ Image Credits