Wie behandeln Sie Legacy-Code (und Daten)?

Question

Ich bin gerade dabei, mein lokales Subversion-Repository neu zu strukturieren, indem ich einige neue Projekte hinzufüge und Legacy-Code und Daten aus einigen älteren Repositories darin zusammenfasse.

Wenn ich dies in der Vergangenheit getan habe, habe ich normalerweise den Legacy-Code in einen dedizierten "Legacy" -Ordner gesteckt, um den neuen und "gut strukturierten" Codebaum nicht zu "stören". Im Sinne des Refactorings empfinde ich dies jedoch als etwas falsch. Theoretisch wird der Legacy-Code im Laufe der Zeit umgestaltet und an seinen neuen Standort verschoben, aber in der Praxis passiert dies selten.

Wie behandeln Sie Ihren Legacy-Code? So sehr ich versucht bin, die alten Sünden im "Legacy" -Ordner zu verstecken, um sie nie wieder zu sehen, hoffe ich, dass ich dadurch, dass ich sie zwinge, unter den "gesünderen" Bewohnern des Repositoriums zu leben Code wird eine bessere Chance haben, eines Tages gesund zu werden?

(Ja, wir alle wissen, we shouldn't rewrite stuff, aber das ist mein „Spaß“ Repository, nicht mein Business-Projekten ...)

aktualisieren

Ich mache mir keine Sorgen über die technischen Aspekte des Haltens Spur verschiedener Versionen. Ich weiß, wie man Tags und Zweige dafür benutzt. Dies ist eher ein psychologischer Aspekt, da ich es vorziehe, eine "ordentliche" Struktur im Repository zu haben, was das Navigieren für den Menschen viel einfacher macht —.

Answer 1

Der gesamte Code wird "Legacy" eines Tages, warum trennen Sie ihn überhaupt? Die Quellcodeverwaltung erfolgt nach Projekt/Zweig oder Projekt/Plattform/Zweig und dieser Art von Hierarchie. Wen kümmert es, wie lange es im Zahn ist?

Answer 2

Tagging ist eine sehr billige Operation in Subversion. Kennzeichnen Sie Ihren Code beim Refactoring und in regelmäßigen Abständen, während Sie mitmachen. Auf diese Weise ist es einfach, immer noch auf den alten (aber funktionalen Code) als Referenz für Ihren glänzenden neuen (aber kaputten Code) zuzugreifen. :-)

Answer 3

Verwenden Externals Definitionen (svn:externals Eigenschaft) Ihre Legacy-Code, wie Sie es einem Dritt Repository zu verweisen.

Dann können Sie Ihre Refactoring-Arbeit von Ihren abhängigen Projekten trennen und (mit festen Revisionsreferenzen, d. H. -r1234) sehr explizit angeben, von welcher Revision des Legacy-Codes das abhängige Projekt abhängt.

Answer 4

Hier ist Ihre kostenlose psychologische Analyse:

Was Sie hier haben, ist ein tief verwurzelte Wunsch, Ihren Legacy-Code zu beheben, so dass es nicht mehr Vermächtnis ist. Wenn Sie es verstecken, unterdrücken Sie nur dieses Verlangen und versuchen, es zu vermeiden, weil es ein unangenehmes Gefühl ist. Wenn Sie es im Freien lassen, wird eines von zwei Dingen passieren: Es wird Sie schließlich verrückt machen und Sie müssen sich umbringen, oder (optimistischer) Sie werden an jedes unordentliche Stück über und erinnert werden über, bis Sie schließlich zusammenbrechen und es aufräumen.

Sie das Chaos nicht verbergen; Putze es. Sonst kommt es zurück, um dich früher oder später zu beißen.

Answer 5

Es hängt davon ab, was Sie nennen Vermächtnis. Wenn du Vermächtnis sagst, meinst du wirklich "Code aus einer früheren Anwendung, der so schlecht ist, dass wir ihn nie mehr benutzen werden", sollte er von deinem aktuellen Code getrennt werden. Wenn es etwas von Ihrem aktuellen Projekt ist, aber von anderen Leuten geschrieben wurde oder nicht Ihren aktuellen Standards entspricht, behandeln Sie es normal, aber kennzeichnen Sie es für die zukünftige Faktorisierung in Ihrem Issue Tracker.