Komplexe Refactorings an Legacy Code durchführen – Teil 2

Im ersten Schritt ist durch eine experimentelle Vorgehensweise ein Mikado Graph entstanden. Es wurde jeweils naiv versucht, die erforderlichen Änderungen am Code durchzuführen. Alle Probleme, die sich bei diesen Experimenten gezeigt haben, sind als Vorbedingungen für das Mikado Ziel in den Mikado Graph übernommen worden. Da die einzelnen Vorbedingungen aufeinander aufbauen, sich also in Abhängigkeiten befinden, enthält der Mikado Graph nicht nur die Vorbedingungen, sondern stellt auch die Abhängigkeiten dar. Lesen Sie im 2. Teil nun mehr zu den Details der Mikado Methode.

Komplexe Refactorings mit der Mikado Methode durchführen

Komplexe Refactorings an Legacy Code durchführen – Teil 1

Dies ist der erste Teil einer Beitragsserie über komplexe Refactorings an Legacy Code Projekten. Er erläutert, welche Herausforderung sich bei komplexen Änderungen zeigen. Anhand einer Bilderserie wird verdeutlich, zu welchen Problemen die übliche Vorgehensweise führt. Im Anschluss wird gezeigt, wie die Herausforderung mit Hilfe der Mikado Methode angegangen werden kann.

Unit Test Explorer

4 Tools, die das automatisierte Testen erleichtern (inkl. Tipps zur Nutzung)

Der Nutzen automatisierter Tests wird inzwischen zwar nicht mehr in Frage gestellt. Doch immer noch treffe ich auf Entwickler, denen es schwer fällt, regelmäßig Tests zu schreiben. Im Beitrag stelle ich 4 Tools vor, mit denen Unit Tests leichter von der Hand geht. Das hilft Ihnen vielleicht dabei, zu einem leidenschaftlichen Tester zu werden.

Einfache Refactorings – Teil 5

Um automatisierte Tests ergänzen zu können, ist es manchmal sinnvoll, einen Konstruktorparameter einzuführen, über den die Abhängigkeit von außen reingereicht werden kann. Der Beitrag zeigt, wie dies am Beispiel von DateTime.Now mit einer simplen Lambda Expression möglich ist.

Desweiteren befasst sich der Beitrag mit Abhängigkeiten. Reduzieren Sie Abhängigkeiten durch das Extrahieren eines Interface. Auf diese Weise kann häufig die Testbarkeit hergestellt oder verbessert werden.

Einfache Refactorings – Teil 4

Häufig kann der Code mit einem simplen Extract Method Refactoring verständlicher gemacht werden. Die zusätzliche Methode ermöglicht es dem Leser, allein anhand des Methodennamens zu verstehen, was der Code macht. Eine gute Ergänzung ist häufig das Introduce Parameter Refactoring. Dadurch werden alle Eingaben einer Methode in der Parameterliste sichtbar, was ebenfalls die Verständlichkeit erhöht.

Einen anderen Fokus hat das Move to Another Type Refactoring. Durch dieses Refactoring werden Aspekte getrennt, dadurch dass ein Teil der Aspekte in eine andere Klasse verschoben wird. Automatisiert mit Toolunterstützung durchgeführt ist das Risiko gering, die Funktionalität zu zerstören.

Tweet Umfrage Twitter Legacy Code Herausforderungen

Legacy Code – Die Herausforderungen

Wo liegt die größte Herausforderung beim Umgang mit Legacy Code?

Über Twitter habe ich kürzlich gefragt, was die größte Herausforderung im Umgang mit Legacy Code ist.

Nun ist Twitter bekanntermaßen darauf ausgelegt, nur knappe Antworten zu geben. Da jedoch mehr als ein Dutzend Antworten eingetroffen sind, will ich hier berichten, wo Entwickler Herausforderungen beim Umgang mit Legacy Code sehen. Die „Umfrage“ ist weit entfernt davon, repräsentativ zu sein. Ich glaube, die Antworten weisen dennoch auf die typischen Herausforderungen hin. Sollte Ihre persönliche Herausforderung nicht genannt sein, freue ich mich über Ihren Kommentar!

Einfache Refactorings – Teil 3

Ein weiteres Anwendungsgebiet für das Extract Method Refactoring sind Bedingungen von Verzweigungen. Die Bedingung einer if-Anweisung erschließt sich beim Lesen manchmal erst, wenn wir den Inhalt der Verzweigung lesen. Durch ein Extract Method Refactoring kann die Bedingung, mit einem Namen versehen, ausgelagert werden. Neben der Verbesserung der Lesbarkeit kann dies auch eine bedeuten, eine DRY Verletzung zu beheben.

Weiters befasst sich der Beitrag damit, die Eingaben einer Methode explizit sichtbar zu machen. Dazu werden die benötigten Werte mittels Introduce Parameter Refactoring in die Parameterleiste gezogen.

Einfache Refactorings – Teil 2

Nicht selten ist die Parameterliste einer Method über die Jahre etwas zu lang geworden. Manchmal stehen die Parameter in einem sinnvollen Zusammenhang zueinander, so dass man sie zu einer Klasse zusammenfassen kann. Das ist nicht immer der Fall, vor allem, wenn eine Methode für mehr als einen Aspekt zuständig ist. In solchen Fällen werden häufig einzelne Parameter oder Gruppen von Parametern für die unterschiedlichen Aspekte der Methode benötigt. In dem Fall kann es helfen, zunächst die Aspekte zu trennen.

Der Beitrag befasst sich mit dem Extract Class from Parameters Refactoring, mit dem die Parameter einer Methode zu einer neuen Klasse zusammengefasst werden. Sollte dies schwer fallen, weil in der Methode Aspekte vermischt sind, hilft oft ein Extract Method Refactoring dabei, Aspekte aus der Methode in weitere Methoden auszulagern.

Einfache Refactorings – Teil 1

In dieser Reihe von Blogbeiträgen stelle ich Ihnen sogenannte Einfache Refactorings vor. Im Gegensatz zu Komplexen Refactorings sind diese vollständig toolgestützt durchführbar. Das bedeutet, dass Sie die Veränderungen am Quellcode automatisiert mithilfe einer IDE, z.B. Microsoft Visual Studio oder JetBrains Rider, ausführen. Vielleicht setzen Sie auch ein zusätzliches Refactoring Tool ein wie JetBrains ReSharper. Durch Einsatz eines solchen Werkzeugs bleibt das Verhalten der Anwendung beim Refactoring erhalten. Solange Sie die Refactorings konsequent ausschließlich mit solchen Werkzeugen ausführen und nicht per Hand eingreifen, ist die Wahrscheinlichkeit sehr hoch, dass sich der Code hinterher genauso verhält wie vor dem Refactoring.

Der erste Beitrag der Serie beschreibt ferner, wie Sie mit dem Rename Refactoring sowie dem Introduce Variable Refactoring die Lesbarkeit Ihres Codes erhöhen.