| |
|
Refactoring, deutsch meist unzutreffend mit Refaktorisierung bezeichnet, ist ein Begriff aus der Informatik, spezieller der Softwareentwicklung. Durch Refaktorisierung verbessert man Lesbarkeit und Struktur (Architektur) eines Programms, dessen Funktionalität bleibt aber erhalten. Refaktorisierung ist eine Methode des Extreme Programming.
Der Ausdruck wurde zum ersten Mal in einer Arbeit 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 Applictaions (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 Funktionaliät zu ändern: Dies, so der Analog-Schluss, entspräche dem Vorgehen der Faktorisierung von Polynomen in der Mathematik.
Refactoring dient der Verbesserung des Designs. Gutes Design hat verschiedene Vorteile. So erhöht sich die Wiederverwendbarkeit von Komponenten. Außerdem verstehen auch andere Programmierer oder man selbst später besser den Code. 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 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. Refaktorisierung erlaubt dem Entwickler diesen Zyklus permanent im Kleinen ablaufen zu lassen, und so sein Produkt kontinuierlich zu verbessern.
Refactoring wird nur auf funktionierendem Code ausgeführt (dessen Funktionalität soll ja erhalten bleiben). Dies beinhaltet aber auch das Risiko, selbst etwas am Code kaputt zu machen. Um dieses Risiko zu vermeiden (oder wenigstens zu minimieren) verwendet man verschiedene Regeln, die den Prozess des Refaktorisierens ungefährlicher machen.
Zuallererst sollte man eine Reihe automatisch ablaufender Unit-Tests haben. Diese werden vor der Refaktorisierung 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 Fehler beim Refactoring sofort erkennen.
Weiterhin gilt das Prinzip der kleinen Änderungen. Wenn man nur wenig verändert, dann kann man auch wenig zerstören. Meistens kann man komplexe Refaktorisierungen, 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.
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.
Begriffsherkunft
Vorteile
Risiken und deren Handhabung
Weblinks und Literatur