Martin Fowler: "Refactoring ist heute relevanter als vor zwanzig Jahren"

Inhaltsverzeichnis

heise Developer: Herr Fowler, die meisten unserer Leser kennen Sie, aber erzählen Sie doch bitte, wie Sie mit Softwareentwicklung in Berührung kamen und was Sie zum Thema Refactoring brachte.

Martin Fowler: Mein erster Kontakt mit Programmieren war eher zufällig: Ich fand das Thema an der Universität und bei meinen ersten Jobs interessant. Ich hatte das Glück, mit den Leuten in Kontakt zu kommen, die in den 1980er-Jahren die Idee des objektorientierten Programmierens verbreiteten. Den Weg schlug ich dann ein und traf dabei auf Kent Beck und Ward Cunningham.

Kent war es dann, der mir das Thema Refactoring näher brachte. Wir arbeiteten zusammen an einem Projekt, das man als Geburt des Extreme-Programming-Ansatzes bezeichnen kann. Kent war ein großer Verfechter von Refactoring, und ich erkannte, wie effizient die Technik war. Allerdings war Refactoring damals recht unbekannt, und lediglich ein paar Leute in der Smalltalk-Community machten Gebrauch davon.

Da Kent mit dem ersten Extreme-Programming-Buch beschäftigt war, habe ich den Plan gefasst, Refactoring einem breiteren Publikum vorzustellen. Das war in den späten 1990er Jahren.

heise Developer: Die erste Auflage Ihres Buchs löste vor zwanzig Jahren eine große Resonanz aus. Wäre das noch genauso, wenn Sie das Thema heute frisch auf den Tisch bringen würden? Wie hat sich das Thema und dessen Wahrnehmung in den vergangenen zwei Jahrzehnten verändert?

Fowler: Ich glaube, es wäre weitgehend ähnlich. Die Kerntechnik ist immer noch dieselbe: Sie machen eine Reihe kleiner, Transformationen, die das Verhalten des Programmcodes nicht verändern. Beim Aneinanderreihen zahlreicher Transformationen, ergibt sich in Summe eine ziemlich große Änderung, auch wenn jede einzelne sehr klein ist. Auch die Art, wie sich Refactoring in den Entwicklungsprozess integrieren lässt, ist heute dieselbe wie vor zwanzig Jahren.

Aber es ist in den letzten Jahren einiges passiert, was die Art beeinflusst, wie sich Refactoring nutzen lässt. So ist das Interesse an Methoden gewachsen, die gut zum Refactoring passen wie das zunehmende Testing und die agile Revolution. Daher ist Refactoring heute relevanter als vor zwanzig Jahren.

Darüber hinaus bringen einige Programmiersprachen eine gute automatisierte Toolunterstützung. Java und C# stechen bei den Werkzeugen besonders positiv hervor.

heise Developer: Würde Sie sagen, dass sich die die Entwickler in den letzten zwanzig Jahren maßgeblich verändert haben?

Fowler: Ja, sie setzen auf kürzere Entwicklungszyklen und Rapid-Development-Werkzeuge. Außerdem sehen Sie Testing nicht mehr als eine externe Aufgabe, sondern als Bestandteil des Entwicklungsprozesses. Diese Änderungen helfen beim Refactoring-Prozess.

Monolithen, Microservices und Open Source

heise Developer: Wie wirkt sich der Trend von Monolithen hin zu Microservices aus?

Fowler: Dabei handelt es sich ja um einen jüngeren Trend, der nicht unbedingt so große Auswirkungen hat. Refactoring betrifft monolithische Anwendungen ebenso wie Microservices.

Wobei – das ist nicht ganz fair: Microservice-Architekturen haben insofern eine Auswirkung, als es schwieriger wird, Änderungen über die Grenzen von Microservices vorzunehmen. Bei Monolithen lassen sich solche Veränderungen geradliniger durchführen. Andererseits ist es deutlich einfacher, Transformationen innerhalb eines kleinen Service durchzuführen, schon aufgrund der kleineren Codebasis.

Unter dem Strich spielt das aber eine geringere Rolle als der allgemeine Zustand des Codes. Eine Codebasis, die noch keinem Refactoring unterzogen wurde, lässt sich schwerer transformieren, weil sie schlicht unordentlich ist. Wenn Entwickler regelmäßig automatische Tests integrieren, ist das Refactoring potenziell einfacher. Im Vergleich zu solchen Unterschieden spielt das Gegenüber von Monolith und Microservices eine verhältnismäßig kleine Rolle.

heise Developer: Wirken sich veränderte Teamstrukturen wie DevOps und integriertes Testing auf das Refactoring aus?

Fowler: Die wichtigste Änderung ist, dass Testing näher am Softwareentwicklungsprozess ist. Das ist unabdingbar für ein gutes Refactoring. DevOps spielt für Refactoring eine kleinere Rolle als für Continuous Delivery (CD). Freilich existieren Synergieeffekte zwischen Refactoring und CD, da eine saubere Codebasis den Delivery-Prozess positiv beeinflusst.

Continuous Integration (CI) hilft wiederum beim Refactoring aufgrund der kurzlebigen Entwicklungszyklen. Langlebige Branches blockieren im Umkehrschluss den Prozess.

heise Developer: Sehen Sie Unterschiede zwischen firmeninternen und Open-Source-Projekten? Vor zwanzig Jahren spielten Letztere kaum eine Rolle, während sie heute eine große Bedeutung haben. Sind sie eventuell chaotischer?

Fowler: Das ist schwer zu sagen. Grundsätzlich gelten dieselben Regeln für firmeninternen und Open-Source-Code. Der Unterschied ist meines Erachtens gar nicht so groß, und es gibt reichlich Chaos in Closed-Source-Projekten. Allerdings bekommen deutlich weniger Leute das Chaos zu sehen als bei öffentlichem Code.

heise Developer: Denken heutige Entwickler besser voraus als früher? Man hört häufig, dass damals das Wichtigste war, dass der Code lief und beispielsweise in den 1970er-Jahren kaum jemand daran dachte, dass der Code den Jahrtausendwechsel erleben würde. Planen Entwickler inzwischen langfristiger?

Fowler: Ehrlich gesagt bin ich da nicht so sicher. Meine Erfahrung ist aber auch nicht repräsentativ, da ich in einer Art Blase lebe – die Leute bei ThoughtWorks und ich haben oft andere Ansichten als die meisten Entwickler in typischen Alltagsprojekten.