您如何对待遗留代码（和数据）？

Question

我目前正在重组我的本地 Subversion 存储库，方法是添加一些新项目并将旧存储库中的遗留代码和数据合并到其中。

当我过去这样做时，我通常会将遗留代码放在专用的“遗留”文件夹中，以免“干扰”新的且“结构良好”的代码树。然而，本着重构的精神我觉得这有些不对。理论上，遗留代码会随着时间的推移而被重构并移动到新位置，但实际上这种情况很少发生。

您如何对待您的遗留代码？尽管我很想把旧罪孽藏在“遗产”文件夹中，永远不再看它，但在某种程度上，我希望通过强迫它生活在存储库中更“健康”的居民中，也许遗产代码有一天会有更好的机会康复吗？

（是的，我们都知道 我们不应该重写东西, ，但这是我的“有趣”存储库，而不是我的商业项目......）

更新

我并不担心跟踪各种版本的技术问题。我知道如何使用标签和分支。这更多的是一个心理方面，因为我更喜欢存储库中有一个“整洁”的结构，这使得人类更容易导航。

Answer 1

总有一天，所有代码都会成为“遗留”代码，为什么还要将它们分开呢？源代码控制是按项目/分支或项目/平台/分支以及该类型的层次结构进行的。谁在乎牙齿有多长？

Answer 2

标记是颠覆中非常便宜的操作。当您开始重构时以及在重构过程中的常规阶段标记您的代码。这样，仍然可以轻松访问旧的（但功能正常的代码）作为闪亮的新代码（但损坏的代码）的参考。:-)

Answer 3

这是您的免费心理分析：

您有一种根深蒂固的愿望，希望修复您的遗留代码，使其不再是遗留代码。当你把它藏起来时，你只是在压抑这种欲望，试图避免它，因为这是一种不舒服的感觉。如果您将其公开，则会发生以下两种情况之一：它最终会让你发疯，你将不得不自杀，或者（更乐观地），你会一遍又一遍地想起每一个混乱的部分，直到你最终崩溃并清理它。

不要隐藏混乱；打扫。不然迟早它会回来咬你。

Answer 4

这取决于你叫什么 遗产. 。如果你所说的遗留实际上是指“来自某个已退役应用程序的代码，这些代码太糟糕了，我们永远不会再使用它”，那么它应该与你当前的代码分开。如果它是来自您当前项目的内容，但由其他人编写或不符合您当前的标准，请正常对待它，但将其标记为将来在问题跟踪器中重构。

Answer 5

使用 外部定义 (svn:外部 属性）来引用您的遗留代码，就像引用第三方存储库一样。

然后，您可以将重构工作与依赖项目分开（使用固定修订参考，即-r1234）非常明确地了解依赖项目所依赖的遗留代码的哪个版本。