Refactoring von Legacy Code

Refactoring von Legacy Code

Michael KokonowskyjThomas Schissler

artiso AG

Ziele ?Was soll durch Refactoring verbessert werden

Aufwand für neue Features

Probleme in Legacy Code

Risiko durch Veränderung

Nutzung neuer Technologien & Methoden

Ziele moderner Architektur

Wartbar ErweiterbarTestbar

Wie ?Ansätze zur Verbesserung des Codes

Häufige Lösung - Greenfield

Refactoring – Renovierung des Codes

ArchitekturAnti-Patterns und wie es sein sollte

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

Trennung -Daten-Orchestrierung -Logik

Oberstes Ziel: Entkopplung

Sackgassen-methoden

Komponenten-orientierung IoCInterfaces

MVVM / MVC

Single Responsibility

POCOs

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?

– Infrastrukturabhängigkeiten– Destruktive Tests– Hoher Initialisierungsaufwand– Simulation von Testfällen oft schwierig

Recognize1.) Aus File laden2.) Split3.) Recognize

FileUnit-Test

Komponentenorientierte Architektur

A B

Data ContractOperation Contract

Contracts Data Contract

Operation Contract

Implementierung Komponente

Klassische Struktur

SplitLine

DB

ReadData

Recognize

Integrations-TestSplitDigit

Recognize Digit Unit-Test

Integrations-Test

Integrations-Test

Integrations-Test

Entkoppelte Struktur durch Orchestrierung

SplitLine

DB

Unit-Test

ReadData

Recognize

Integrations-Test

Unit-Test

SplitDigit Recognize Digit

Unit-TestIntegrations-

Test

Inversion of Control (IoC)

Constructor Injection

StrategienRefactoring in der Praxis

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

Tipps & TricksSo funktionierts mit dem Refactoring

Die Mikado-Methode

Refactoring-Ziel definieren

Refactoring implementieren

Fehler?

Fehler dokumentieren

Änderungen rückgängig machen

Nächste Anpassung identifizieren

Anpassungen übernehmen

Ziel erreicht?

Fertig

Start

Nein

Ja

Ja

Nein

Die Mikado-MethodeGrid

ersetzen

Export Speichern-Methode

Neu berechnen

Validierung

FazitWas sollten sie mitnehmen?

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!

Noch Fragen?

Kontakt

Vielen Dank für ihre Aufmerksam-keit

Thomas Schisslerartiso solutions GmbHOberer Wiesenweg 25D - 89134 Blaustein

+49 7304 / 803-180 TSchissler@artiso.comhttp://www.artiso.comwww.artiso.com/problog