t2informatik » Wissen kompakt » Refactoring

Refactoring

Die Restrukturierung einer Software

Softwareentwicklung ist ein kontinuierlicher Prozess. Kaum hat ein Unternehmen eine neue Version einer Software veröffentlicht, stellen Anwender neue Anforderungen für neue Versionen. Im Laufe der Zeit wächst der Funktionsumfang, doch je umfangreicher und älter eine Software und ihre Architektur werden, desto schwieriger wird die Weiterentwicklung. Hier hilft das sogenannte Refactoring. Es bezeichnet die – manuelle oder automatisierte – Restrukturierung einer Software (meist) unter Beibehaltung des Funktionsangebots. 

Der Begriff Refactoring wurde erstmals 1990 von den US-amerikanischen Informatikern Ralph Johnson und Dr. William Opdyke erwähnt. Durch Marin Fowlers Buch „Refactoring: Improving the Desgin of Existing Code“, an dem u.a. auch Dr. Opdyke mitgewirkte, verbreitete sich der Begriff und die Techniken des Refactorings sehr schnell unter Softwareentwicklern. 

Grundsätzlich adressiert Refactoring drei wesentliche Aspekte:

  • 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 der Verständlichkeit des Codes.
  • Die Beseitigung von Code-Smells wie bspw. Code-Duplikaten und das Beheben von konkreten Fehlern. Obwohl Bugfixing an sich kein primäres Ziel der Restrukturierung ist, ermöglicht die detaillierte Auseinandersetzung mit dem Code das Auffinden und Beseitigen von Fehlern. Auch Redundanzen lassen sich vermeiden.

Ein weiterer Aspekt ergibt sich aus den drei genannten Vorteilen: Durch eine verbesserte Struktur lassen sich Erweiterungen in der Folge schneller realisieren. In anderen Worten: Die Entwicklungsgeschwindigkeit nimmt zu.

Refactoring - Wissen kompakt - t2informatik

Als mögliche 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, den Erfinder des Extreme Progammings, geht die Metapher der zwei Hüte zurück: Werden neue Funktionen hinzugefügt, darf existenter Code nicht verändert werden. Wird eine Software restrukturiert, darf keine neue Funktionalität hinzukommen.

Hinweise:

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.

Einen guten Überblick finden Sie hier  »

Einen Blogbeitrag zum Thema Unit-Testing finden Sie hier  »

 

“Das Fachwissen zu Softwarearchitekturen, die Expertise in der Softwareentwicklung und die sehr flexible Arbeitsweise waren ideal für uns.“

„Ihren Blog lese ich schon lange und mit großer Freude. Systematisch, auf den Punkt und ansprechend.“

Share This