Vorzeitiger Refactoring? [geschlossen]

Question

Wir haben alle gehört, von vorzeitigen Optimierung , aber was denken Sie über vorzeitigen Refactoring ? Gibt es eine solche Sache Ihrer Meinung nach? Hier ist, was ich hinaus will.

Zunächst einmal, Lesen Martin Fowler brechenden Arbeit „Refactoring“ buchstäblich mein Leben in Bezug auf die Programmierung geändert.

Eine Sache, die ich bemerkt haben, ist jedoch, dass, wenn ich Refactoring eine Klasse oder Rahmen beginnen zu schnell, ich mich manchmal finden sich in eine Ecke kodiert, so zu sprechen. Nun, ich vermute, dass das Problem nicht wirklich Refactoring per se, aber vielleicht verfrüht / schlechte Design-Entscheidungen / Annahmen.

Was sind Ihre Gedanken, Einsichten und / oder Meinungen zu diesem Thema? Haben Sie einen Rat oder gemeinsam Zusammenhang mit diesem Thema anti-Muster?

EDIT:

Aus Ihren Antworten Lesen und Nachdenken über dieses Thema mehr, ich glaube, ich habe zu der Erkenntnis gekommen, dass mein Problem in diesem Fall ist wirklich ein Problem von „premature Design“ und nicht unbedingt „verfrüht Refactoring“. Ich habe zuschulden einen Entwurf anzunehmen, und Refactoring in dieser Richtung bei der Codierung zu früh. Eine wenig Geduld auf meinem Teil ein Maß an Design Agnostizismus zu halten und auf Refactoring in Richtung sauberen Code konzentrieren würde mich halten von der Position, dieses Design Kaninchen Wegen nach unten.

Answer 1

Ich denke eigentlich das Gegenteil.

Je früher Sie anfangen, darüber nachzudenken, ob Ihr Design muss Refactoring, desto besser. Umgestalten ständig, so dass es nie ein großes Problem.

Ich habe auch festgestellt, dass je mehr ich früh auf Refactoring, desto besser habe ich über das Schreiben von Code sauberer vorne bekommen. Ich neige dazu, weniger große Methoden zu erstellen, und haben weniger Probleme.

Wenn Sie jedoch selbst „Refactoring“ finden sich in eine Ecke, würde ich erwarten, dass mehr eine Frage der fehlenden ursprünglichen Entwurf oder Mangel an Planung für den Umfang der Verwendung einer Klasse ist. Versuchen Sie das Schreiben heraus, wie Sie die Klasse oder Rahmen verwenden möchten, bevor Sie den Code schreiben beginnen - es kann Ihnen helfen, dieses Problem zu vermeiden. Dies ist auch glaube ich, ein Vorteil Driven Design zu testen -. Es hilft Ihnen, sich an mit Ihrem Objekt suchen erzwingen, bevor es geschrieben ist

Denken Sie daran, technisch Refactoring sollten Sie nie in eine Ecke sperren - es geht um die Interna Nacharbeiten ohne Änderung, wie eine Klasse verwendet wird. Wenn Ihr selbst durch Refactoring Trapping, es bedeutet, dass Ihre ursprünglichen Entwurf fehlerhaft war.

Wahrscheinlich werden Sie feststellen, dass im Laufe der Zeit, dieses Problem besser und besser wird. Ihre Klasse und Rahmen-Design wird wahrscheinlich am Ende flexibler.

Answer 2

  

Wir haben alle Vorzeitige Optimierung gehört, aber was tun Sie, was über vorzeitige Refactoring? Gibt es eine solche Sache Ihrer Meinung nach?

Ja, es gibt. Refactoring ist eine Möglichkeit, zahlen Sie technische Schulden , die über die gesamte Lebensdauer Ihres Entwicklungsprozesses entstanden ist. Allerdings ist die bloße Abgrenzung von technischen Schulden nicht unbedingt eine schlechte Sache.

Um zu sehen, warum, sich vorstellen, dass Sie Steuererklärung Analysesoftware für die IRS schreiben. Plötzlich werden neue Vorschriften in letzter Minute eingeführt, die einige Ihrer ursprünglichen Annahmen brechen. Obwohl Sie gut gestaltet, hat Ihr Domain-Modell unter den Füßen in mindestens einen wichtigen Platz grundlegend verschoben. Es ist April 14th, und das Projekt muss leben morgen gehen, kommen Hölle oder Hochwasser. Was tun Sie?

• Wenn Sie eine Muttern-und Schrauben-Lösung auf Kosten einiger moderate technische Schulden implementieren, wird Ihr System steifer und weniger in der Lage eine weitere Runde dieser Veränderungen zu widerstehen. Aber die Seite kann weiter leben und gehen Sie gehen, und es wird kein Risiko für die Bereitstellung spät; Sie sind sicher, dass Sie die erforderlichen Änderungen vornehmen können.
• Auf der anderen Seite, wenn Sie die Zeit nehmen, um die Lösung Refactoring, so dass es jetzt das neue Design in anspruchsvoller und flexible Art und Weise unterstützt, werden Sie keine Schwierigkeiten haben, an künftigen Änderungen anzupassen. Aber Sie laufen Gefahr Ihres Unternehmens Flaggschiff-Produkt gegen die Uhr gelaufen; Sie sind nicht sicher, ob das Redesign länger als heute nehmen.

In diesem Fall ist die erste Option ist die bessere Wahl. Vorausgesetzt, dass Sie wenig bisherigen technischen Schulden haben, es lohnt sich Ihre Klumpen jetzt zu nehmen und zahlen sie später auf. Dies ist, natürlich, eine geschäftliche Entscheidung, und kein Design ein.

Answer 3

Ich denke, dass es möglich ist zu früh, um zu Refactoring.

Bei den Muttern und Schrauben Ende Design ist der Code selbst. Diese letzte Phase des Designs kommt in der Existenz, wie Sie Code, wird es manchmal fehlerhaft sein, und Sie werden sehen, dass der Code entwickelt. Wenn Sie Refactoring zu früh macht es schwieriger, den fehlerhaften Entwurf zu ändern.

Zum Beispiel, es ist viel einfacher, eine einzige lange Funktion zu löschen, wenn Sie es Müll oder geht in der falschen Richtung erkennen, als es eine schöne wohlgeformte Funktion zu löschen ist und die Funktionen, die es verwendet und die Funktionen, die sie verwenden, usw. , während sichergestellt wird Sie nicht etwas anderes zu brechen, den Teil des Refactoring war.

Man könnte sagen, dass vielleicht sollten Sie mehr Zeit für das Entwerfen verbracht haben, aber ein Schlüsselelement in einem agilen Prozess ist, dass codierenden Teil des Designprozesses ist und in den meisten Fällen einig vertretbaren Aufwand in Design setzen hat, dann ist es besser, erhalten auf nur damit.

Bearbeiten In Reaktion auf die Kommentare: -

Entwurf wird nicht getan, bis Sie Code geschrieben haben. Wir können nicht lösen alle Probleme bei der Vorcodierung Design, der springende Punkt hinter Agile ist, dass Codierung ist Problemlösung. Wenn das Nicht-Code-Design, alle Probleme up-front gelöst, bevor es Codierung keine Notwendigkeit, re Faktor wäre, würden wir einfach das Design in einem Schritt zu gut faktorisierter Code umwandeln.

erinnern

Wer die Ende der 1980er Jahre und Anfang der 1990er Jahre strukturierten Design-Methoden, die, wo Sie bekam alle Probleme in cleveren Diagramme gelöst, bevor Sie eine Zeile Code geschrieben?

Answer 4

Vorzeitiger Refactoring ist Refactoring ohne Komponententests. Sie an diesem Punkt sind einfach nicht bereit für ein Refactoring. Zunächst einige Komponententests und dann über Refactoring nachzudenken. Andernfalls werden Sie (vielleicht) verletzt das Projekt mehr als Hilfe.

Answer 5

ich glaube, jeder „1.0“ Projekt dieser Art anfällig ist ... nennen wir es „iterative Design“. Wenn Sie nicht über eine klare Spezifikation haben, bevor Sie beginnen Objekte sind entwerfen, werden Sie wahrscheinlich denken Sie an vielen Designs und Ansätze zu Problemen.

Also, ich glaube, dieses spezielle Problem zu überwinden ist klar, Dinge zu entwerfen, bevor Sie Code schreiben beginnen.

Answer 6

Es gibt ein paar vielversprechenden Lösungen für diese Art von Problem, je nach Situation.

Wenn das Problem ist, dass Sie entscheiden können, was in einer bestimmten Art und Weise optimiert werden, und Sie extrahieren eine Methode oder etwas und erkennen, dass aufgrund dieser Entscheidung sind Sie alles andere in einem gewundenen Weg zu codieren gezwungen, das Problem ist wahrscheinlich, dass Sie kamen nicht weit genug in den Design-Prozess denken. Wenn es eine gut geschrieben und geplant spec gewesen wäre, hätte man über dieses Problem vor der Zeit bekannt (es sei denn, Sie nicht die Spezifikation gelesen haben, aber das ist ein anderes Thema :))

Je nach Situation kann Rapid-Prototyping-Adresse auch dieses Problems, da Sie eine bessere Vorstellung von diesen Implementierungsdetails haben, wenn Sie auf der realen Sache anfangen zu arbeiten.

Answer 7

Ich bin ein starker Gläubiger in ständigem Refactoring. Es gibt keinen Grund zu warten, bis einige bestimmte Zeit Refactoring zu starten.

Immer, wenn Sie sehen etwas, das besser, Umgestalten getan werden sollte.

Just hält dies in meinem Kopf. Ich kenne einen Entwickler (ein reines Genie), der so vielen refactors (er ist so klug er immer einen besseren Weg finden) beendet er nie ein Projekt.

Answer 8

Der Grund, warum vorzeitige Optimierung schlecht ist, dass die Optimierung in der Regel zu einer schlechteren Design führt. Im Gegensatz zu Refactoring, die zu einem besseren und saubereren Design führt, wenn nachdenklich und richtig gemacht. Was ich gelernt habe, nützlich zu sein für mich die Nützlichkeit eines Refactoring analysieren wurde zum ersten Mal in unserem UML-Diagramm suchen, um die Änderung sichtbar zu machen und dann das Code-doc Schreiben (z Javadoc) für die Klasse ersten und Stubs vor jedem echten Code hinzufügen. Natürlich Erfahrung viel helfen mit, dass, wenn im Zweifelsfall Ihre Lieblingsarchitekten fragen;)