Hat jemand anderes ein Refactoring-Problem? [geschlossen]

Es scheint, als hätte ich nach dem Schreiben einer beträchtlichen Menge an Code das Gefühl, dass ich es nicht auf die bestmögliche Art und Weise getan habe, und am Ende bin ich ständig umgestaltet und verbringe viel zu viel Zeit mit dem Projekt oder werde es nie das ist manchmal passiert. Passiert das jemals jemand anderem und wie gehen Sie damit um?

Ich genieße diese Momente, wenn sie mir passieren.

Der Grund: Wenn ich nicht auf meine Arbeit zurückblicken und denken würde, dass es etwas gibt, das ich hätte besser machen können, als ich als Entwickler nicht weiterkommen würde. Wenn diese Momente der Erleuchtung auftreten, nehmen Sie sie daher an und nehmen Sie zur Kenntnis, was Sie gelernt haben. Überlegen Sie sich Ihren Zeitplan für das aktuelle Projekt und überarbeiten Sie den Code, falls dies nicht möglich ist. Nehmen Sie die Lektion und verwenden Sie sie in zukünftigen Implementierungen für Projekte.

Aus eigenen Fehlern zu lernen, ist in jedem Fall eine großartige Sache!

Hier einige Regeln, um diese Aktivität einzuschränken und produktiver zu machen:

• time-box es, zb den timer auf 25 minuten einstellen
• Tun Sie dies nur, wenn Sie eine angemessene Testabdeckung haben.
• Versuchen Sie, Ihr Refactoring für die Entwicklung der nächsten Funktionen nützlich zu machen

Es sieht so aus, als könnten Sie immer umgestalten, nicht wahr? Ich versuche, das Refactoring nur dann einzuschränken, wenn ich andere Probleme lösen möchte. Wenn Sie beispielsweise ein Leistungsproblem haben und beim Refactoring Hilfe benötigen, können Sie dieses Problem beheben. Wenn Sie neue Funktionen hinzufügen und beim Refactoring Hilfe benötigen, können Sie das Problem beheben

Um ehrlich zu sein, würde ich mir mehr Sorgen machen, wenn Sie riesige Mengen an Code herausbringen und denken, dass alles perfekt ist und keine Umgestaltung benötigt ...

Als ich jünger und unerfahren war, war ich sehr arrogant in Bezug auf meine Programmierfähigkeiten und stellte mir immer vor, dass es möglich ist, wirklich gut zu entwerfen und zu planen. Ich werde alle perfekt sein.

Die Realität ist fast das Gegenteil. Einige sagen sogar, dass Sie sich, sobald Sie mit dem Codieren beginnen, im Wartungsmodus befinden sollten. Die Idee dabei ist, dass die "Implementierungs" -Stufe der SDLC als solche nicht wirklich existiert, da Sie niemals die Fehlerbehebung oder das Refactoring beiseite legen und so tun sollten, als ob der Code, den Sie produzieren, "frisch" und perfekt ist.

Das alles gesagt, ich nehme an, es IST möglich zu obsessiven über Refactoring zu bekommen. Ich habe es nur noch nicht gesehen. Und je mehr Erfahrung ich habe, desto mehr denke ich, dass es eine gute Sache wäre, wenn mehr Software-Teams sich offenkundig weigern würden, an engen Fristen zu arbeiten und technische Schulden zu machen. Schließlich ist dies der häufigste Grund, warum Refactoring in der realen Welt nicht mehr zum Einsatz kommt.

Ich würde vorschlagen, sich nicht nur auf das Gefühl oder den Code-Geruch zu verlassen.

Führen Sie klar auf, was mit dem Code nicht stimmt und welche Lösungen es gibt. Im Ernst, schreiben Sie es auf, weil Sie überprüfen möchten, wie effektiv Ihr Refactor dagegen war.

Identifizieren Sie Möglichkeiten, um den Refaktor in erreichbare Teile zu zerlegen, und priorisieren Sie sie. Haben Sie die Disziplin, sich nur auf den Umfang jedes Abschnitts zu konzentrieren, und vermeiden Sie Tangenten, die Ihre Aufgabe untergraben können.

Ermitteln Sie außerdem, welche Komponententests Sie mit dem vorhandenen Code schreiben können, bevor Sie fortfahren. Wenn es schon umfangreiche Tests gibt, ist das eine tolle Sache. Das Fehlen von Komponententests ist eine großartige Gelegenheit, einige zu machen.

Es besteht kein Zweifel, dass ich in diese Falle tappe, aber ein bisschen Refactoring ist wichtig für die zukünftige Unterstützung / Fehlersuche.

Wenn Sie einen großen Teil des Codes schreiben, ist es sehr einfach, durch die Codezeilen in die Methode zu gelangen, die gerade geschrieben wird. Wenn ich einen großen Teil des Codes fertiggestellt habe, platziere ich einen Kommentar zur Überprüfung des Codes . Ein paar Tage später werde ich dann die Codeüberprüfung durchführen und entsprechend umgestalten. Wenn ich ein paar Tage später Probleme habe, zu lesen, was in ein paar Monaten oder sogar Jahren passieren wird.

Ich tappe in diese Falle, wenn ich zum ersten Mal eine Sprache oder Technologie lerne. Wenn Sie zum Beispiel Java zum ersten Mal lernen, stellen Sie sich vor, Sie schreiben eine Web-App mit einem Servlet, und denken, das ist der richtige Weg. Dann merkt man, dass es jsp gibt und man denkt, oh, das ist neuer, das ist wahrscheinlich richtig. Sobald Sie die Hälfte der Zeit hinter sich haben, finden Sie Struts und vielleicht etwas EJB-Material. Danach finden Sie Spring (xml-basiert). Danach finden Sie die coolen @ MVC-Annotationen. Danach finden Sie alles zu ausführlich und Sie sind verwöhnt Wahl zwischen Groovy / Grails und Scala / Lift! Dies ist für persönliche Projekte vollkommen in Ordnung, da es in der Regel darum geht, zu lernen und nicht unbedingt eine Frist einzuhalten.

Ich war auch ein Über-Refactorer bei der Arbeit. Aber da ich mehr Erfahrung gesammelt habe, bin ich selektiver geworden, was ich umgestalten werde. Es stellt sich heraus, dass Sie den Code nicht mitnehmen, wenn Sie ein Unternehmen verlassen, und normalerweise können andere Ingenieure den Code fast schneller zerstören, als Sie ihn reparieren können.

Die Faustregel, der ich folge, lautet: Ich überarbeite, bis es so optimiert ist, wie es zu diesem Zeitpunkt sein kann, und dann überarbeite ich es nicht erneut, es sei denn, die Situation ändert sich, oder seltener, wenn ich eine Inspiration für einen neuen und besseren Weg habe Dinge tun (zum Beispiel mit einer neuen Sprachfunktion).

Ich musste zum Beispiel einmal ein neues Codemodul für eine vorhandene Anwendung schreiben. Ich schrieb es auf eine bestimmte Art und Weise, und am nächsten Tag überlegte ich, ob ich es überarbeiten und abstrakter gestalten könnte, da wir ziemlich sicher waren, dass es für andere Zwecke später erweitert werden müsste. Also habe ich den Code überarbeitet. Dann entschied ich, dass es etwas zu generisch war und konsolidierte einige Klassen und Interfaces, die im Grunde dasselbe taten, indem ich Generics (C #) verwendete, um die gleiche Funktionalität zu erhalten. An dieser Stelle ich wahrscheinlich könnteweitere Überarbeitung, um es noch besser zu machen, aber es ist "gut genug" - der Code ist gut geschrieben, folgt den richtigen Entwurfsmustern und Konstruktionskonzepten und ist erweiterbar. Ich würde es nur noch einmal überarbeiten, wenn ich aufgrund der Anforderungen gezwungen wäre, den Code neu zu bewerten, oder wenn es eine Sprachfunktion gäbe, die den Code klarer und / oder lesbarer machen könnte.