Refactoring – Was soll der Kram eigentlich ?

Marcus Schönrock/ Juli 5, 2020

Fangen wir erstmal mit den Basics an.

Was ist Refactoring ?

Refactoring ist kurz gefasst das Überarbeiten bestehendes Codes ohne das Ziel ein neues Feature zu implementieren. Es kann zu unterschiedlichen Zeitpunkte in einem Software-Projekt angewendet werden. Im Idealfall ist es ein Teil der täglichen Arbeit bei jedem Team-Mitglied und ermöglich es so die Software Qualität durch das inkrementelle Verbessern stetig hoch zu halten. Martin Fowler z.B. beschreibt in einem Talk 2014 zum Thema Refactoring, das es mehrere Unterschiedliche Arten gibt und wann diese angewendet werden können. In der folgenden Tabelle habe ich seine Varianten versucht mit meinen Worten zu beschreiben.

Art des RefactoringBeschreibung
TDD - RefactoringDer Zyklus "Red"-"Green"-"Refactor" lässt sich sehr gut während des Test-Driven-Development umsetzen. Das Feature wird durch einen/mehrere Test(s) beschrieben, die zu Beginn der Entwicklung scheitern (Rot sind), diese werden dann nach und nach mit Code in den Grünen Zustand überführt. Anschließend wird der geschriebene Code kritisch überprüft, welche Verbesserungen hier noch sinnvoll sind, das ist dann das Refactoring. Durch das Bearbeiten wird dann temporär der Rot-Zustand vom Test wieder herbei geführt und der Zyklus beginnt erneut.
Refactoring gehört gezielt zum Implementierungspfad.
Boyscouting - Refactoring
[Litter Pickup-Refactoring]
Während des Implementieren eines Features "stolpert" man über Code, der sicher durch einfache Modifikation, z.B. Entkopplung der Funktion für das Feature wieder verwenden lässt oder andere kleine Bugs fallen einem während der Bearbeitung auf. Wenn die notwendigen Änderungen dann während der Implementierung umgesetzt werden, kann man hier von Boyscouting reden.
Man verlässt den eigentlichen Implementierungspfad nur minimal.
"Wtf, was ist das ?" - Refactoring
[Comprehension Refactoring]
Auch hier wird eher über das Problem "gestolpert" als das man aktiv danach gesucht hätte. Es wird eine Funktion oder Code-Stelle erreicht, die auch nach kurzem oder langem Überfliegen nicht vollständig nachvollziehbar ist. Diese Stelle gilt dann auch als Problem, wenn hier kein Fehler im Code vorliegt. Der Code sollte nach "Clean Code" Regeln weitestgehend selbsterklärend sein und Code der diesen Ansprüchen nicht ausreichend genügt, sollte dahin gehend angepasst werden, das dieser dann mit "gutem Gewissen" der Nachwelt hinterlassen werden kann. Da hier explizit von dem Pfad der Implementierung abgewichen wird, sollten vor diesen Änderungen alle featurerelevanten Änderung vollendet oder zurück gesetzt werden, bevor man sich dieser Code-Stelle widmet.
"Das kann ich jetzt besser" - Refactoring
[We should have done this way]
Wer kennt es nicht, seinen grauenvollen Code von vor ein paar Monaten/Jahren. Da wir alle verantwortungsvolle, sich weiterbildende Softwareentwicklerinnen (ich will nicht dieses wissenschaftliche "Gendern" betreiben, daher sind wir heute alle Frauen :-P) sind und daher ständig neue Dinge lernen, wissen wir heute mehr Dinge als gestern und können daher feststellen, dass das Alte nicht mehr unseren neuen Ansprüchen genügt. Daher sollte mit diesem Wissen dann auch den Code an unsere heutigen Ansprüche angepasst werden und entsprechend überarbeitet werden. Auch hier gilt, wie bei dem "Wtf, was ist das ?", dass wir werden den Pfad der Implementierung verlassen und daher vor den größeren Änderungen die Qualität des Features sicherstellen müssen.
Geplantes RefactoringHier steht es das Hasswort der Agilen Welt, der "PLAN". Nein, Spaß beiseite, ein geplantes Refactoring ist nicht wirklich, dass was eine gute Software Entwicklung braucht. Denn die Tätigkeit des Refactoring sollte sich eher auf die anderen Themen in dieser Tabelle konzentrieren. Nur leider ist in manchen Fällen ein geplantes (größeres) Refactoring der letzten Auswege. Da ich besonders diese Situation kenne, kann ich euch sagen, es gibt diese Art des Refactoring und es macht keinen Spaß. Es muss hier dann um Zeit verhandelt werden, die in der ersten Betrachtung keinen Mehrwert bietet. Hier wird das Refactoring als eigentliches Entwicklungsziel betrachtet und dann gezielt für eine bestimmten Zeitraum ausgeführt, das macht dann auch die Schwäche aus, es kann einmalig bleiben und ist daher weniger effektiv als die anderen inkrementellen Methoden.
Doch wie kann es zu so einer Situation kommen? Das kann äußert vielschichtig sein. Es kann von der Planung, die Technologie, technische Schulden bis hin zu fehlender Erfahrung alles dabei sein, was ihr euch vorstellen könnt.
In meinem Fall ist es z.B. die gewachsene Architektur der Software, die Entwicklungsprozesse im Medizinprodukte-Kontext, die alte Technologie und das fehlenden Wissen zu Test-Frameworks für die alte Technologie.

Nachdem ich hier hoffentlich Martin Fowler würdig einmal mein Verständnis der von Ihm genannten Refactoring Methoden hier zusammen gefasst habe, denke ist das hat zu mind. das was ist Refactoring einigermaßen beantwortet.
Für alle diese Verfahren ist es sinnvoll ein Sicherheitsnetz in Form von Tests zu haben. Das kann von einer kompletten Testautomatisierung mit CI-Pipeline bis hin zu einem „Golden-Master“-Test ausreichen.
Kurzer Exkurs: Der Golden-Master-Test Tests greift hauptsächlich bei Software die keine Tests besitzen und man daher nur den Verlauf der gesamten Komponenten prüft und nicht nur eine einzelne Einheit der Komponente.

Aber die Frage war doch „Was soll der Kram eigentlich ?
Ich bereue jetzt schon das Wort „Kram“ im Titel 😀 Denn es ist alles andere als Kram, es ist eine Methode wenn nicht sogar ein Mindset was gute und schlechte Entwicklerinnen von einander trennt und ja ich bleibe heute dabei das wir alle weiblich sind.

Also wieso sollte wir nun Refactoring betreiben ? Tja, ich glaube bei meiner ersten groben Fassung bin ich sehr in die Richtung von TDD – Refactoring unterwegs gewesen und habe dann darüber geschrieben das es manchmal gar nicht so sinnvoll wäre alles zu refactoren, was einem vor die Tastatur kommt. Doch dann habe ich mir während der Recherche noch mal die Meinung von Martin Fowler in seinem Talk dazu angehört, ich kann euch den echt nur Empfehlen 😉
Ja, ich denke weiterhin, dass es nicht sinnvoll ist alles zu refactoren, denn es gibt nun mal Code, der wird nicht mehr oft bzw. gar nicht angefasst. Dann sollte er auch nicht nur um des Refactoringswillen bearbeitet werden, denn jede Bearbeitung kann auch zu Fehler führen. Und mit dem Gedanken der Fehler kann ich auch den Bogen zu dem Grund bzw. dem Sinn hinter Refactoring spannen.
Wir alle arbeiten nicht 100% Fehlerfrei und keiner von euch wird mir das Gegenteil beweise können. Es ist „normal“ Fehler zu machen und Refactoring ist eine Methode mit diesen Fehlern umzugehen und diese Stück für Stück zu beheben. Aus dem Grund der „Normalität“ von Fehlern ist es für mich nicht alleine eine Methode, sondern ein Mindset einer guten Softwareentwicklerin. Es musst nicht darüber diskutiert werden, wer? wann? wieso? den Fehler, das Hindernis oder was auch immer gerade Refactor wird geschaffen hat, sondern es ist da und muss behoben werden. Und wenn ihr euch in dem Moment dazu in der Lage fühlt, ist es auch sinnvoll das zu tun.

Das fühlt sich gerade mega pathetisch an, aber ich empfinde es so. So am Rande, das ist auch einer der Gründe warum der Blog so heißt. Es ist nämlich normal Fehler zu machen, die Kunst besteht dann darin mit diesen Fehlern sinnvoll umzugehen und sich damit weiterzuentwickeln.

Und wenn ihr (Code) refactored ist es genau das was ihr tut. Ihr entwickelt euch und die Software weiter.

Wie refactored ihr so ?

Ergebnisse ansehen

Loading ... Loading ...
Share this Post

Hinterlasse einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*
*