Führen Sie Refactoring in kleinen Schritten durch?

Question

Nachdem ich Fowlers "Refactoring" eine Weile gelesen habe, ertappe ich mich immer noch oft dabei, dass ich denke: "Ich hätte das in kleineren Schritten machen sollen." -- auch wenn ich meinen Code nicht kaputt gemacht habe.

Refactoring in kleinen Schritten ist sicher, kostet aber Zeit. Es ist ein Kompromiss zwischen Geschwindigkeit und Risiko - ich versuche, die Art und Weise, wie ich refaktorisiere, strategisch zu wählen.

Dennoch: Die meiste Zeit mache ich Refactorings in größeren Schritten. Wenn ich einen Teil von Fowlers "Mechanics"-Abschnitt nehme und vergleiche, wie ich arbeite, stelle ich vielleicht fest, dass ich oft zwei oder fünf Schritte auf einmal vorwärts springe. Das heißt nicht, dass ich ein Refactoring-Guru bin. Mein Code bleibt vielleicht 5 bis 60 Minuten lang kaputt oder unkompilierbar.

Führen Sie Refactoring in kleineren Schritten durch und versuchen Sie, unversehrten Code in kürzeren Abständen zu produzieren? Und: Sind Sie dabei erfolgreich?

Answer 1

Die Faustregel, die ich verwende, lautet: Refaktorieren Sie mit Tests und nur so viel Code, wie Sie auch wirklich brauchen.

Nach 60 Minuten sind Sie sicher, dass Ihr Code genau das tut, was er tun soll. Sie bräuchten eine Menge Tests, um zu bestehen. Ich würde einfach versuchen, einen zum Laufen zu bringen und dann zum nächsten überzugehen.

Answer 2

Wenn ich eine klare Vorstellung davon habe, was ich tun will, und wenn ich hinterher leicht überprüfen kann, dass ich nichts kaputt gemacht habe, mache ich größere Schritte.

Wenn das Refactoring komplizierter ist, versuche ich, es in kleinere Schritte aufzuteilen und nach jedem Schritt umfangreiche Tests durchzuführen.

Answer 3

Normalerweise refaktorisiere ich den Code, wenn ich ihn ändere. Das heißt, anstatt ein Stück Code zu nehmen und es unter Beibehaltung seiner Funktion neu zu schreiben, schreibe ich es in Richtung einer neuen Funktionalität um und verbessere dabei das Design des Codes.

Das bedeutet oft, dass ich zu dem Zeitpunkt, an dem ich die gewünschte Funktion implementiert habe, noch keine vollständige und zufriedenstellende Überarbeitung des alten Codes vorgenommen habe. Er ist jedoch verbessert, und ich weiß, dass ich die Zeit haben werde, ihn weiter zu verbessern, wenn ich das nächste Mal seine Funktion ändern will.

Für das Testen bedeutet dies, dass ich sowohl das Refactoring als auch die neue Funktion gleichzeitig testen kann, was etwas Zeit sparen dürfte.

Das bedeutet auch, dass ich nur so viel Zeit für das Refactoring aufbringe, wie für die Verbesserung der Wartungssituation für die betreffende Funktion erforderlich ist. Dies sollte dazu beitragen, dass ich nicht zu viel Engineering betreibe und/oder Zeit mit der Überarbeitung von Dingen vergeude, die bereits funktionieren und nicht von einem besseren Design profitieren würden. Wenn ich mich nur auf den Code konzentriere, den ich ohnehin ändern würde, ist die Wahrscheinlichkeit groß, dass ich diesen Code in nächster Zeit wieder aufgreife, um weitere Änderungen vorzunehmen, solange er noch im Blickfeld der Benutzer ist.

Answer 4

Kleine, diskrete Schritte sind das, womit ich mich am wohlsten fühle, auch wenn es manchmal ein Test meiner Selbstbeherrschung sein kann, das zu zügeln, was ein Refactoring-Blutbad werden könnte. Wenn mir Verbesserungen (egal wie groß) auffallen, notiere ich sie und überlege, wie ich sie in einzelne Refactoring-Aufgaben aufteilen kann. Außerdem ist es nicht hilfreich, wenn in der Commit-Nachricht eine Saga von Änderungen steht.

NB. Die Code-Basis, an der ich arbeite, ist ziemlich alt und voll von diesen mystischen Fehlern, die nach Wissenschaftlern benannt sind. Da große Teile immer noch nicht einmal eine Testabdeckung von annähernd 50 % aufweisen, wäre es leichtsinnig, sich darauf einzulassen.

Answer 5

Ja, das stimmt. Ich mag es, die Tests ständig laufen zu lassen, und so funktioniert eine Kette von kleinen Refactors gut. Es ist mir wirklich unangenehm, wenn mein Code länger als ein paar Minuten am Stück kaputt ist, und ich gehe in der Regel zurück, wenn mein Code kaputt ist, wenn ich abends nach Hause gehe, denn das Neuschreiben am nächsten Morgen funktioniert IMMER besser als der Versuch, dort weiterzumachen, wo ich war.