如何处理被认为更改危险但稳定的代码?[关闭]

如果您还没有单元测试,请编写它们。然后开始重构,并在每次提交时继续进行回归测试。

告诉他们别管它。

它是有效的,除了预先捆绑它之外,改变它的好处是什么(潜在成本很高),所以你只需要解释成本/收益分析。

我希望你的开发人员足够聪明,能够理解这一点,如果没有,你可以使用你的源代码控制系统日志,紧紧地卷起来,把它们打败:-)。

Svn确实有一个锁定文件以防止并发访问的设置(类似于源代码安全),但我建议围绕可怕的代码构建一些自动化的单元测试和集成测试。希望你也有一个坚实的QA小组作为安全网。

1. 编写自动化单元测试。如果你有测试你正在维护的代码的测试,你可以放心,任何修改都没有破坏它 JUnit 可以帮助。

2. 买一本马丁·福勒的经典著作 Refactoring 并阅读它。特别注意代码气味的概念。这将为您指出有助于解决您的情况的特定重构。

3. 获得一个内置重构支持的好IDE。IDE不会支持本书中的所有重构,但其中许多IDE会有许多重构。 Eclipse 和 NetBeans 在Java世界中是免费的,并且很好地支持重构。

4. 考虑一个持续集成服务器,如 Hudson 跟踪你的测试是否失败。

是的,锁定它,直到你能为它编写一个更易于维护的替代品。

Michael Feathers关于遗留代码的书将是该团队的一本好书。当然,说起来容易做起来难,但从长远来看,特定的代码可能会成为你软件的设计债。

把它放在图书馆的黑盒子里,这样它就不会被弄乱。记录好接口。

制作完整的单元测试,这样即使必须更改,你也知道它仍然有效。

如果你有Subversion,锁定文件并不可怕,除非代码只是几个文件。Subversion不允许锁定子目录,只允许锁定单个文件。此外,锁可能会被打破。

你可能想要的是一个预提交钩子脚本。你几乎可以做任何事情,但我用它来限制特定人员(分支、SQL脚本)对某个子目录的访问。此外,除非你有权访问服务器,否则你无法打破预提交钩子。

请参阅 Version Control with Subversion 有关…的书 Implementing Repository Hooks 。Subversion发行版应该包括一些如何做到这一点的好例子。

我的想法更像重构器,如果代码很难使用,那么就需要重做,这可能需要一些时间,但从长远来看可能会更好,因为你不会造成那么多问题。

设置自动构建和单元测试。任何一种跟踪更改的存储库都是好的,但并不能防止错误。

此外,只进行可以立即运行的更改。敏捷方法论说尽早发布通常会有所帮助。这样,随着您对代码的深入了解,您可以更好地理解代码。

基本上,如果可以的话,从不改变功能的重构开始。然后在重构的代码之上引入新功能。慢慢地做一些小的、深思熟虑的改变。

在进行更改时锁定源代码可能没有传达更改的内容和位置那么有帮助。你最好的方法是建立开放的沟通渠道。使用Slashcode之类的东西建立一个论坛,在那里他们可以公开讨论事情,提出问题,并留下记录。