© ringo, Photocase.com

Bestehende Software zerlegen und aus den Einzelteilen nach genauer Inspektion etwas Neues schaffen ist ein effektiver Entwurfsprozess. Doch ist es ratsam, dabei nicht zu übertreiben .

Wer vor 1975 geboren wurde, kennt sie vielleicht noch vom Sperrmüll: Viele alte röhrenbetriebene Radiogeräte mussten in den 1970ern erst Transistorradios und später Geräten mit integrierten Schaltkreisen weichen. Wer sich also für Technik interessierte, nahm mit Freude die Geräte auseinander, um zu ergründen, wie sie wohl funktionieren mochten. Eine Röhre bestand meist aus einem kleinen Glühdraht, der negativ geladene Elektronen aussandte. Die zog eine positiv geladene Anode mit ihrem elektrischen Feld an. Ein Steuergitter regelte den Strom der elektrischen Teilchen – letztlich arbeitete eine Röhre funktional nicht viel anders als ein Transistor, der Ströme regelt und verstärkt.

Anders als die späteren Transistoren und verlöteten ICs saßen die Röhren auf Sockeln, sodass sich theoretisch ein defektes Gerät mit anderen Austauschelementen reparieren oder erweitern ließ. Das hauchte einigen Radios und Fernsehgeräten neues Leben ein, erforderte aber einige Sachkenntnis, denn bekanntlich ist das Zusammenbauen viel schwieriger als das Auseinandernehmen.

Das haben diese Technikrelikte auch mit moderner Software gemein. Überhaupt lohnt sich ein Vergleich des Refactoring von damals mit heute. Das spielerische Auseinandernehmen diente durchaus dem Zweck, mehr über die inneren Zusammenhänge zu lernen. Auch heute berichten viele Entwickler, dass sie ihre wichtigsten Erkenntnisse aus dem Studium von bestehendem Code und mehr oder minder erfolgreichen Experimenten mit ihm gewonnen haben.

So half Linus Torvalds sicher das Studium des Minix-Kernels mit all seinen Vor- und Nachteilen dabei, sein eigenes Konzept zu entwickeln. Er hatte sich schließlich keine vollständige Spezifikation im Kopf zurechtgelegt, wie ein Betriebssystemkern aussehen sollte, sondern ging inkrementell daran, bestehende Probleme besser zu lösen als vorher. Insofern diente das Anschauungsobjekt selbst als eine Art Feinspezifikation.

Übermut tut selten gut

Wer den Gedanken des Wiederaufbaus jedoch überdreht, neigt dazu, Probleme zu lösen, die noch gar nicht aufgetreten sind. Von vielen ist nicht einmal abzusehen, ob sie jemals auftreten werden. Am besten zeigt sich das bei der Übergeneralisierung. Das ergibt abstrakte APIs, die sowohl eine Mondlandung als auch den Kauf einer Fahrkarte ermöglichen. Oft sind sie so unkonkret, dass andere Entwickler keine rechte Vorstellung erhalten, wie sie einzusetzen sind.

LDAP ist so ein Fall: Das Protokoll ist so generisch, dass Anwendungen Probleme haben, Authentifikationsdaten von einem Programm zum anderen auszutauschen [1]. Die Open-Office-Schnittstelle UNO [2] ist so mächtig, dass sich kaum ein Unternehmen an sie herantraut. Beim Schlüsseltauschprotokoll IKE, einem Teil von IPsec, wollte man flexibel bleiben – mit dem Ergebnis, dass immer noch in Einzelfällen ein Partner den anderen nicht versteht [3]. Aber das muss nicht sein, denn mit dem richtigen Augenmaß gelingt auch ein Refactoring.