如何处理被认为有变化危险但仍然稳定的代码？

Question

处理一个可以访问稳定但不那么漂亮的代码的大团队的最佳方法是什么，这很容易引入错误？

我正在寻找SVN锁定文件的内容。

Answer 1

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

Answer 2

告诉他们不管它。

它有效，改变它的好处是什么，而不是让它变得更好（潜在的成本很高）所以你只需要解释成本/效益分析。

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

Answer 3

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

Answer 4

1. 编写自动单元测试。如果您有测试您正在维护的代码的测试，您可以放心，任何修改都没有破坏它。诸如JUnit之类的测试框架可以提供帮助。

2. 获取Martin Fowler经典着作Refactoring的副本并阅读。特别注意代码味道的概念。这将指向特定的重构，这将有助于您的情况。

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

4. 考虑使用Hudson之类的持续集成服务器来跟踪您的测试是否失败。

Answer 5

是的，锁定它，直到你可以为它写一个更易维护的替代品。

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

Answer 6

在图书馆中将其黑盒子，这样它就不会被搞乱。准确记录界面。

Answer 7

生成完整的单元测试，以便在必须更改时，您知道它仍然有效。

Answer 8

如果你有Subversion，除非代码只是几个文件，否则锁定文件并不是很严重。 Subversion不允许您锁定子目录，只锁定单个文件。锁定可以打破。

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

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

Answer 9

我认为更像是refacter，如果代码很难用，那么它需要重做，可能需要一些时间，但从长远来看它可能会更好，因为你不会导致很多问题

Answer 10

设置自动构建和单元测试。任何跟踪变化的存储库都是好的，但不会阻止错误。

此外，只进行可以立即运行的更改。敏捷方法说早期发布并且通常在这里有所帮助。这样，当您深入了解代码时，您可以更好地理解代码。

基本上，如果可以，请从不改变功能的重构开始。然后在重构代码之上引入新功能。通过小的，刻意的改变慢慢地做。

在进行更改时锁定源可能无助于传达正在发生变化的内容和位置。您最好的方法是建立开放的沟通渠道。使用像Slashcode这样的东西建立论坛，他们可以公开讨论事情并提出问题，并留下记录。