13.2 Warum weigern sich Entwickler, ihre eigenen
13.2.2 Refaktorisieren, um kurzfristige Ziele zu erreichen
Es ist relativ leicht, die mittel- bis langfristigen Vorteile des Refaktorisierens zu be- schreiben. Viele Organisationen werden aber von Investoren und anderen zuneh- mend nach kurzfristigen Leistungsmerkmalen bewertet. Kann das Refaktorisieren kurzfristig einen Unterschied machen?
Das Refaktorisieren wird seit mehr als zehn Jahren erfolgreich von erfahrenen ob- jektorientierten Entwicklern angewandt. Viele dieser Entwickler verdienten sich ihre Sporen in der Smalltalk-Kultur, in der klarer und einfacher Code geschọtzt und die Wiederverwendung gefửrdert wird. In einer solchen Kultur investieren Programmierer Zeit, um zu refaktorisieren, da es das jeweils Richtige ist. Die Spra- che Smalltalk und ihre Implementierungen machen das Refaktorisieren in einer Weise mửglich, die es in den meisten frỹheren Sprachen und Software-Entwick- lungsumgebungen nicht gab. Viel der frühen Smalltalk-Programmierung erfolgte in Forschungsgruppen wie Xerox, PARC oder kleinen Programmierungsteams in
technologisch führenden Firmen und Beratungsunternehmen. Die Wertvorstel- lungen dieser Gruppen unterschieden sich von denen der kommerziellen Soft- ware-Entwicklungsgruppen. Martin Fowler und ich sind uns bewusst, dass das Re- faktorisieren nur dann in groòem Stil eingesetzt werden wird, wenn mindestens einige seiner Vorteile kurzfristig wirksam werden.
Unsere Forschungsgruppe3,9,12-15 hat verschiedene Beispiele beschrieben, die zei- gen, wie Refaktorisierungen so mit Erweiterungen eines Programms verbunden werden kửnnen, dass sowohl kurz- als auch langfristige Vorteile realisiert werden.
Eines unserer Beispiele ist Choices, ein Dateisystem-Framework. Ursprünglich im- plementierte dieses Framework das BSD (Berkeley Software Distribution) Unix- Dateisystemformat. Spọter wurde es um Unterstỹtzung fỹr UNIX System V, MS- DOS, persistente und verteilte Dateisysteme erweitert. System-V-Dateisysteme ha- ben viele Ähnlichkeiten mit BSD-Unix-Dateisystemen. Der Ansatz der Entwickler bestand darin, zunọchst Teile der BSD-Unix-Implementierung zu klonen und die- sen Klon dann anzupassen, um System V zu unterstützen. Diese Implementierung funktionierte, es gab aber eine Fülle redundanten Codes. Nachdem die Frame- work-Entwickler neuen Code hinzugefügt hatten, refaktorisierten sie den Code, indem sie abstrakte Oberklassen erstellten, die das beiden Unix-Dateisystem-Imp- lementierungen gemeinsame Verhalten enthielten. Gemeinsame Felder und Me- thoden wurden in die Oberklassen verschoben. In Fọllen, in denen die entspre- chenden Methoden für die beiden Dateisystem-Implementierungen nahezu, aber nicht ganz, identisch waren, wurden neue Methoden in den Unterklassen defi- niert, um die Unterschiede aufzunehmen. In den Originalmethoden wurden diese Codesegmente durch Aufrufe der neuen Methoden ersetzt. Wenn die Me- thoden identisch waren, wurden sie in eine gemeinsame Oberklasse verschoben.
Diese Refaktorisierungen boten mehrere kurz- und mittelfristige Vorteile. Kurz- fristig mussten Fehler, die in der gemeinsamen Codebasis beim Testen gefunden wurden, nur an einer Stelle korrigiert werden. Die Gesamtgrửòe des Codes war klei- ner. Das Verhalten, das für ein bestimmtes Dateisystem spezifisch war, wurde klar von dem Code getrennt, der beiden Dateisystemen gemeinsam war. Das machte es leichter, Verhalten zu finden und zu bereinigen, das spezifisch für ein Dateisys- temformat war. Mittelfristig waren die Abstraktionen, die sich beim Refaktorisie- ren ergaben, oft für die Definition nachfolgender Dateisysteme nützlich. Zugege- benermaòen mag das, was zwei Dateisystemformaten gemeinsam ist, nicht auch noch einem dritten ganz genau entsprechen, aber die vorhandene Basis gemein- samen Codes ist ein guter Ausgangspunkt. Nachfolgende Refaktorisierungen kửn- nen herausarbeiten, was wirklich gemeinsam ist. Das Framework-Entwick- lungsteam stellte fest, dass es mit der Zeit weniger Aufwand wurde, schrittweise
die Unterstützung für ein neues Dateisystemformat hinzuzufügen. Obwohl die neueren Formate komplexer waren, erfolgte die Entwicklung mit weniger erfahre- nem Personal.
Ich kửnnte weitere Beispiele fỹr Kurz- und langfristige Vorteile aus Refaktorisie- rungen anführen, aber das hat Martin Fowler bereits getan. Lassen Sie mich statt diese Liste zu verlọngern, eine Analogie ziehen, die einfach zu verstehen und vie- len von uns teuer ist: unsere kửrperliche Gesundheit.
In vielerlei Hinsicht ist Refaktorisieren wie Sport treiben und sich vernünftig er- nọhren. Viele von uns wissen, dass sie mehr Sport treiben und sich ausgewogener ernọhren sollten. Einige von uns leben in Kulturen, die dieses Verhalten stark fửr- dern. Einige von uns kửnnen eine Zeitlang ohne sichtbare Effekte ohne diese ge- sunden Verhaltensweisen auskommen. Wir kửnnen immer Ausreden finden, aber letztendlich betrügen wir uns selbst, wenn wir auf Dauer dieses gesunde Verhal- ten missachten.
Einige von uns motiviert der kurzfristige Erfolg des Sporttreibens und einer gesun- den Ernọhrung wie grửòere Energie, hửhere Flexibilitọt, grửòere Selbstachtung usw. Fast alle von uns wissen, dass diese kurzfristigen Erfolge sehr real sind. An- dere wiederum sind nicht hinreichend hierfür motiviert, bis sie einen kritischen Punkt erreichen.
Ja, einige Vorbehalte muss man machen; so sollte man einen Experten konsultie- ren, bevor man sich auf ein Programm einlọsst. Im Fall von Sport und Ernọhrung sollten Sie einen Arzt konsultieren. Im Fall des Refaktorisierens sollten Sie Res- sourcen wie dieses Buch und die Artikel, die an anderer Stelle in diesem Kapitel genannt werden, zu Rate ziehen. Personal mit Erfahrungen im Refaktorisieren kann Ihnen gezieltere Unterstützung geben.
Verschiedene Menschen, die ich getroffen habe, sind Vorbilder in Bezug auf Fit- ness und Refaktorisieren. Ich bewundere ihre Energie und ihre Produktivitọt. Ne- gativbeispiele zeigen sichtbare Zeichen der Vernachlọssigung. Ihre Zukunft und die der Softwaresysteme, die sie produzieren, mag nicht rosig sein.
Das Refaktorisieren kann kurzfristig Vorteile bieten und zu Software führen, die einfacher zu ọndern und zu warten ist. Das Refaktorisieren ist eher ein Mittel als ein Ziel. Es ist Teil eines breiteren Kontexts, in dem Programmierer und Program- mierteams ihre Software entwickeln3.