Ich habe mich gefragt, wie andere Entwickler anfangen zu refactoring. Was ist dein erster Schritt? Wie unterscheidet sich dieser Prozess (Refactoring), wenn Sie Code umgestalten, der nicht Ihnen gehört? Schreibst du Tests beim Refactoring?Wie refaktorieren Sie?
* DRY = Sie Repeat Yourself nicht
TROCKEN = Wiederhole dich nicht, ich wusste nicht, bis ich nachgeschaut habe, also dachte ich, ich würde anderen einen Kopf geben. –
@ [nemo]: danke, zur besseren Übersicht bearbeitet –
(1) funktioniert nicht wirklich auf jeder nicht-trivialen Codebasis. –
Für mich ist die erste Sache, sicherzustellen, dass der Code alle Best Practices unseres Büros trifft. Zum Beispiel, verwenden strenge, Warnungen und Taint für unsere Perl-Skripte.
Wenn es Probleme mit der Effizienz oder Geschwindigkeit gibt, konzentrieren Sie sich auf sie. Dinge wie finden Sie einen besseren Algorithmus, oder finden Sie einen besseren Weg, um zu tun, was die vierfach verschachtelte for-Schleife tut.
Und zuletzt sehen, ob es eine Möglichkeit gibt, den Code lesbarer zu machen. Dies wird normalerweise dadurch erreicht, dass 5 kleine Skripte, die ähnliche Dinge tun, in 1 Modul (Klasse) umgewandelt werden.
Ich Refaktor beim Schreiben neuer Code, mit Unit-Tests. Ich werde auch alten Code umgestalten, entweder meinen oder jemand anderen, wenn Methoden zu lang sind, oder Variablen schlecht benannt, oder ich duple etc.
Starten Sie mit Komponententests und verwenden Sie dann automatisierte Refactoring-Tools. Wenn das Refactoring nicht automatisiert werden kann, handelt es sich nicht wirklich um eine mechanische Transformation des Codes und somit auch nicht um ein Refactoring. Die Komponententests sollen sicherstellen, dass Sie nur mechanische Transformationen von einer Codebasis zu einer gleichwertigen durchführen.
Ich nehme Mist und mache es weniger beschissen. :-)
Ernsthaft. Ich überarbeite nicht, um neue Funktionen zu erstellen. Refactoring tritt vor neuen Sachen auf. Wenn es keine Tests gibt, schreibe ich Tests, um sicherzustellen, dass ich mit meinem Refactoring nichts breche. Wenn es Tests gibt, benutze ich diese. Wenn die Tests nicht ausreichen, schreibe ich vielleicht mehr Tests, aber ich würde das vom Refactoring getrennt betrachten und es zuerst machen. Der erste Schritt für mich ist zu bemerken, dass ich etwas abstrahieren und es allgemeiner machen kann (und nützlich an anderen Stellen, die jetzt die Funktionalität brauchen), oder ich bemerke, dass etwas schlecht ist und besser (subjektiv) sein könnte. Ich reformiere die Allgemeinheit nicht grundlos. YAGNI principle gilt.
Wir haben das Konzept der gemeinsamen Besitz, so dass der Code immer mir gehört - ich habe es vielleicht nicht geschrieben, aber ich denke nicht, dass beim Refactoring. Ich kann versuchen, die Dinge zu verstehen, bevor ich mich entscheide, dass sie refaktorisiert werden müssen, wenn der Zweck nicht klar ist - obwohl das fast immer ein Grund ist, sich selbst zu überdenken.
Refactoring ohne Komponententest ist gefährlich. Immer einen Komponententest haben. Wenn Sie etwas ändern, ohne gute Tests durchzuführen, sind Sie möglicherweise für einen Teil des Codes sicher, aber etwas anderswo hat möglicherweise nicht das gleiche Verhalten. Mit Unit Testing schützen Sie jede Änderung.
Refactoring anderer Code ist in Ordnung, aber das Extrem ist nicht. Es ist normal, dass jemand anders nicht so programmiert wie du. Es ist nicht "nett", Dinge zu ändern, weil du es anders gemacht hättest. Just Refactoring, wenn es wirklich notwendig ist.
Ich entferne die Duplizierung, die die Denkmuster des Codes vereinheitlicht. Refactoring muss diese beiden Dinge erreichen. Wenn Sie Code haben, der dasselbe zweimal durchführt, refactorisieren Sie ihn an einem gemeinsamen Ort und vereinheitlichen Sie die Abstraktion. Wenn Sie das gleiche Literal an drei Stellen haben, setzen Sie es in eine Konstante und vereinheitlichen den Zweck. Wenn Sie die gleiche Gruppe von Argumenten haben, stellen Sie sicher, dass sie immer in der gleichen Reihenfolge verwendet werden, oder, noch besser, ordnen Sie sie in einer gemeinsamen Struktur und vereinheitlichen Informationsgruppen.
lesen Martin Fowler ‚s Buch "Refactoring"
BTW - das eigene Amazon exec Link Martin Fowler, wenn Sie :)
fügen Sie etwas Verbindung hinzu! – MrBoJangles
Und seinen Namen richtig bekommen;) –
Hoppla! danke Leute. Eine gute Ausrede, um meine Antwort zu überdenken – MarkJ
frage ich mit den anderen Plakaten zustimmen, wenn Sie Code Refactoring Sie schrieb.
Wenn es Code ist, den Sie nicht geschrieben haben, und vor allem, wenn es viele davon gibt, würde ich mit Tools wie fxCop, Visual Studio Code-Analyse, DevPartner beginnen - ich bin sicher, es gibt andere gute. Sie würden Ihnen Ideen geben, wo Sie anfangen sollen und was die häufigsten Coding-Probleme sind. Ich würde auch Stresstests durchführen, um zu sehen, wo die Engpässe sind, daher der größte Gewinn für Ihre Bemühungen, den Code zu verbessern.
Ich liebe es, meinen Code zu refaktorieren, aber es ist möglich, es zu übertreiben. Wenn Sie die Leistung der App nicht wirklich verbessern oder die Lesbarkeit des Codes ernsthaft verbessern, sollten Sie wahrscheinlich aufhören. Es gibt immer die Möglichkeit, beim Refactoring neue Bugs einzuführen, besonders wenn Sie ohne Unit-Tests arbeiten.
Hängt sehr von meinen Zielen ab. Wie bereits gesagt wurde, benötigen Sie Unit-Tests, um sicherzustellen, dass Ihr Refactoring nichts gebrochen hat, und wenn Sie es getan haben, müssen Sie sich Zeit nehmen, es zu beheben. In vielen Situationen teste ich die vorhandene Lösung und wenn sie funktioniert, wickle sie um, anstatt sie zu refactorieren, da dies die Möglichkeit einer Unterbrechung minimiert.
Wenn ich Refactoring, zum Beispiel musste ich vor kurzem eine Reihe von ASCII-basierten C++ zu UNICODE portieren, tendiere ich dazu, sicherzustellen, dass ich gute Regressionstests haben, die sowohl auf Endbenutzer- als auch auf Geräteebene funktionieren. Wiederum versuche ich, Werkzeuge zu verwenden, anstatt manuell zu refactorieren, da dies weniger anfällig für Fehler ist und die Fehler, die Sie bekommen, eher systematisch als zufällig sind.
Ich bin viel widerwilliger Refactor Code von anderen geschrieben als Refactor mein eigenes.
Wenn es von einem meiner Vorgänger geschrieben wurde, refobieren ich im Allgemeinen nur innerhalb einer Funktion. Z.B. Ich könnte eine if-Anweisung durch einen Schalter ersetzen. Alles, was viel größer ist als das, liegt normalerweise außerhalb des Budgets.
Für meinen eigenen Code Refaktor ich normalerweise, wenn ich schreibe, wenn etwas hässlich aussieht oder anfängt zu riechen. Es ist viel einfacher, es jetzt zu reparieren, anstatt darauf zu warten, dass es Probleme auf der Straße verursacht.
Was ist Ihr erster Schritt?
Der erste Schritt besteht darin, die Komponententests auszuführen, um sicherzustellen, dass alle bestanden werden. In der Tat können Sie eine große Menge Zeit verschwenden, wenn Sie nach einer Ihrer Änderungen suchen, die einen Test unterbrochen hat, wenn dieser bereits vor Ihren Code geändert wurde.
Wie unterscheidet sich dieser Prozess, wenn Sie Code umgestalten, der nicht Ihnen gehört?
Ich mache sicherlich kleinere Schritte beim Refactoring-Code, den ich nicht geschrieben habe (oder Code, den ich vor langer Zeit geschrieben habe). Ich kann auch die Testabdeckung überprüfen, bevor ich fortfahre, um zu vermeiden, dass ich auf Komponententests angewiesen bin, die immer bestehen ... aber den Bereich, an dem ich arbeite, nicht testen.
Schreiben Sie Tests beim Refactoring?
ich normalerweise nicht, aber ich kann neue Tests in den folgenden Umständen (ohne Anspruch auf Vollständigkeit) hinzufügen:
es hängt auch von dem Refactoring entdecken durchgeführt wird. Beim Extrahieren einer Funktion kann ich einen neuen Test erstellen, wenn dieser anders als zuvor aufgerufen werden kann.
Hier sind einige allgemeine Hinweise:
Das erste, was ist es, eine Liste der code smells bemerkt zu halten, während auf dem Code zu arbeiten. Dies ermöglicht es, sich von der Last zu befreien, sich daran zu erinnern, was im Code gesehen wurde. Auch
Die goldene Regel ist nie Refaktor, wenn die Unit-Tests nicht vollständig bestehen.
Refactor, wenn der Code stabil ist, vor dem Hinzufügen etwas, das Sie wissen, wird durch eine zukünftige Refactoring beeinflusst werden, bevor zu integrieren und vor allem vor zu sagen, Ihre getan.
Wenn keine Komponententests vorhanden sind, müssen Sie den Teil des Codes eingeben, den Sie im Test testen möchten. Wenn Komponententests zu schwierig sind, um sie nachzurüsten, wie es normalerweise der Fall ist, können Sie characterization tests erstellen, wie unter Michael Feathers in Working Effectively with Legacy Code empfohlen. Kurz gesagt sind es End-to-End-Tests, mit denen Sie das aktuelle Verhalten des Codes festhalten können (von dem nicht angenommen wird, dass er immer perfekt funktioniert).
Haben Sie keine Angst zu tun Baby Schritte. Tu nicht zwei Dinge gleichzeitig. Wenn Sie etwas bemerken, das Refactoring erfordert, notieren Sie es, reparieren Sie es nicht sofort, auch wenn es sehr einfach erscheint.
Check-in sehr oft, wenn die Tests bestehen. Damit können Sie ein schlechtes Refactoring rückgängig machen, ohne dass das, was vorher gemacht wurde, verloren geht.
Denken Sie daran, Refactoring nicht Ihren Kunden einen Mehrwert (das kann diskutiert werden), aber der Kunde zahlt Ihnen nicht zu refactor. Eine Faustregel besteht darin, Änderungen vorher zu korrigieren oder dem Code neue Funktionen hinzuzufügen.
Erster Schritt: Identifizieren eines code smell.
Zweiter Schritt: Betrachten Sie alternative Implementierungen und was die Abwägungen sind und die akzeptiere ich in Bezug auf denen „besser.“
Dritter Schritt: Implementieren Sie eine bessere Lösung.
Das unterscheidet sich nicht, wenn der Code meins ist oder nicht, weil ich manchmal über Code zurückgehen kann, den ich vor Monaten oder Jahren geschrieben habe, und es wird wie Code von jemand anderem aussehen. Ich kann Tests schreiben, wenn ich neue Methoden entwickle oder es keine ausreichenden Tests für den Code gibt, IMO.
Allgemeiner Ansatz
ich an der Software durch spähen (Komponente) aus Vogelsicht beginnen kann. Abhängigkeitsanalyse und Graphikwerkzeuge sind hier eine große Hilfe (siehe weiter unten). Ich suche nach einem Kreis in den Abhängigkeiten auf Paketebene oder auf Klassenebene und auch nach Klassen mit zu vielen Abhängigkeiten. Dies sind gute Kandidaten für das Refactoring.
Werkzeuge des Handels
Dependency-Analyse-Tools:
Siehe http://stackoverflow.com/questions/20262/refactoring-for -testability-on-a-existing-system. Siehe http://stackoverflow.com/questions/48817/where-to-find-resources-on-refactoring. Keiner von diesen half? http://StackOverflow.com/Questions/Tagged/Refactoring –