DseWiki: CodeRefactoring

Veränderung (letzte Korrektur) (Änderung, Autor, Normalansicht)

Verändert: 34c34

Die Beispiele hier und in

http://www.refactoring.com/ sind stark auf die SpracheJava ausgerichtet, das scheint aber eher Zufall als erklärte Absicht - ich refaktorisiere seit Jahren erfolgreich in der SpracheCpp und sehe sogar Refaktorisierungen, die für einzelne Sprachen unterschiedlich relevant sind. ZusammengehörigeVariablenKapseln ist in SpracheCpp allermeistens angebracht, und muss nicht mal Overhead bedeuten. WolfPeuker

Die Beispiele hier und in

Verändert: 37c37,38

KategorieRefactoring KategorieXp KategorieZitat

"The fact that you know more today, and are more capable today, is good news about today, not bad news about yesterday." -- RonJeffries auf der XpMailingliste

Allgemein gesprochen, handelt es sich hierbei um eine Technik zur Veränderung des Designs von Code, nachdem er geschrieben wurde. Ziel des Refaktorisierens ist es dabei, das System so zu verändern, dass es sein externes Verhalten beibehält.
Um dieses Ziel zu erreichen und dabei auftretende Fehler zu minimieren, ist eine disziplinierte Vorgehensweise notwendig, bei der in sehr kleinen und einfachen Schritten gearbeitet wird. Integraler Bestandteil dieser Arbeitsweise ist die Ausführung von existierenden UnitTests, mit deren Hilfe man das Risiko solcher Veränderungen stark reduzieren kann. Sollte man keine UnitTests zur Hand haben, ist es mitunter ratsam, nicht zu refaktorisieren. Wer sich jedoch vor einer Refaktosierung scheut, weil er keine UnitTests für die entsprechenden Implementierungen hat, sollte sich (konsequenterweise) auch jede sonstige Änderung am Quelltext verkneifen. Kurrioserweise aber werden in der Praxis gerade solche Einbauten ausgeführt, die das Verhalten ändern sollen, wohingegen sich gleichzeitig vehement gegen jede vorbereitende Refaktorisierung mit dem Argument gewehrt wird, man könne die Äquivalenz der Umformung ja nicht testen.

Ursprünglich im Bereich der FrameworkEntwicklung? unter SpracheSmalltalk aufgekommen, hat sich GnadenlosesRefaktorisieren zu einem essentiellen Bestandteil von ExtremeProgramming entwickelt. Dieser Ansatz, das Design jeder Zeit im laufenden Entwicklungsprozess ändern zu können, macht das Treffen großer Designentscheidungen vorab unnötig.

Im Allgemeinen wird CodeRefactoring benutzt, um das Design eines Systems bezüglich Wartbarkeit und Erweiterbarkeit zu verbessern. Man kann aber die Techniken des CodeRefactoring auch nutzen um z.B. die Performance oder den Speicherbedarf eines Systems zu optimieren (wenn man diese Aspekte großzügig aus dem "externen Verhalten" ausklammert).

Wichtiges Hilfsmittel für das Arbeiten mit dieser Methode sind ohne Zweifel die allmählich auf den Markt kommenden RefactoringBrowser.

CodeRefactoring ist für Quelltext, was ÄquivalenteUmformungen? für Gleichungen sind. Es läuft nicht darauf hinaus, die beste Formulierung an sich zu finden, sondern die im vorliegenden Zusammenhang nützlichste. Genau wie eine mathematische Gleichung nicht immer dadurch nach einer Unbekannten umgestellt werden kann, dass man eine bestimmte Faustregel wie "Löse alle Klammern auf" befolgt, kann eine Refaktorisierung wie ZusammengehörigeVariablenKapseln nicht immer gut sein. Tatsächlich haben wir es hier mit einem Paar von entgegengesetzten Refaktorisierungen zu tun:

VariablenAlsKlasseBündeln? <--> KlasseInVariablenAuflösen?

Bei dieser Bezeichnungsweise kann man leicht zustimmen, dass das "Zusammengehören" eine Frage des Blickwinkels und damit vielleicht des Zeitpunkts der Betrachtung ist. Sie wird im Laufe der Zeit unterscheidlich beantwortet werden. Hier aber wird ein wesentliches Ziel von CodeRefactoring deutlich: Design nicht mehr als unantastbar ansehen zu müssen.

Siehe

Diskussion

Die Beispiele hier und in http://www.refactoring.com/ sind stark auf die SpracheJava ausgerichtet, das scheint aber eher Zufall als erklärte Absicht - ich refaktorisiere seit Jahren erfolgreich in der SpracheCpp und sehe sogar Refaktorisierungen, die für einzelne Sprachen unterschiedlich relevant sind. ZusammengehörigeVariablenKapseln ist in SpracheCpp allermeistens angebracht, und muss nicht mal OverHead? bedeuten. WolfPeuker

KategorieRefactoring KategorieXp KategorieZitat