Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Refactoring oder Nobody is perfect und es gibt (fast) nichts, was nicht anders gemacht werden könnte 800 = 8 * 100 = 100 * 8 = 25 * 32 = 5 2 * 2 5.

Ähnliche Präsentationen


Präsentation zum Thema: "Refactoring oder Nobody is perfect und es gibt (fast) nichts, was nicht anders gemacht werden könnte 800 = 8 * 100 = 100 * 8 = 25 * 32 = 5 2 * 2 5."—  Präsentation transkript:

1 Refactoring oder Nobody is perfect und es gibt (fast) nichts, was nicht anders gemacht werden könnte 800 = 8 * 100 = 100 * 8 = 25 * 32 = 5 2 * 2 5

2 Was ist Refactoring? Refactoring ist ein systematischer Ansatz, durch eine Serie von kleinen Modifikationen das Design eines bestehenden objektorientierten Programms so zu verbessern, dass sich neue Funktionalitäten leichter implementieren lassen oder das Programm anschließend leichter wartbar ist. Bei Refactoring wird das externe Verhalten des Programmes nicht geändert, der Code erhält aber eine bessere interne Struktur.

3 Warum Refactoring? Refactoring verbessert das Design der Software Refactoring macht die Software verständlicher Refactoring verbessert die Flexibilität Refactoring hilft Fehler zu finden Refactoring beschleunigt den Software- Entwicklungsprozess

4 Wann soll Refactoring eingesetzt werden? Vor Hinzufügen einer neuen Funktionalität Vor und Nach dem Codereview Code Bed Smells als Wegweiser

5 Bed Smells: If it stinks, change it - Kent Beck Bed Smell 1: Rule of three - Duplizierter Code –Beim ersten Mal wird der Code geschrieben. –Beim zweiten Mal kann der gleiche Code noch dupliziert werden. –Beim dritten Mal muss der Code umstrukturiert werden. Bed Smell 2: Lange Methode –Lange Methode macht den Code unübersichtlich Bed Smell 3: Große Klasse –besitzt viele Attribute und Methoden, erledigt die Arbeit von mehreren Klassen Bed Smell 4: Lange Parameterliste –Schwer zu verstehen und zu benutzen Bed Smell 5: Faule Klasse –Tut fast nichts, bringt unnötige Kosten Bed Smell 6: Kommentare –Kommentierter Code ist gut, selbstkommentierter Code ist besser u.v.a.

6 Wie soll Refactoring eingesetzt werden? Test bei jedem Schritt –Unit-Test –white-box Test Ein Schritt auf einmal –Rückzugsmöglichkeit sichern (CVS, o.a.) –nicht debuggen, sonder zurückziehen Keine Funktionalität ändern Grundlegende Modifikationen: –Hinzufügen –Umbenennen –Löschen –Bewegen –Extrahieren –Ersetzen von Strukturelementen (Attributen, Klassen, Methoden)

7 Refactoring Methoden Methode extrahieren –Zusammengehörigen Code in eine neue Methode extrahieren –Gegen: Duplizierter Code, Lange Methode, Kommentare Klasse extrahieren –Neue Klasse anlegen und Attribute und Methoden verschieben –Gegen: Duplizierter Code, Große Klasse Klasse integrieren –Attribute und Methoden in eine andere Klasse verschieben; Klasse löschen –Gegen: Faule Klasse Ganzes Objekt übergeben –Mehrere Parameter bilden eine natürliche Einheit –Gegen: Lange Parameterliste Schnittstelle extrahieren –Teilmenge der Methoden in eine Schnittstelle extrahieren –Gegen: Große Klasse u.v.a.

8 Refactoring Methode: Schnittstelle extrahieren Problem –Verschiedene Klienten verwenden die gleiche Teilmenge der Schnitt- stelle einer Klasse, oder zwei Klassen haben einen Teil ihrer Schnitt- stellen gemeinsam Lösung –Extrahieren Sie die Teilmenge in eine Schnittstelle Motivation –Schnittstellen sind immer dann nützlich, wenn eine Klasse in verschiedenen Situationen unterschiedliche Rolle spielt. Verwenden Sie die Schnittstelle extrahieren für jede Rolle. Eine andere nützliche Anwendung dieser Refactoring Methode besteht darin die Importschnittstelle zu beschreiben. Vorgehen –Erstellen Sie eine leere Schnittstelle –Deklarieren Sie die gemeinsame Methode in der Schnittstelle –Lassen Sie die relevanten Klassen die Schnittstelle implementieren –Lassen Sie die Klienten die Schnittstelle verwenden

9 Refactoring mit Eclipse

10 Wann soll Refactoring nicht eingesetzt werden? Vom Refactoring ist abzuraten Kurz vor dem Abschlusstermin –Refactoring wird die Entwicklung über den Termin hinaus verlängern –Vorteile würden zu spät wirken wenn der Code zu schlecht ist –z.B. nicht übersetzbar oder nicht stabil lauffähig –Basis für stabiles Verhalten und Testbarkeit fehlt

11 Was wir gesehen haben


Herunterladen ppt "Refactoring oder Nobody is perfect und es gibt (fast) nichts, was nicht anders gemacht werden könnte 800 = 8 * 100 = 100 * 8 = 25 * 32 = 5 2 * 2 5."

Ähnliche Präsentationen


Google-Anzeigen