Refactoring

Durch Marin Fowlers Buch “Refactoring: Improving the Design of Existing Code”², an dem u. a. auch Dr. Opdyke mitgewirkte, verbreitete sich der Begriff und die Techniken des Refactorings sehr schnell unter Softwareentwicklern.

Gründe für Refactoring

Was sind die beiden wesentlichen Gründe für den Bedarf an Refactoring? Die Antwort lautet:

• Komplexität und
• technische Schulden.

1980 – also noch bevor der Begriff Refactoring genutzt wurde, schrieb Meir “Manny” Lehmann, ein deutscher Professor und Leiter des Computing Departments am Imperial College London: “As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it”.³

Frei ins Deutsche übersetzt: “Wenn ein sich entwickelndes Programm ständig geändert wird, steigt seine Komplexität, die eine sich verschlechternde Struktur widerspiegelt, sofern nicht daran gearbeitet wird, diese zu erhalten oder zu reduzieren.”

Und Ward Cunningham, einer der 17 Autoren des Agilen Manifests, nutzte die sogenannte “Debt Metapher”, um die Bedeutung von Refactorings im Zuge der Beseitigung von technischen Schulden zu betonen: “With borrowed money you can do something sooner than you might otherwise, but then until you pay back that money you’ll be paying interest. I thought borrowing money was a good idea, I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it”.⁴

Frei ins Deutsche übersetzt: “Mit geliehenem Geld kann man etwas früher tun, als man es sonst könnte, allerdings sind Zinsen fällig, bis das geliehene Geld zurückbezahlt wurde. Eine Software frühzeitig auf den Markt zu bringen, um Erfahrungen damit zu sammeln, ist meiner Ansicht nach eine gute Idee. Natürlich muss man das Darlehen zurückzahlen, also das Gelernte auch in die Software überführen und das Programm überarbeiten. So fließen neue Erkenntnisse in das Produkt ein”. 

Ziele beim Refactoring

Grundsätzlich adressiert Refactoring zwei konkrete Ziele:

• Die Steigerung der Performance der Software.
• Die Erleichterung der Weiterentwicklung der Software.

In der Literatur und zahlreichen Beiträgen werden häufig weitere/andere Ziele genannt:

• Lesbarkeit,
• Übersichtlichkeit,
• Erweiterbarkeit,
• Verständlichkeit und
• Testbarkeit.

Natürlich ist eine strukturelle Übersichtlichkeit wünschenswert, ebenso wie die Lesbarkeit oder Verständlichkeit. Im Wesentlich sind aber die Erweiterbarkeit und die Testbarkeit hervorzuheben, denn sie adressieren direkt die Steigerung der Performance und erleichtern die Weiterentwicklung der Software.

Vorgehen beim Refactoring

Erreicht werden die Ziele durch

• die Pflege und Verbesserung von Entwurf und Design. Dies verbessert sowohl die Übersichtlichkeit (bspw. durch die Modularisierung der Software) als auch die Erweiterbarkeit und die Testbarkeit.
• Die Optimierung des Codes – einerseits bspw. im Sinne der Verwendung von neuen, besseren, schnelleren oder robusteren Programmiersprachen, Bibliotheken, Widgets etc., und andererseits im Sinne von Lesbarkeit und Verständlichkeit.
• Die Beseitigung von Code-Smells wie bspw. Code-Duplikaten. Auch wenn die Behebung von konkreten Fehlern an sich kein primäres Ziel des Refactorings ist, werden im Zuge einer Software-Restrukturierung auch immer wieder Fehler im Code entdeckt. Natürlich sollten diese – je nach Schweregrad, Priorität und Aufwand – zügig beseitigt werden. Die Prozesse zum Bugfixing in Unternehmen variieren häufig.

Ein großer Vorteil ergibt sich aus den genannten Zielen und dem Vorgehen: Durch eine verbesserte Struktur lassen sich Erweiterungen in der Folge schneller realisieren. In anderen Worten: Die Entwicklungsgeschwindigkeit nimmt zu. Und damit sinken relativ auch die Kosten der Entwicklung.

Herausforderungen beim Refactoring

Als mögliche Herausforderungen bzw. Risiken oder Nachteile gelten:

• Die versehentliche Implementierung von ungewollten Änderungen oder Fehlern. Auch scheinbar kleine Änderungen können große Wirkungen entfalten. Unit-Tests können dieses Risiko senken.
• Der Aufwand könnte größer sein als ursprünglich erwartet bzw. eingeplant.
• Der Abstimmungsaufwand zwischen Entwicklern und/oder Softwarearchitekten könnte umfangreicher als erwartet sein.
• Der Kunde merkt nichts von dem Refactoring, da sich für ihn alles unverändert anfühlt und er keine neuen Features erhält.

Heutzutage ist Refactoring ein zentraler Bestandteil einer iterativen Softwareentwicklung. In diesem Zusammenhang wird gerne auch von kontinuierlichem – im Gegensatz zu punktuellem, einmaligen Ansätzen der Restrukturierung – gesprochen.

Unterschiedliche Meinungen gibt es in der Praxis der Softwareentwicklung beim Thema “kompromissloses” Refactoring; sollte also im Zuge einer agilen Vorgehensweise in jedem Sprint Zeit für Refactoring eingeplant werden und somit in der Folge vorübergehend auf neue Features verzichtet werden, oder gehen neue Kundenanforderungen bzw. Features vor? Auf Kent Beck, einem der Erfinder des Extreme Programmings, geht die Metapher der zwei Hüte zurück, wonach man als Entwickler lediglich einen Tut tragen kann:⁵

• Werden neue Funktionen hinzugefügt, darf existenter Code nicht verändert werden.
• Wird eine Software restrukturiert, darf keine neue Funktionalität hinzukommen.

Impuls zum Diskutieren:

Die Durchführung von Refactorings wird auch als eine von 23 Praktiken bei der Implementierung von Clean Code empfohlen. Wie wichtig ist Refactoring im Vergleich zu den anderen 22 Praktiken?

Hinweise:

Haben Sie Lust auf einen neuen Lieblings-Newsletter?

Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.

[1] Proceedings of Symposion on Object-Oriented Programming Emphasizing Practical Applications. Refactoring: An aid in designing application frameworks and evolving object-oriented systems.
[2] Martin Fowler: Refactoring: Improving the Design of Existing Code
[3] Meir “Manny” Lehmann: Laws of software evolution revisited
[4] Ward Cunningham: Debt Metaphor
[5] Die “Two Hats Metaphor” von Kent Beck findet sich ebenfalls in Martin Fowlers Refactoring-Buch.

William Opdyke promovierte 1992 zu dem Thema: Refactoring Object-Oriented Frameworks

Martin Fowler nennt eine Reihe von Refactorings wie bspw.

• Composing Methods,
• Moving Features between Objects,
• Organizing Data,
• Simplifying Conditional Expressions,
• Making Method Calls Simpler und
• Dealing with Generalization.

Hier finden Sie einen guten Überblick zu verschiedenen Refactorings.

Hier finden Sie ergänzende Informationen aus unserem t2informatik Blog:

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.