我目前正在重建我的本地Subversion存储库,通过添加一些新项目并将遗留代码和数据从几个较旧的存储库合并到其中。
当我在过去这样做时,我通常将遗留代码放在专用的“遗留”文件夹中,以免“干扰”新的和“结构良好”的代码树。但是,本着重构的精神,我觉得这有点不对劲。从理论上讲,遗留代码将随着时间的推移重新构建并移至新位置,但实际上很少发生这种情况。
您如何对待遗留代码?尽管我觉得想要把“遗留”文件夹中的旧罪孽收起来,但永远不要再看一遍,在某种程度上我希望通过强迫它生活在储存库中更“健康”的居民中,也许是遗产代码有一天会有更好的成功机会吗?
(是的,我们都知道we shouldn't rewrite stuff,但这是我的“有趣”存储库,而不是我的商业项目......)
更新
我并不担心跟踪各种版本的技术方面。我知道如何使用标签和分支。这更像是一种心理方面,因为我更喜欢在存储库中拥有一个“整洁”的结构,这使得人类的导航变得更加容易。
答案 0 :(得分:4)
有一天所有代码都变成了'遗产',为什么要把它分开呢?源控件是由项目/分支或项目/平台/分支以及该类型的层次结构。谁在乎它的牙齿有多长?
答案 1 :(得分:2)
标记是颠覆中非常便宜的操作。在开始重构时以及在常规阶段标记代码。这样,仍然可以轻松地访问旧的(但功能代码)作为您的闪亮新(但破坏的代码)的参考。 : - )
答案 2 :(得分:1)
使用外部定义(svn:externals属性)来引用您的旧代码,就像使用第三方存储库一样。
然后,您可以将重构工作与依赖项目分开,并且(使用固定修订引用,即-r1234)非常明确依赖项目所依赖的遗留代码的哪个版本。
答案 3 :(得分:1)
这是你的自由心理分析:
你在这里有一个根深蒂固的愿望,即修复遗留代码,使其不再是遗产。当你把它藏起来时,你只是压抑那种欲望,试图避免它,因为这是一种不舒服的感觉。如果你把它公之于众,就会发生以下两种情况之一:它最终将驱使你疯狂,你将不得不自杀,或者(更乐观地),你会被提醒每一个凌乱的东西直到你最终崩溃并清理它。
不要掩饰一团糟;打扫。否则它迟早会回来咬你。
答案 4 :(得分:1)
这取决于你所谓的遗产。如果说遗留你真的意味着'来自某个退役应用程序的代码非常糟糕,我们将永远不再使用它'它应该与你当前的代码分开。 如果它是您当前项目中的内容,但是由其他人编写或者不符合您当前的标准,则只需正常处理,但将其标记为将来在您的问题跟踪器中进行重新分解。