Refactoring von Legacy Code

1. Refactoring von Legacy Code Michael Kokonowskyj Thomas Schissler artiso AG

2. Ziele ? Was soll durch Refactoring verbessert werden

3. Probleme in Legacy Code Risiko durch Veränderung Aufwand für neue Features Nutzung neuer Technologien & Methoden

4. Ziele moderner Architektur Wartbar Testbar Erweiterbar

5. Wie ? Ansätze zur Verbesserung des Codes

6. Häufige Lösung - Greenfield

7. Refactoring – Renovierung des Codes

8. Architektur Anti-Patterns und wie es sein sollte

9. Anti-Patterns • Redundanzen • UI-Componenten (z.B. Message-Boxen) im Code verwenden • Zugriffe auf Ressourcen (z.B. Files) nicht isolierbar • Zu viel Funktionalität in einer Methode • Starke Bindung zwischen Klassen

10. Oberstes Ziel: Entkopplung Single Responsibility MVVM / MVC POCOs Sackgassen-methoden Trennung -Daten-Orchestrierung -Logik Komponenten-orientierung IoC Interfaces

11. Single Responsibility • Methoden sollten nur ein Funktionalität implementieren • Es sollte genau einen Grund geben, eine Methode zu ändern • Tests können diese atomare Logik gut abprüfen

12. Abhängigkeiten zu Ressourcen • Problem: Wie kontrollieren wir die Abhängigkeiten von Methoden • Warum ist das überhaupt problematisch? • Infrastrukturabhängigkeiten • Destruktive Tests • Hoher Initialisierungsaufwand • Simulation von Testfällen oft schwierig Recognize 1.) Aus File laden 2.) Split 3.) Recognize Unit-Test File

13. KomponentenorientierteArchitektur A B Data Contract Operation Contract

14. Contracts • Data Contract • OperationContract

15. Implementierung • Komponente

16. Klassische Struktur Recognize Integrations-Test SplitLine Integrations-Test ReadData Integrations-Test DB SplitDigit Integrations-Test Recognize Digit Unit-Test

17. Entkoppelte Struktur durch Orchestrierung Integrations-Test Recognize ReadData SplitLine Recognize Digit SplitDigit Unit-Test Integrations-Test Unit-Test Unit-Test DB

18. Inversion of Control (IoC) • ConstructorInjection

19. Strategien Refactoring in der Praxis

20. Refactoring Best Practices • Kleine Schritte • Häufig lauffähige Stände anstreben • Mit einfachen und schnellen Ergebnissen beginnen (Pfadfinder-Regel) • Aus kleinen Bereichen lernen statt alles auf ein Mal umstellen • Testautomatisierung sofort mit umsetzen • Überprüfung der Refaktoring-Ziele • Sicherheit • Patterns extrahieren • Für neue Funktionen lernen und im gesamten Team kommunizieren • Einheitliche Strukturen

21. Visualisierung • Kandidaten zu identifizieren • Komplexität abzuschätzen • Fortschritt transparent machen • Notwendige Anpassungen erkennen • Code Maps / Dependency Graph / Layer Diagramm / Code Metrics

22. Demo

23. Tipps & Tricks So funktionierts mit dem Refactoring

24. Die Mikado-Methode Start Refactoring implementieren Nächste Anpassung identifizieren Refactoring-Ziel definieren Fehler? Anpassungen übernehmen Nein Ja Ziel erreicht? Nein Fehler dokumentieren Ja Änderungen rückgängig machen Fertig

25. Die Mikado-Methode  Grid ersetzen    Export Neu berechnen Speichern-Methode  Validierung

26. Fazit Was sollten sie mitnehmen?

27. Zusammenfassung • Unit-Testing ist essentiell • Refactoring muss gewollt werden, von allen Beteiligten • Refactoring ist eine kontinuierliche Aufgabe • Refactoring ist eine Investition, lohnt sich aber • Dem Greenfield-Impuls wiederstehen, Refactoring heute starten!

28. Noch Fragen?

29. Kontakt Vielen Dank fürihreAufmerksam-keit • Thomas Schissler • artiso solutions GmbHOberer Wiesenweg 25D - 89134 Blaustein • +49 7304 / 803-180 TSchissler@artiso.com • http://www.artiso.com • www.artiso.com/problog