Refactor / Code umschreiben oder fortfahren?

Refaktoriere es jetzt.

Da Sie sogar über das Refactoring nachdenken, klingt es, als könnten Sie sich die Zeit dafür nehmen. Wenn Sie es für später verlassen, sind Sie wahrscheinlich mit anderen Dingen beschäftigt und verlieren diese Gelegenheit. Wenn die Zeitpläne knapp werden, können die Kunden verstehen, ob Sie etwas mehr Zeit benötigen, um ein neues Feature fertig zu stellen. Sie sind viel weniger verständnisvoll, wenn Sie ihnen sagen, dass Sie zusätzliche Zeit benötigen, um etwas umzuschreiben, das bereits funktioniert.

Wenn dieser Code die QA bereits bestanden hat, sollten Sie ihn vielleicht so wie er ist freigeben und die Code-Schulden akzeptieren. Wenn es Zeit gibt, dafür zu investieren, würde ich die Teile davon auswählen, die am ungeheuerlichsten sind, und versuchen, diese zu umgestalten, zum Beispiel die Umsetzung Ihrer Hashtable-Implementierung. Erstellen Sie andernfalls eine Liste mit Dingen, die Sie verbessern möchten, und arbeiten Sie an den Verbesserungen Ihrer zukünftigen Änderungsanforderungen.

Es ist gut über dich selbst zu wissen, dass du mit dem Code niemals zufrieden bist. Erinnere dich daran, dass du deinen Perfektionismus nicht in die Lage legst, regelmäßig zu veröffentlichen.

In einem deiner Kommentare hast du gesagt: "Es wird viel Code drauf gebaut." Sie sagen, dass es richtig funktioniert, aber wenn es schlampig ist und auf schlechten Designprinzipien beruht, wird es immer schwieriger werden, irgendetwas im Laufe der Zeit zu ändern. Im Allgemeinen gilt, je wichtiger ein Code ist, desto besser sollte er aussehen. Holen Sie sich das Design richtig, bevor Sie Dinge hinzufügen (im Rahmen des Zumutbaren).

Plus, eines der Hauptziele des Schreibens von Software (meiner Meinung nach) ist es, Komplexität zu verwalten. Wenn Sie es funktioniert haben, haben Sie die Hälfte der Arbeit erledigt. Die andere SEHR wichtige Hälfte des Jobs besteht darin, die Dinge einigermaßen leicht zu verstehen und zu verändern. Ohne das erstellen Sie Software, die nicht gut auf Änderungen reagiert. Und Software muss sich ändern. Oft.

Meine Firma hat eine Software, die sehr schlampig in den Kinderschuhen steckt, und jede kleine Veränderung, die über die Jahre hinzugefügt wurde, wurde schlampig auf die bereits schlampige Basis genagelt. Jetzt ist es an dem Punkt, an dem die Leute nach einfachen Dingen fragen (wie zum Beispiel Mausrad-Unterstützung zum Scrollen), und der Hauptentwickler antwortet mit "Sie wissen nicht, wie viel ich ändern müsste, um das zu tun". Wenn der Code während des Schreibens (oder kurz danach) gereinigt wurde, haben wir dieses Problem nicht.

Wenn Sie jetzt schlampigen, schlecht entworfenen Code haben, wird Sie später in den Hintern beißen. Vor allem, wenn viel anderer Code darüber geschrieben wird.

Ist es wahrscheinlich, dass andere den Greueln ausgesetzt werden, die Sie verursacht haben? Wenn ich schrecklichen Code in die Wildnis entlassen habe, tendiere ich dazu, ihn zu säubern, aber wenn ich der Einzige bin, der der Wartung und dem Umgang damit ausgesetzt ist, werde ich es eine Weile schwächen lassen funktioniert gut genug und wenn ich mich ein bisschen darauf setze, könnte ich sogar eine bessere Lösung finden, als ich es gewesen wäre. Ich wurde inspiriert, es sofort zu "reparieren".

IMHO, natürlich.

"Einige Klassen verlieren Implementierungsdetails (z. B. habe ich früher eine Map in eine Hash-Map geändert und musste feststellen, dass ich Code in anderen Quelldateien ändern muss, damit die Änderung funktioniert)"

Das ist Grund genug, dass es sich im Aufwand lohnt. Per Definition ist es etwas, das Benutzer tatsächlich bemerken.

Einige andere wichtige Dinge zu beachten:

• Wartbarkeit - Wie einfach wird es sein, alle unvermeidlichen Fehler zu beheben?
• Testability - Wenn Sie Ihren Code in eine besser testbare Form bringen, ist dies eine großartige Möglichkeit, ihn zu refaktorisieren. Das Hinzufügen von Komponententests bedeutet dann, dass Sie es ändern können und genau wissen, was bricht.
• Erweiterbarkeit - Denken Sie, dass Sie jemals neue Funktionen hinzufügen müssen?

Es ist wirklich das einzige Mal, dass Sie nicht daran denken sollten, Ihren Code besser zu machen, wenn Sie sicher sind, dass Sie ihn nie wieder anfassen müssen (d. h. fast nie).

"Ich habe gerade abgeschlossen ..."

Es klingt so, als würden Sie aktiv Legacy-Code schreiben, was nicht gut ist. Sie haben viele Gründe hervorgehoben, warum Sie Ihren Code möglicherweise umgestalten möchten, aber wie Sie sagen, funktioniert es nach Spezifikation, so dass keine Kosten dafür anfallen, es so zu belassen wie es ist.

Auf der positiven Seite, wie der Code funktioniert (und sollte funktionieren) ist wahrscheinlich frisch in Ihrem Kopf, so Refactoring ist jetzt wahrscheinlich billiger als Refactoring später; Auf der anderen Seite erhöht Refactoring später mit einer tatsächlichen Änderung Anfrage die Wahrscheinlichkeit der Umgestaltung in die richtige Richtung.

In Zukunft würde ich ernsthaft darüber nachdenken, langsamer zu werden und beim Schreiben von Code weiter zu denken. Refactoring (oder Factoring!), Wie Sie gehen, ist viel einfacher und Sie haben nicht den "aber es funktioniert" Druck, einfach so zu bleiben, wie sie sind.

Sehen Sie zu. Wenn Sie feststellen, dass eine Klasse mehrere Verantwortlichkeiten zu übernehmen scheint, halten Sie inne und überlegen Sie, ob Sie die Verantwortlichkeiten in separate Klassen aufteilen müssen.

Wenn Sie bemerken, dass Sie in die Interna einer Klasse gelangen wollen, halten Sie an und überlegen Sie, wie die Schnittstelle zwischen den Klassen aussehen soll, damit Sie nicht die konkreten Einbauten einer konkreten Klasse kennen und verwenden müssen.

Arbeite an den Aspekten, die später zu Fehlern führen. Vergolden Sie nicht.

Es ist eigentlich nicht so kompliziert. Folge einfach dieser Regel:

Häufig Code umgestalten. Refactor jedes Mal, wenn es möglich ist.

Wenn Sie also denken, dass Sie Ihren Code umgestalten können, sollten Sie dies jetzt tun, bevor es später, wenn alle Codes so eng zusammengezogen sind, viel komplizierter wird.

Jetzt haben Sie Ihre Referenzimplementierung. Wenn Sie sich motiviert fühlen, versuchen Sie es mit Refactoring. Hab keine Angst, wegzuwerfen und weiterzumachen oder neu zu starten.

Vielleicht wiederholen Sie die API / Schnittstelle basierend auf dem Verbrauchercode und fahren Sie das Refactoring-Top nach unten.

Sie sollten nicht wirklich daran interessiert sein, öffentliche Datenmitglieder zu haben. Die Leute schreiben viel zu viele Accessoren, die am Ende zum Spaß tippen und ehrlich gesagt die Quelle von wirklich dummen und frustrierenden Bugs (der einzige Code ohne Bugs ist Code, der nie geschrieben wurde). Das ist irritierend. Nur einkapseln, um fragile Zustände zu schützen (wenn der Elementdatenstatus gekoppelt ist).

  

Also, was denkt stackoverflow?   Code reinigen oder an Features arbeiten?

Die Frage, die ich hier sehe, ist der Preis, den Sie bezahlen müssen, wenn Sie umgestalten, im Gegensatz zu dem Preis, den Sie bezahlen, wenn Sie das nicht tun.

Wenn Sie es so belassen wie es ist, kostet es Sie für jede Wartung (zusätzliche Zeit, erhöhte Möglichkeit, bei jeder Änderung neue Defekte hinzuzufügen) und den Ruf als Entwickler (jeder andere Programmierer, der sich damit beschäftigt, könnte Sie wahrscheinlich verfluchen :) ).

Wenn Sie garantieren können, dass niemand diesen Code jemals wieder anfasst (nicht weil es zu schrecklich ist;)), können Sie ihn sicher so lassen, wie er ist. (In 10+ Jahren als Entwickler habe ich nie eine Situation gefunden, in der ich das garantieren konnte).

In allen anderen Fällen ist das Refactoring besser.

  

Sie sehen wie gute Gründe dafür aus   Refactor und Clean Code, Hilfe für die Zukunft   Wartung und Erweiterung, könnte aber   ziemlich zeitaufwendig sein.

Sie müssen den Code nicht perfekt machen. In der Tat, Sie sollten es eine Änderung zu einer Zeit nehmen, und Refactor in Iterationen, und wenn Sie dies richtig tun, wird es keinen anderen Code beeinflussen.

Das heißt, Sie sollten in der Lage sein, abhängig von Ihrer verfügbaren Zeit umzustukturieren, und nicht umgekehrt.

Wenn Sie beispielsweise nur eine Ihrer Mehrzweckklassen in drei oder vier separaten Klassen auflösen und den Code mit diesem Code aktualisieren, funktioniert der Rest des Codes genauso wie zuvor. Wenn Sie keine Zeit mehr haben, wenn Sie diese Änderung abgeschlossen haben, können Sie sie so lassen, wie sie ist (nur ein bisschen klarer, in nur einem Bereich).

Wenn Sie mehr Zeit haben, können Sie das nächste Refactoring machen und wiederholen.

Außerdem können Sie, wenn Sie ein verzweigtes Quellcodeverwaltungssystem verwenden, sogar parallel arbeiten, um neue Funktionen mit relativ geringen zusätzlichen Kosten zu refaktorieren und hinzuzufügen (und das Refactoring fortzusetzen, je mehr Zeit Sie haben).

Ich würde immer Refactor sagen. Jede zusätzliche Zeile Code und alle diese kleinen kleinen Fehler kommen zurück und beißen dich in den Arsch.

In der Zukunft könnten Sie sogar umgestalten, während Sie gehen - die Zeit ist nie unbeaufsichtigt - selbst wenn Sie es wegwerfen, haben Sie immer noch gelernt, etwas Besseres zu tun.

Wenn Sie eine Reihe von Tests haben, um zu überprüfen, ob Ihr Code jetzt und nach Ihrem Refactoring funktioniert, dann würde ich sagen, wenn Sie Zeit haben, beheben Sie es, da es später mehr Zeit kostet. Aber wenn die Zeit drängt, dann ist es völlig in Ordnung, dies als Code-Schulden aufzuschreiben und zu einem besseren Zeitpunkt zurückzukommen. Wenn der Code funktioniert, können Sie jetzt eine vollkommen gute Version davon schneiden und später darauf zurückkommen, wenn Sie mehr Zeit und weniger Druck haben.