Refactoring

Juten Tach,

Beim Entwickeln und Betreuen von Flash Projekten habe ich in letzter Zeit viel über Refactoring nachgedacht. Das ist ja inzwischen auch in der Flash Programmierung ein hippes Wort, steht es doch in engem Zusammenhang mit genauso hippen Wörtern wie ‘Agile Programmierung’ oder auch ‘Extreme Programming’.

Auch wenn ich letzterem Konzept kritisch gegenüberstehe, bauen wir in unseren Projekten auch bisweilen unsere Klassen- und Paketstruktur um, wenn durch neue oder veränderte Anforderungen die alte Struktur anfängt arg zu zwicken.

Beim Refactoring tun sich ja nun zwei grosse Aufgaben vor einem Entwickler auf. Einmal muss man ja nun den Code umstellen. Da sind wir Flash Entwickler ja noch leider recht leidgeprüft, weil es klassische Refactoring Tools für Actionscript2.0 nicht gibt (ja ja, fdt, da bin ich auch schon gespannt drauf). Bleibt einem momentan nur das Experimentieren mit eigenen regulären Ausdrücken (gefährlich, wie ich schon festgestellt habe) oder eben alles per Hand (noch gefährlicher).

Allein deshalb kann man schon momentan zumindest nicht wirklich ‘Xtreme’ Flash entwickeln, weil da ist ja Refactoring an der Tagesordnung, es sei denn man verwechselt ‘extrem’ mit ‘extrem dreckig’.

Ein weiterer Punkt spielt für mich aber auch noch eine viel wichtigere Rolle, dass ja nach dem Refactoring der Code sich nach aussen noch genauso darstellen und verhalten sollte, wie zuvor. Ist ja klar, wenn ich eine API umstelle, die schon diverse Leute nutzen, und ich mache das Update nach dem Refactoring verfügbar, sollen all diese Leute ja ihren eigenen Kram nicht komplett umprogrammieren müsen. Ein Grund, warum es auch noch im Flash Player 8 den Befehl ‘add’ geben wird, obwohl das ja heutzutage als grosses ‘pfui’ gilt. (Nachtrag: Da hab’ ich mir doch tatsächlich eins rausgepickt, was in Flash 8 nun NICHT mehr unterstützt wird)

Hierbei kommt nämlich noch ein nicht ganz so hippes Wort ins Spiel und zwar ‘veraltet’, oder ‘deprecated’. Sehr oft, wenn man über Umstellungsmaßnahmen seines Codes nachdenkt, betrifft das auch das Verhalten des Codes nach aussen, etwas, was man ja eigentlich vermeiden will, wegen den vielen braven Programmierern, und die haben ja alle keine Zeit alles umzubauen und so weiter. Was also tun? Man stellt den Code so um, wie man es für nötig hält, belässt aber die alten Zugriffsmethoden samt ihrer vielleicht ‘veralteten’ Klassen zunächst bei, leitet diese aber dann meist intern auf die neuen Methoden und Klassen weiter. Irgendwann – je nach Wichtigkeit des Systems kann das Jahre dauern – wird dann das Alte entfernt und nur noch das Neue unterstützt.

Und da sollte einem eben zumindest ein wenig mulmig werden, bei dem Gedanken, den Code nach und nach mit ‘deprecated’ Teilen auszustaffieren. Flash selbst neben vielen anderen APIs und Frameworks zeigt dies ja auch. Im Flash Player tummeln sich dutzende ‘veraltete’ Funktionen, die ja nur noch aus Kompatibilitätsgründen mitgeschleppt werden. Sie alle sind Überbleibsel von Refactoring Maßnahmen. Man schleppt also Funktionen, Attribute, ganze Klassen mit sich rum, die wahrscheinlich zum Grossteil entkernt sind und nur noch auf neue Funktionalität weiterleiten. All diese Überbleibsel müssen trotzdem gepflegt und auf Bugs geprüft werden, denn es reicht ja nicht, dass sie da sind, sie müssen ja auch funktionieren.

Dadurch wird der Code gerade für codefremde Entwickler immer ein kleines Stück unverständlicher, weil man halt erstmal nachschauen muss, welches denn die ‘neue’ und welches die ‘veraltete’ Herangehensweise ist.

Noch komplizierter wird es, wenn sich mehrere Refactoring Schleifen irgendwann überdecken. Wenn sich in einer ‘neuen’ Klasse intern Funktionalität geändert hat, muss vielleicht die Weiterleitung der ‘veralteten’ Funktion auch nochmal geändert werden.

Refactoring sollte daher speziell bei Code, der von vielen Entwicklern genutzt wird, sehr behutsam umgestellt werden, wenn überhaupt. Dies ist z.B. bei Frameworks oder APIs meistens der Fall, weil solcher Code ja extra fü mehrere Entwickler entworfen wird. Für mich ein wichtiger Punkt, der mich kritisch auf “Xtreme Programming” schauen lässt.