Refactoring

Inhaltsverzeichnis

1 Begriffsherkunft 2 Vorteile 3 Risiken und deren Handhabung 4 Literatur 5 Externe Verweise

Begriffsherkunft

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

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

Die unzutreffende Übersetzung Refaktorisierung stammt aus einer Verwechslung mit einer zitierten Analogie die ursprünglich nicht Begriffsinhalt war: ist eine Art ein Programm so zu dass verborgene Strukturen offengelegt werden ohne die zu ändern: Dies so der Analog-Schluss entspreche Vorgehen der Faktorisierung von Polynomen in der Mathematik .

Vorteile

Refactoring dient der Verbesserung des Designs. Design hat verschiedene Vorteile. So erhöht sich Wiederverwendbarkeit von Komponenten . Außerdem verstehen auch andere Programmierer oder man selbst später besser den Schließlich ist guter Code flexibler.

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

Risiken und deren Handhabung

Refactoring wird nur auf funktionierendem Code (dessen Funktionalität soll ja erhalten bleiben). Dies aber auch das Risiko selbst etwas am Code kaputt zu Um dieses Risiko zu vermeiden (oder wenigstens minimieren) verwendet man verschiedene Regeln die den Prozess des Refaktorisierens ungefährlicher

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

Weiterhin gilt das Prinzip der kleinen Wenn man nur wenig verändert dann kann auch wenig zerstören. Meistens kann man komplexe die man plant in einfache kleine Einheiten Vor und nach jedem Schritt wird wieder die Tests die Integrität des Systems geprüft.

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

Literatur

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

Externe Verweise

• Refactoring-Startseite (englisch)
  • Katalog zu Refaktorisierungen (englisch)
  • Werkzeuge (englisch)
• Was ist Refactoring? - c2.com Artikel (englisch)
• 1993 PhD dissertation von William F. Opdyke (englisch)
• " Wie wird unwartbarer Quelltext geschrieben? " von Roedy Green (englisch)
• Zitate von CiteSeer

Bücher zum Thema Refactoring

Dieser Artikel von Wikipedia unterliegt der GNU FDL.