Entwicklertag FFM 2018: Software nachhaltig sanieren

Es ist nichts beständiger als der Wandel. IT Systeme müssen deshalb ebenfalls laufend geändert werden, oft genug ist das ein Problem. Egal ob der Auslöser eine Firmenübernahme ist, der Legacy-Stack auf die neueste unterstützte Version migriert werden soll oder ob sich das unter Zeitdruck erstellte Greenfield-Projekt als strukturloser "Big Ball of Mud" entpuppt - ein Sanierungsfall liegt vor.

Diese Vorstellung ist für viele Entwickler mindestens abschreckend. Ein Großteil der massiven Codebasis muss angepasst werden. Wo fängt man an? Und wie geht man vor, ohne sich in einem Netz unvollständiger Änderungen zu verstricken?

Angefangen bei kurzfristigen Stabilisierungsmaßnahmen über organisatorische Aspekte bis hin zu sozialen Themen teilen wir in dieser Session unsere Erfahrungen, die wir zu den drei Säulen "Infrastruktur", "Techniken" und "Vorgehen" für eine nachhaltige Sanierung verdichtet haben. Steht zu Beginn mit Messen und Erste-Hilfe-Maßnahmen bei der (Entwicklungs-)Infrastruktur vor allem kurzfristig Erreichbares auf der Agenda, folgen Techniken mit dem Ziel des testbar Machens von Bestandscode, kontinuierlichen Refactorings von Code und Architektur in kleinen Schritten und schließlich langfristigee Maßnahmen für nachhaltig mehr Qualität in Form eines gemeinsamen Managements technischer Schulden, Qualitäts- und Verantwortungskultur im Team.

Ziel ist der systematische Abbau von technischen Schulden als kontinuierlicher Prozess und dadurch nachhaltig bessere Software.

Transcript

1. Software nachhaltig sanieren Entwicklertag 2018 Frankfurt, 21. Februar
2. Silas Graffy Johannes Seitz @SilasG @Ookami86
3. IT-Consulting, Software Engineering & Test Management SBB CFS FFS 24 Mio. Umsatz * 350 Mitarbeiter 8 Jahre in Folge 3 Tage F&E pro MA/Jahr Berlin Frank- furt München 22 Natio- nalitäten * Zahlen für 2017 geschätzt
4. Wie entsteht Legacy Software? Wie wird man Legacy Software los? - Unsere Prinzipien für eine nachhaltige Sanierung - Die drei Säulen Fazit und Literatur Agenda 1. 2. 3.
5. Wie entsteht Legacy Software? Agenda 1.
6. Wie entsteht „Tech Debt“? Fahrlässig Mit Bedacht Mit Absicht Ohne Absicht „Für Qualität haben wir keine Zeit“ „Um den Termin zu halten, schieben wir Aufräumarbeiten auf“ Was ist eine Race Condition? Jetzt wissen wir besser wie es geht https://martinfowler.com/bliki/TechnicalDebtQuadrant.htm
7. Klar kommunizieren, Tracken, Zeit zum Abbau fordern Kontinuierlich und inkrementell abbauen Wie entsteht „Tech Debt“? Fahrlässig Mit Bedacht Mit Absicht Ohne Absicht https://martinfowler.com/bliki/TechnicalDebtQuadrant.htm Mehr Mut! Weiterbildung
8. Wie wird man Legacy Software los? Agenda 2.
9. Wie wird man Legacy Software los? - Unsere Prinzipien für eine nachhaltige Sanierung Agenda 2.
10. Prinzipien 1. Inkrementell 2. Mutig 3. Kollaborativ - Besser planbar - Geringeres Risiko - Leicht rückgängig zu machen - Früheres Lernen, direktes Profitieren - Zeitdruck und Furcht sind Garant für hohe Zeitverschwendung - Unbedingt ganzes Team involvieren
11. Wie wird man Legacy Software los? - Die drei Säulen Agenda 2.
12. Die Drei Säulen Infrastruktur Techniken Vorgehen - Erste Hilfe leisten - Metriken erfassen - Testing Legacy - Parallel Change - Branch by Abstraction - Strangler Application - Schulden bewerten - Schulden überwachen - Qualitätskultur - Kollektiv Entscheidungen verantworten Nachhaltige Sanierung Kurzfristig erreichbar Langfristig erreichbar
13. Die Drei Säulen Infrastruktur Techniken Vorgehen - Erste Hilfe leisten - Metriken erfassen - Testing Legacy - Parallel Change - Branch by Abstraction - Strangler Application - Schulden bewerten - Schulden überwachen - Qualitätskultur - Kollektiv Entscheidungen verantworten Nachhaltige Sanierung Kurzfristig erreichbar Langfristig erreichbar
14. Erste Hilfe leisten - VCS einführen - Builds automatisieren - CI Server aufsetzen - Automatische Tests ermöglichen
15. Metriken erfassen - Linter - Coverage Tools - Profiler - Structure 101 http://structure101.com/ - SonarQube https://www.sonarqube.org/ - Source Monitor http://www.campwoodsw.com/ sourcemonitor.html - Code Charta https://github.com/ MaibornWolff/codecharta
16. Die Drei Säulen Infrastruktur Techniken Vorgehen - Erste Hilfe leisten - Metriken erfassen - Testing Legacy - Parallel Change - Branch by Abstraction - Strangler Application - Schulden bewerten - Schulden überwachen - Qualitätskultur - Kollektiv Entscheidungen verantworten Nachhaltige Sanierung Kurzfristig erreichbar Langfristig erreichbar
17. Testing Legacy Code - Wir brauchen Tests! - Techniken, die Legacy testbar machen - Langfristiges Ziel: Testpyramide
18. Golden Master Technik Aufgezeichneter Input (Datei) Aufgezeichneter Output (Datei) Legacy Applikation Sanierte Applikation Input für UI/API Input für UI/API Output Vergleich des Output
19. Testpyramide Autom. UI-Tests Integrationst ests Unit-Tests Automatisierte UI-Tests Integrationst ests Unit-Tests Manuelles Testen Session Based Testing
20. Das Problem mit Refactorings Automated GUI Tests Automated Unit Tests
21. Branch by abstraction Parallel Change Strangler Application
22. Strangler Application Automated GUI Tests Automated Unit Tests https://paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/
23. Die Drei Säulen Infrastruktur Techniken Vorgehen - Erste Hilfe leisten - Metriken erfassen - Testing Legacy - Parallel Change - Branch by Abstraction - Strangler Application - Schulden bewerten - Schulden überwachen - Qualitätskultur - Kollektiv Entscheidungen verantworten Nachhaltige Sanierung Kurzfristig erreichbar Langfristig erreichbar
24. Schulden bewerten - „Pain Points“ sammeln - Priorisieren à wie sehr behindert die Schuld uns? - Gemeinsam entscheiden: Was sofort angehen? Pain Effort
25. Schulden überwachen - Metriken regelmäßig reviewen - Im Team transparent machen à Motivation - Wenn möglich versehentlichen Neuaufbau per Tooling ver- hindern
26. Qualitätskultur & kontinuierliche Verbesserung Quality Fridays If it hurts, do it more often: Continuous Integration Unnötige Komplexität vermeiden und abbauen Test-driven Development Boy Scout Rule Pair Programming Code Reviews
27. Kollektiv Entscheidungen verantworten Automated GUI Tests - Gemeinsames Zielbild durch gemeinsame Entscheidungen - Architektur und Design - Verantwortung für den Prozess
28. Fazit und Literatur Agenda 3.
29. Fazit Eine nachhaltige Sanierung betrifft nicht nur Codebasis und Infrastruktur, sondern vor allem Prozess und Teamkultur.
30. Lesenswertes zum Thema https://www.maibornwolff.de/blog/it-sanierung-refactoring-schritt-fuer-schritt https://www.maibornwolff.de/blog/it-sanierung-grosse-aenderungen-strukturieren https://www.maibornwolff.de/blog/techniken-der-it-sanierung-der-golden-master-test https://www.maibornwolff.de/tags/it-sanierung
31. Vielen Dank für die Aufmerksamkeit! Fragen und Diskussionen jederzeit gern W e‘re hiring! In München, Frankfurt, Berlin und Augsburg
32. Backup
33. Was passiert wenn man „keine Zeit“ hat …
34. Parallel Change Benutzende Klasse Benutzende Klasse Benutzende Klasse Zu ändernde Klasse alteMethode() <<deprecated>> neueMethode()
35. Branch by Abstraction Benutzende Klasse Benutzende Klasse Benutzende Klasse Abzulösende Klasse(n)
36. Branch by Abstraction Benutzende Klasse Benutzende Klasse Benutzende Klasse Abzulösende Klasse(n) Abstraktion
37. Branch by Abstraction Benutzende Klasse Benutzende Klasse Benutzende Klasse Abzulösende Klasse(n) Abstraktion Neue Implementierung