Refactoring

aus Wikipedia, der freien Enzyklopädie

Du hast neue Nachrichten auf deiner Diskussionsseite.

Refactoring bezeichnet in der Software-Entwicklung die manuelle oder automatisierte Strukturverbesserung von Programm-Quelltexten unter Beibehaltung des bestehenden Programm-Verhaltens. Dabei sollen die Lesbarkeit, Verständlichkeit, Wartbarkeit und Erweiterbarkeit verbessert werden, mit dem Ziel, die Aufwände für Fehleranalyse und funktionale Erweiterungen deutlich zu senken.

Refactoring ist ein wichtiger Bestandteil des Extreme Programming.

Refactoring wird manchmal auch mit der eher unzutreffenden Bezeichnung Refaktorisierung oder mit Refaktorierung übersetzt. Im aktuellen Visual Studio 2005 von Microsoft wird Refactoring als Umgestaltung bezeichnet.

Inhaltsverzeichnis

1 Begriffsherkunft
2 Vorgehensweise
- 2.1 Mögliche Refactorings
3 Vorteile
4 Risiken und deren Handhabung
5 Literatur
6 Weblinks

[Bearbeiten] Begriffsherkunft

Der Begriff wurde zum ersten Mal in einer Arbeit von Ralph Johnson und William Opdyke 1990 gebraucht ("Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In: Proceedings of Symposion on Object-Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990)). Opdyke promovierte 1992 über das Thema.

Sie entwickelten die Idee einer Software-Refactory, die das Umgestalten (eben das re-factoring) von Software-Programmen erleichtern sollte.

Die unzutreffende Übersetzung Refaktorisierung stammt aus einer Verwechslung mit einer häufig zitierten Analogie, die ursprünglich nicht Begriffsinhalt war: Refactoring ist eine Art, ein Programm so zu modifizieren, dass verborgene Strukturen offengelegt werden, ohne die Funktionalität zu ändern: Dies, so der (fälschliche) Analogieschluss, entspreche dem Vorgehen der Faktorisierung von Polynomen in der Mathematik.

[Bearbeiten] Vorgehensweise

Beim Refactoring wird der Quelltext eines Computerprogramms umgestaltet, wobei die tatsächliche Programmfunktion unverändert bleiben soll. Die Umgestaltung des Quelltextes erfolgt meist nach folgenden Gesichtspunkten:

Lesbarkeit
Übersichtlichkeit
Verständlichkeit
Erweiterbarkeit
Vermeidung von Redundanz
Testbarkeit

Die Gesichtspunkte des Refactorings hängen eng mit den daraus resultierenden Vorteilen zusammen.

Das Refactoring wird erleichtert und unterstützt durch:

Unit-Tests, die als Regressionstests belegen können, dass das Programm sich immer noch gleich verhält und durch das Refactoring nicht versehentlich Fehler eingeführt wurden
Werkzeuge, insbesondere integrierte Entwicklungsumgebungen, die eine Unterstützung bei der Durchführung von Refactorings anbieten.

[Bearbeiten] Mögliche Refactorings

Folgendes sind besonders häufig eingesetzte Refactorings:

Änderung eines Symbolnamens.
Verschieben eines Symbols in ein anderes Modul, z.B. eine Methode in eine andere Klasse.
Aufteilung eines Moduls (z.B. Paket, Klasse, Methode) in mehrere kleinere Module oder Zusammenlegung kleinerer Module zu einem größeren.
Im weitesten Sinne auch die Umformatierung eines Quelltextes, z.B. mit einem Beautifier
Bei geänderten Geschäftsprozessen bei Darstellung mittels der Unified Modeling Language UML kann mittels "Refactoring" der Programmcode geändert werden. Dadurch wird eine robuste und stabile Systemarchitektur geschaffen, da unübersichtliche Änderungen nicht im Code initiiert werden müssen.

[Bearbeiten] Vorteile

Refactoring dient der Verbesserung der Wartbarkeit des Designs in der Art, dass es für den Programmierer leichter wird, den bestehenden Code funktional zu erweitern oder an anderer Stelle wiederzuverwenden. Dies versucht man zu erreichen, indem man den Code bezüglich folgender Kriterien verbessert:

Lesbarkeit, so dass möglichst viele Programmierer verstehen, was der Code tatsächlich macht
Testbarkeit (siehe Unit-Test), so dass es möglich wird, die korrekte Arbeitsweise des Codes für die Zukunft durch Regressionstests abzusichern
Modularität und Redundanz, so dass konkrete Problemlösungen von anderer Stelle genutzt werden können und nicht mehrfach implementiert sind

Im üblichen Softwareentwicklungszyklus ist ein fortwährender Kreislauf von Spezifikation, Design, Implementierung und Tests vorgesehen. Nach jedem Durchlauf kann das Softwareprodukt immer wieder neu in diesen Kreislauf einsteigen. Mit den klassischen Techniken hieß das jedoch, dass nach einer Änderung der Spezifikation oder einem Redesign oft Teile oder sogar das ganze Programm völlig neu geschrieben werden mussten. Refactoring erlaubt dem Entwickler diesen Zyklus permanent im Kleinen ablaufen zu lassen, und so sein Produkt kontinuierlich zu verbessern.

[Bearbeiten] Risiken und deren Handhabung

Refactoring wird nur auf funktionierendem Code ausgeführt (dessen Funktionalität soll ja erhalten bleiben). Dies beinhaltet aber auch das Risiko ungewünschter Änderungen und Fehler. Um dieses Risiko zu vermeiden (oder wenigstens zu minimieren) verwendet man verschiedene Regeln, die den Prozess des Refaktorisierens ungefährlicher machen.

Zuerst sollte man eine Reihe automatisch ablaufender Unit-Tests haben. Diese werden vor der Refactoring angewandt, und man beginnt erst, wenn die Tests alle funktionieren. Dies stellt sicher, dass das Programm richtig läuft. Nach Ausführung des Refactoring wird wieder die Testsuite ausgeführt. So kann man viele Fehler beim Refactoring sofort erkennen.

Weiterhin gilt das Prinzip der kleinen Änderungen. Wenn man nur wenig verändert, so kann man hoffen, auch nur wenig zu zerstören, falls man durch das Refactoring Fehler einträgt (dieses Argument wird allerdings durch die Tatsache geschmälert, dass es sich bei Digitalrechnern um maximal unstetige Systeme handelt, in denen kleine Ursachen sehr wohl große Auswirkungen haben können). Meistens kann man komplexe Refactorings, die man plant, in einfache kleine Einheiten zerlegen. Vor und nach jedem Schritt wird wieder durch die Tests die Integrität des Systems geprüft. Durch die Verwendung automatisierter Refactoring-Funktionen (wie sie z.B. von Eclipse oder Borland Delphi 2005 zur Verfügung gestellt werden) lassen sich ebenfalls Fehlerquellen effektiv ausschließen sowie der eigene Arbeitsaufwand minimieren.

Schließlich gibt es einen Katalog von Refactoring-Mustern, die ähnlich wie die Entwurfsmuster eingesetzt werden, um Fehler zu vermeiden. Dabei ist in jedem Muster eine Reihe von Parametern definiert. Da wäre erstmal das Ziel des Musters (Methode extrahieren, Klasse umbenennen, etc.) und dazu dann eine Reihe von Arbeitsanweisungen, die für diese Aktion ausgeführt werden müssen. Viele dieser Muster können heutzutage automatisch von Werkzeugen umgesetzt werden. Man trifft als Softwareentwickler nur noch die Entscheidung, welches Muster worauf angewendet wird, um den Quelltext zu verbessern.

[Bearbeiten] Literatur

Martin Fowler: Refactoring. Wie Sie das Design vorhandener Software verbessern. Addison-Wesley Verlag, ISBN 3-8273-1630-8.
William C. Wake: Refactoring Workbook. Addison-Wesley, ISBN 0-321-10929-5.
Joshua Kerievsky: Refactoring To Patterns. Addison-Wesley, ISBN 0321213351.