Refactoring von Legacy Code Michael Kokonowskyj Thomas Schissler artiso AG

download Refactoring von Legacy Code Michael Kokonowskyj Thomas Schissler artiso AG

If you can't read please download the document

  • date post

    05-Apr-2015
  • Category

    Documents

  • view

    103
  • download

    0

Embed Size (px)

Transcript of Refactoring von Legacy Code Michael Kokonowskyj Thomas Schissler artiso AG

  • Folie 1
  • Refactoring von Legacy Code Michael Kokonowskyj Thomas Schissler artiso AG
  • Folie 2
  • Folie 3
  • Aufwand fr neue Features Probleme in Legacy Code Risiko durch Vernderung Nutzung neuer Technologie n & Methoden
  • Folie 4
  • Ziele moderner Architektur WartbarErweiterbarTestbar
  • Folie 5
  • Folie 6
  • Hufige Lsung - Greenfield
  • Folie 7
  • Refactoring Renovierung des Codes
  • Folie 8
  • Folie 9
  • Anti-Patterns Redundanzen UI-Componenten (z.B. Message-Boxen) im Code verwenden Zugriffe auf Ressourcen (z.B. Files) nicht isolierbar Zu viel Funktionalitt in einer Methode Starke Bindung zwischen Klassen
  • Folie 10
  • Trennung -Daten - Orchestrierung -Logik Oberstes Ziel: Entkopplung Sackgassen- methoden Komponenten- orientierung IoC Interfaces MVVM / MVC Single Responsibilit y POCOs
  • Folie 11
  • Single Responsibility Methoden sollten nur ein Funktionalitt implementieren Es sollte genau einen Grund geben, eine Methode zu ndern Tests knnen diese atomare Logik gut abprfen
  • Folie 12
  • Abhngigkeiten zu Ressourcen Problem: Wie kontrollieren wir die Abhngigkeiten von Methoden Warum ist das berhaupt problematisch? Infrastrukturabhngigkeiten Destruktive Tests Hoher Initialisierungsaufwand Simulation von Testfllen oft schwierig
  • Folie 13
  • Komponentenorientierte Architektur Data Contract Operation Contract
  • Folie 14
  • Contracts Data Contract Operation Contract
  • Folie 15
  • Implementierung Komponente
  • Folie 16
  • Klassische Struktur SplitLine DB ReadData Recognize Integrations- Test SplitDigit Recognize Digit Unit-Test Integrations- Test
  • Folie 17
  • Entkoppelte Struktur durch Orchestrierung SplitLine DB Unit-Test ReadData Recognize Integrations-Test Unit-Test SplitDigit Recognize Digit Unit-Test Integrations- Test
  • Folie 18
  • Inversion of Control (IoC) Constructor Injection
  • Folie 19
  • Folie 20
  • Refactoring Best Practices Kleine Schritte Hufig lauffhige Stnde anstreben Mit einfachen und schnellen Ergebnissen beginnen (Pfadfinder-Regel) Aus kleinen Bereichen lernen statt alles auf ein Mal umstellen Testautomatisierung sofort mit umsetzen berprfung der Refaktoring-Ziele Sicherheit Patterns extrahieren Fr neue Funktionen lernen und im gesamten Team kommunizieren Einheitliche Strukturen
  • Folie 21
  • Visualisierung Kandidaten zu identifizieren Komplexitt abzuschtzen Fortschritt transparent machen Notwendige Anpassungen erkennen Code Maps / Dependency Graph / Layer Diagramm / Code Metrics
  • Folie 22
  • Demo
  • Folie 23
  • Folie 24
  • Die Mikado-Methode Refactoring-Ziel definieren Refactoring implementieren Fehler? Fehler dokumentieren nderungen rckgngig machen Nchste Anpassung identifizieren Anpassungen bernehmen Ziel erreicht? Fertig Start Nein Ja Nein
  • Folie 25
  • Die Mikado-Methode Grid ersetzen Export Speichern- Methode Neu berechnen Validierung
  • Folie 26
  • Folie 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!
  • Folie 28
  • Folie 29
  • Kontakt Vielen Dank fr ihre Aufmerksam -keit Thomas Schissler artiso solutions GmbH Oberer Wiesenweg 25 D - 89134 Blaustein +49 7304 / 803-180 TSchissler@artiso.com http://www.artiso.com www.artiso.com/problog