Wie gehen Sie mit Legacy-Code (und Daten) um?

Question

Ich bin derzeit dabei, mein lokales Subversion-Repository umzustrukturieren, indem ich einige neue Projekte hinzufüge und Legacy-Code und Daten aus einigen älteren Repositorys darin zusammenführe.

Wenn ich dies in der Vergangenheit getan habe, habe ich den Legacy-Code normalerweise in einem speziellen „Legacy“-Ordner abgelegt, um den neuen und „gut strukturierten“ Codebaum nicht zu „stören“.Allerdings halte ich das im Sinne des Refactorings für etwas falsch.Theoretisch wird der Legacy-Code im Laufe der Zeit umgestaltet und an seinen neuen Speicherort verschoben, in der Praxis kommt dies jedoch selten vor.

Wie gehen Sie mit Ihrem Legacy-Code um?So sehr ich versucht bin, alte Sünden im „Legacy“-Ordner zu verstauen und nie wieder darauf zu schauen, so hoffe ich doch, dass ich es in gewisser Weise dazu zwinge, unter den „gesünderen“ Bewohnern im Repository zu leben, vielleicht das Legacy Code wird eines Tages bessere Chancen haben, gesund zu werden?

(Ja, das wissen wir alle Wir sollten nichts umschreiben, aber das ist mein „Spaß“-Repository, nicht meine Geschäftsprojekte ...)

Aktualisieren

Ich mache mir keine Sorgen über die technischen Aspekte, die es mit sich bringt, den Überblick über verschiedene Versionen zu behalten.Ich weiß, wie man dafür Tags und Branches verwendet.Dies ist eher ein psychologischer Aspekt, da ich eine „ordentliche“ Struktur im Repository bevorzuge, die die Navigation im Repository viel einfacher macht – für Menschen.

Answer 1

Der gesamte Code wird eines Tages „veraltet“. Warum sollte man ihn dann überhaupt trennen?Die Quellcodeverwaltung erfolgt nach Projekt/Zweig oder Projekt/Plattform/Zweig und dieser Art von Hierarchie.Wen interessiert es, wie lange der Zahn im Zahn ist?

Answer 2

Tagging ist eine sehr kostengünstige Operation in Subversion.Markieren Sie Ihren Code, wenn Sie mit dem Refactoring beginnen, und in regelmäßigen Phasen, während Sie damit fortfahren.Auf diese Weise ist es einfach, weiterhin auf den alten (aber funktionsfähigen Code) als Referenz für Ihren glänzenden neuen (aber defekten) Code zuzugreifen.:-)

Answer 3

Hier ist Ihre kostenlose psychologische Analyse:

Was Sie hier haben, ist der tief verwurzelte Wunsch, Ihren Legacy-Code so zu reparieren, dass er kein Legacy mehr ist.Wenn du es versteckst, unterdrückst du nur dieses Verlangen und versuchst es zu vermeiden, weil es ein unangenehmes Gefühl ist.Wenn Sie es offen liegen lassen, passieren zwei Dinge:Es wird dich irgendwann in den Wahnsinn treiben und du musst dich umbringen, oder (optimistischer) du wirst immer wieder an jedes schmutzige Stück erinnert, bis du es schließlich aufbrichst und aufräumst.

Verstecken Sie das Chaos nicht;Putze es.Sonst kommt es früher oder später wieder und beißt Sie.

Answer 4

Es kommt darauf an, wie Sie anrufen Vermächtnis.Wenn Sie mit Legacy wirklich „Code aus einer veralteten Anwendung meinen, der so schlecht ist, dass wir ihn nie mehr verwenden werden“, sollte dieser von Ihrem aktuellen Code getrennt werden.Wenn es sich um etwas aus Ihrem aktuellen Projekt handelt, das aber von anderen Leuten geschrieben wurde oder nicht Ihren aktuellen Standards entspricht, behandeln Sie es einfach normal, markieren Sie es jedoch für eine zukünftige Überarbeitung in Ihrem Issue-Tracker.

Answer 5

Verwenden Externe Definitionen (svn:externals -Eigenschaft), um auf Ihren Legacy-Code zu verweisen, wie Sie es bei einem Drittanbieter-Repository tun würden.

Dann können Sie Ihre Refactoring-Arbeit von Ihren abhängigen Projekten trennen und (unter Verwendung fester Revisionsreferenzen, d. h.-r1234) geben Sie sehr deutlich an, von welcher Revision des Legacy-Codes das abhängige Projekt abhängt.