Wann Sie nicht refaktorisieren sollten

Refactoring ist Teil der Arbeit eines Softwareentwicklers. Eine allgemeine Faustregel, die ich immer verwendet habe, lautet: Wenn Sie Code sehen, der riecht (z.B. Duplikation), sollten Sie refaktorisieren. Aber gilt diese Regel immer? Gibt es Situationen, in denen Sie nicht refaktorisieren sollten? Und wenn ja, wie erkennen Sie diese Situationen?

Letzte Woche arbeitete ich an einer bestimmten Aufgabe, nennen wir sie Aufgabe X, bei der ich einen Dienst mit einer unklaren Schnittstelle und einer stinkenden Implementierung verwenden musste. Nachdem wir uns mit dem Rest des Teams beraten hatten, beschlossen wir, diese bestimmte Methode des Dienstes zu refaktorisieren, damit sie klarer wird und Code-Duplizierung in dieser Methode entfernt wird. Während der Umstrukturierung bemerkte ich, dass auch die anderen Methoden des Dienstes unklar waren und doppelten Code enthielten, also begann ich auch diese zu überarbeiten. Um zu beweisen, dass der Dienst immer noch funktioniert, brauchte ich ein gutes (automatisiertes) Regressionstestset. Es handelte sich um Produktionssoftware, und ich wollte sicherstellen, dass ich mit meiner Umstrukturierung nichts kaputt mache. Leider gab es kein automatisiertes Regressionstestset für alle Methoden des Dienstes. Während ich also kurz davor war, ein komplettes automatisiertes Regressionstestset für den gesamten Dienst zu erstellen, das unter anderem aus dem Mocking eines Webservice-Aufrufs bestanden hätte, erinnerte ich mich an etwas über das Rasieren von Yaks. Warum sollte ich ein automatisiertes Testset für den gesamten Dienst erstellen, während ich eigentlich an Aufgabe X arbeite? Bevor die Sache aus dem Ruder läuft, habe ich beschlossen, die anderen Methoden des Dienstes nicht zu refaktorisieren, die Code-Duplizierung an Ort und Stelle zu lassen und mich auf die Refaktorisierung (und das Testen) dieser einen Methode des Dienstes zu beschränken. Warum habe ich beschlossen, nicht zu refaktorisieren?

• Das Refacoring hatte keinen direkten Zusammenhang mit der Aufgabe X, an der ich gerade arbeitete
• Es war kein automatisiertes Regressionstestset verfügbar
• Der Rest des Teams stimmte zu, keine Überarbeitung vorzunehmen.
• Das komplette Refactoring (inkl. Testen) hätte mehr als einen Tag in Anspruch genommen (mindestens eine Woche).
• Eine gute Praxis bei der agilen Modellierung ist, nur dann zu aktualisieren, wenn es weh tut. Ich denke, das gilt auch, wenn es um das Refactoring von Code geht. Ich habe die anderen Methoden des Dienstes nicht verwendet und deshalb hat es mir nicht weh getan

Mit Schmerzen im Herzen musste ich den stinkenden Code in Ruhe lassen und mit der Implementierung von Aufgabe X fortfahren. Bedeutet das, dass der Dienst weiterhin stinkt? Ich denke, das hängt von den zukünftigen Funktionen ab, die wir implementieren werden, und davon, ob wir denselben Dienst noch einmal benötigen. Und wenn wir das tun, werden wir wahrscheinlich die gleichen Regeln anwenden wie in dieser Situation. Lars