Transcript Refactoring von Legacy Code

Refactoring von
Legacy Code
Michael Kokonowskyj
Thomas Schissler
artiso AG
Probleme in Legacy Code
Risiko durch
Veränderung
Aufwand für
neue Features
Nutzung
neuer
Technologien
& Methoden
Ziele moderner Architektur
Wartbar
Testbar
Erweiterbar
Häufige Lösung - Greenfield
Refactoring – Renovierung des Codes
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
Oberstes Ziel: Entkopplung
Single
Responsibility
MVVM / MVC
POCOs
Sackgassenmethoden
Trennung
-Daten
-Orchestrierung
-Logik
Komponentenorientierung
IoC
Interfaces
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
Abhängigkeiten zu Ressourcen
 Problem: Wie kontrollieren wir die Abhängigkeiten
von Methoden
 Warum ist das überhaupt problematisch?
Recognize
Unit-Test
–
–
–
–
1.) Aus File laden
2.) Split
3.) Recognize
Infrastrukturabhängigkeiten
Destruktive Tests
Hoher Initialisierungsaufwand
Simulation von Testfällen oft schwierig
File
Komponentenorientierte Architektur
Data Contract
Operation Contract
Contracts
 Data Contract
 Operation Contract
Implementierung
 Komponente
Klassische Struktur
IntegrationsTest
Recognize
IntegrationsTest
SplitLine
IntegrationsTest
ReadData
DB
SplitDigit
Recognize Digit
IntegrationsTest
Unit-Test
Entkoppelte Struktur durch Orchestrierung
Integrations-Test
Recognize
DB
ReadData
SplitLine
SplitDigit
Recognize Digit
IntegrationsTest
Unit-Test
Unit-Test
Unit-Test
Inversion of Control (IoC)
 Constructor Injection
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
Visualisierung




Kandidaten zu identifizieren
Komplexität abzuschätzen
Fortschritt transparent machen
Notwendige Anpassungen erkennen
 Code Maps / Dependency Graph / Layer
Diagramm / Code Metrics
Demo
Die Mikado-Methode
Start
Refactoring
implementieren
Refactoring-Ziel
definieren
Anpassungen
übernehmen
Nein
Fehler?
Ja
Ziel
erreicht?
Nein
Fehler
dokumentieren
Ja
Fertig
Änderungen
rückgängig machen
Nächste Anpassung
identifizieren
Die Mikado-Methode
Export

Grid
ersetzen

SpeichernMethode

Validierung
Neu
berechnen


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!
Kontakt
Vielen Dank
für ihre
Aufmerksamkeit
Thomas Schissler
artiso solutions GmbH
Oberer Wiesenweg 25
D - 89134 Blaustein
+49 7304 / 803-180
[email protected]
http://www.artiso.com
www.artiso.com/problog