Meine Frage bezieht sich vage auf diese . Es behandelt jedoch nicht die Techniken oder Praktiken.
Ich lese The Pragmatic Programmer und es wird dringend empfohlen, Code so oft wie möglich zu refactoring. Es wird jedoch nicht detailliert darauf eingegangen, wie dies und wie oft zu tun ist. Wie redest du deinen Code um und wie oft refaktorierst du?
Wann und wo benötigt.
Es hat keinen Sinn, Refactoring an sich vorzunehmen, es ist ein Werkzeug, um die weitere Entwicklung zu erleichtern. Refaktorieren Sie nur, wenn Sie davon profitieren. Eine kleine Bibliothek, die sich niemals weiterentwickeln wird und getestet wird, ist der perfekte Kandidat, um nicht zu refaktorieren, jede Zeit, die in das Refactoring investiert wird, zahlt sich nicht aus. Teile Ihres Systems / Programms, die sich weiterentwickeln werden, Wartung benötigen und schwer zu lesen sind, sind die klaren Kandidaten für einen Refactoring.
Denken Sie immer an den ROI (Return of Investment), wenn Sie anfangen, alles zu refaktorisieren, von dem Sie denken, dass es besser sein könnte, dann werden Sie morgen wieder umgestalten, und vielleicht werden Sie irgendwann Zeit haben, tatsächlich einen wirklichen Fortschritt zu machen.
Es ist so, als würde man ein Haus putzen, man sollte jeden Tag aufräumen und die kleinen Aufgaben erledigen, die nötig sind, um die Dinge sauber zu halten. Dann (einmal in der Woche oder so) nehmen Sie mehrere Stunden und geben dem Haus eine gute Reinigung von oben bis unten. Endlich (einmal im Jahr oder so) machst du einen guten Frühjahrsputz, hol den Müll raus und fang frisch an.
Beim Refactoring geht es darum, eine saubere Code-Basis zu behalten, und es sind immerwährende Aufgaben, die niemals beendet werden.
Immer wenn ich Code doppelt sehe.
Immer wenn ich eine Möglichkeit für einen einfacheren Algorithmus / Heuristik sehe.
Je weniger ich zu einer Veröffentlichung komme, desto weniger.
Ich liebe Tools, die Ihnen helfen, Ihre Codebasis zu analysieren, und Ihnen über ungenutzte Mitglieder, unnötige Sichtbarkeit (öffentlich vs. geschützt vs. intern vs. privat) erzählen können.
Ich arbeite hauptsächlich in. NET und ReSharper ist Awesome für dieses Verfahren sowie die Automatisierung vieler Arten von Refactoring-Operationen. Ich denke, dass es ähnliche Tools für viele andere Sprachen gibt.
Im Allgemeinen refaktoriere ich den Code, wenn ich daran arbeite, einen Teil des Systems zu verbessern, und ich weiß, dass der Teil des Codes, den ich umgestalte, getestet wird.
Wenn ich etwas sehe, von dem ich weiß, dass es bearbeitet werden muss, und es nicht Teil der aktuellen Version ist, lasse ich es für den Moment in Ruhe und hole es für die nächste Veröffentlichung heraus. Das ist keine große Sache für uns hier, weil wir ungefähr einmal im Monat veröffentlichen, also kann schlechter Code, den wir sehen, ein wenig warten (vorausgesetzt, es verursacht kein Problem in der Produktion), bis wir Zeit haben, gründlich zu überprüfen Was getan werden muss.
Wenn ich einen ersten Code-Code schreibe, versuche ich normalerweise, mich nicht zu langweilen, wenn ich über mögliche Wiederverwendungsszenarien zu weit in die Zukunft denke. Dann, je mehr Wiederverwendungsszenarien auftauchen, je weiter ich in die Entwicklung eintrete, desto mehr refactoriere ich meinen alten Code, um seine Abstraktionsebenen zu erhöhen und ihn wiederzuverwenden.
Also wirklich, es ist ein iterativer Prozess; Je mehr ich rüber gehe und den Code benutze, den ich bereits für neue Zwecke geschrieben habe, desto mehr finde ich es notwendig, zu refactorieren.
Ich suche nach Refactoring-Möglichkeiten, wenn ich neue Funktionen hinzufüge oder speziell die bestehenden Funktionen ändere
Hauptsache, erzählen Sie Ihrem Chef / Kunden nie, dass Sie refactoring sind. Schließen Sie das Refactoring immer mit dem normalen Arbeitsablauf ein. Es lohnt sich nicht, ständig zu erklären, warum es sich lohnt, dafür zu bezahlen.
Es gibt Ebenen und Ebenen des Refactoring.
Ich reformiere ständig, um Duplikate zu entfernen. Ich gehe nicht nach für die Vervielfältigung, aber wenn ich es sehe, repariere ich es. Ich benutze ständig die Extraktionsmethode, um Methoden zu verkleinern und alle ReSharper-Vorschläge oder Warnungen zu befolgen (Ich konfiguriere ReSharper, um alles zu machen, was ich wahrscheinlich in einen Hinweis ignoriere). Dies ist auch ein Vorteil, weil Sie sich daran gewöhnt haben, das nette fröhliche grüne Quadrat oben zu sehen, das Ihnen sagt, dass alles gut ist. Wenn es eine andere Farbe ist, weißt du , dass etwas nicht stimmt.
Größere Refactorings (die Art, um die das OP besorgt sein kann), behandle ich weitgehend wie ein neues Feature. Ich werde versuchen, einen Konsens darüber zu erzielen, wie wichtig es ist, und werde es entsprechend planen. Ich werde eine solche Änderung nicht vornehmen, es sei denn, der betreffende Code weist eine hohe Einheitentestabdeckung auf. "Wenn es nicht getestet wird, dann ist es kaputt" ist eine logische Folge von Murphys Gesetz. Wenn es bereits kaputt ist, werde ich es nicht noch schlimmer machen, indem ich schlecht abgedeckten Code umgestalte.
Ich reformiere auch nicht, um den Code an ein Muster anzupassen oder für die Zukunft einfacher zu modifizieren. Wenn die Zukunft eintrifft, wird sie mit einigen fehlgeschlagenen Komponententests ankommen, die nicht erfolgreich sein werden, wenn ich die Änderungen nicht mache. Wenn es solche Tests nicht gibt, kann ich nicht sagen, ob meine Änderungen etwas kaputt gemacht haben, also werde ich nicht umgestalten.
Es gibt eine Reihe von Aussagen und Faustregeln zum Refactoring. Ein gewöhnliches, das mir sofort in den Sinn kam, war Die Dreiheit
Im Berufsleben haben wir natürlich weniger Flexibilität, wann Refactoring durchgeführt werden kann, als in unseren persönlichen Projekten. Da Änderungen Risiken einführen und Arbeit für Tester schaffen (selbst wenn Sie alle Ihre Regressionstests automatisiert haben, erzeugt ein Wechsel zur Produktion etwas Arbeit für einen Menschen irgendwo in Ihrem Prozess neben dem Menschen, der den Code geändert hat), müssen Sie Berechnen Sie das Kosten-Nutzen-Verhältnis, wenn Sie entscheiden, was und wann umgestaltet werden soll.
Hier sind ein paar Dinge, die ich im Hinterkopf habe, wenn ich darüber nachdenke, was und wie ich umgestalten soll, besonders wenn ich an Code arbeite, der in Produktion geht:
Ich bin kein großer Fan von Refactoring nur für Refactoring Sake. Ich versuche immer, den Code so sauber wie möglich zu halten, Verknüpfungen zu vermeiden und es beim ersten Mal richtig zu machen. Jedes Mal, wenn ich ein neues Feature hinzufüge, refactoriere ich unterwegs, falls nötig, und berücksichtige dies als einen Teil der Feature-Implementierung.
Wenn Sie es sich leisten können, so zu arbeiten, werden große und "gruselige" Refactorings nicht so oft benötigt, als wenn Sie nicht regelmäßig kleinere Aufräumarbeiten durchführen.
Natürlich, wenn sich der Umfang des Projekts ändert, wird das Refactoring oft benötigt, unabhängig von der Form, in der der Code ist, aber je schlanker der Code ist, desto einfacher und schneller ist das Refactoring.
Ich refaktoriere, wenn ich keinen neuen Code entwickle. Ich reformiere auch an jedem Punkt, an dem ich Engpässe feststelle.
anders als wirklich - wirklich enge Situationen, in denen du etwas erledigen musst jetzt dann behalte ich immer ein offenes Auge für Refactoring, sobald ich etwas aufschreibe. Es gibt Zeiten, wenn ich Freizeit habe, werde ich versuchen, alten Code neu zu refaktorieren, falls ich etwas verpasst habe.
Ich refaktoriere sehr oft. Das klassische Szenario ist, wenn ich große Methoden schreibe und sie gerne in kleinere Teile zerlege. Es gibt viele andere und sie treten mit einer gewissen Häufigkeit auf. Refactoring hilft mir sehr dabei, schnell zwischen dem Code zu balancieren, aber meinen Code so sauber wie möglich zu halten.
Ich denke, es gibt mehrere entscheidende Faktoren, um Code zu refaktorieren. Einige von ihnen können Ästhetik, gemeinsame Funktionalität oder Geschäftsprozess sein.
Zum Beispiel arbeite ich gerade an der Umgestaltung der gemeinsamen Funktionalität von mehreren unserer Dienstprogramme (Java Swing). Jedes Dienstprogramm hat die gleiche Menüleiste oben. Aber wenn ich einen Menüpunkt hinzufügen muss, muss ich es für alle Dienstprogramme (Kopieren / Einfügen) tun. Also habe ich ein Menüleisten-Objekt erstellt und jedes Werkzeug benutzt dieses Objekt. Jetzt, wenn ich einen Menüpunkt hinzufüge, werden sie alle sofort aktualisiert.
Die Entwicklung dieser Utilities wird jetzt an verschiedenen Orten auf der ganzen Welt statt nur von mir erfolgen. Also versuche ich, noch mehr Gemeinsamkeiten zu entwickeln, so dass, wenn ein neuer Entwickler an einem Dienstprogramm arbeitet, sie sich nur auf das Fleisch-und-Kartoffeln und jetzt auf den Swing-Aspekt konzentrieren können.
Ich habe auch mehrere Datenvalidierungs- und Dateneinfügungsverfahren in kleinere umstrukturiert. Dies hilft dabei, die Geschäftslogik in der Anwendung aufzulösen, und kann dazu beitragen, dass Sie sich genau dorthin begeben, wo Sie hin müssen. Beispielsweise gibt es einen Schritt in einer Anwendung, der bestimmt, ob eine Zeile in die Datenbank eingefügt werden kann. Anstatt diesen einen Schritt zu machen, habe ich ungefähr 10 gemacht, was das Lesen der Daten, die Überprüfung der richtigen Größe und des Datentyps, die Anzeige im Label usw. einschließt. Jetzt ist es einfacher, die Geschäftslogik eines bestimmten Abschnitts zu ändern .
Die ganze Zeit. Immer wenn ich einen besseren Namen für eine Methode oder Variable sehe, werde ich immer dann, wenn ich etwas sehe, das inline oder extrahiert werden soll, auf Eclipse's automatisierte Refactorings angewiesen, um diese Änderungen sicher durchzuführen. Größere, nicht automatisierte Refactorings kommen seltener vor, aber wenn ich die Notwendigkeit sehe, und nur mit einer soliden Testabdeckung.
Spezifisch für VS 2008 und C #
Die ganze Zeit. Ich neige dazu, mit StyleCop und Code Analysis permanent zu laufen. Sogar Resharper wird verwendet, und wenn ich irgendwo Rot sehe, ist es an der Zeit zu refaktorieren. Zugegeben, ich benutze diese Tools nur, um das zu vereinfachen und um mich dazu zu zwingen.
Wie auch immer, ich korrigiere nur meinen eigenen Code und neuen Code. Legacy-Code und Code von anderen geschriebenen unberührt bleiben, bis sie dazu aufgefordert werden.
Tags und Links programming-languages coding-style refactoring