保留旧代码以供参考的惯例是什么？

Question

我有一个相当新的小团队项目和一个新团队，我们尝试了一些不同的方法，并在设计中进行了一些重要的迭代。

我们有一些不应该使用的类和一些具有ClassStuff和ClassStuffImproved等混乱的类。我们有SVN，但我认为没有把所有的垃圾拿到手上并且让人们在历史上手工挖掘是有效的。有些事情可能需要重新正确实施，之前的不良实施将提供参考。但是我想打破任何依赖于垃圾的东西。即使这些垃圾文件被破坏，我也希望项目能够构建。

是否有文件夹约定？我是否应该将所有核心内容放入文本文件中，以便当有人想知道课程的位置时，至少可以轻松搜索到这些内容？

这里的典型惯例是什么？

Answer 1

我不确定是否有约定，在我的项目中，我只是将其复制到一个名称为的新版本中：

MyClass2.java

这样我在导入旧版源文件时就不会遇到麻烦了。我还用MyClass.java评论了/* ... */的全部内容。在一段合理的时间后，我放弃了旧的MyClass版本并将MyClass2留在项目中。我将其保留为MyClass2，因此它声明此文件具有历史记录，并且它是我班级的更高级版本，因此为该过程带来了一点乐趣。

我从未见过有人这样做，但这种做法看起来非常直观。

Answer 2

我使用TortoiseSVN的Repository Browser保留了SVN历史记录。如果您有最新的SVN服务器，“移至”，“复制到”和“重命名”等操作会将历史记录日志保留为原始日志。确保在这些更改后更新所有签出（否则本地更改将很难与新服务器实际合并）。

您不再使用的文件可以移动到“博物馆”或“阁楼”分支（并尝试将原始目录结构保留在那里）。

Apache项目一直在更改软件包名称，以指示与先前版本或多或少相冲突的新版本（例如，将commons-lang 2.6与3.2进行比较）。在SVN中，您只需重命名主干中的目录即可。我发现它是一个很好的约定：所有依赖于旧版本的代码都会中断，但可以通过在import语句中添加一个字符来轻松更新（当然，通过阅读更新的Apidocs，您可以验证新版本是否按预期工作）。

根据我的经验，重新实施垃圾比第一眼看上去更难。我首先在类级别使用@Deprecated注释用于需要替换的类。您的IDE将清楚地显示已弃用代码的使用位置，编译器将显示警告。在包“版本2”中创建重新实现。然后，您可以更新，就像从commons-lang版本2更新到commons-lang版本3.完成所有操作后，删除不推荐使用的类（或包）。
在删除不推荐使用的类时要小心：上次我尝试删除已弃用的类时，我发现在一个有点旧的，但是关键且经过严格测试的程序中依赖于已弃用的类，并且必须保留已弃用的类保持向后兼容性的地方。