处理一支拥有稳定但没有那么漂亮的代码且易于引入错误的大团队的最佳方法是什么？

我正在寻找一些与SVN锁定文件的方式。

解决方案

我在想的更像是refacter，如果代码难以使用，则需要重做，这可能需要一些时间，但从长远来看，可能会更好，因为我们不会引起太多问题。

是的，锁定它，直到我们可以为其编写更易于维护的替代品为止。

迈克尔·费瑟斯(Michael Feathers)的有关遗留代码的书对于该团队来说是一本好书。当然，说起来容易做起来难，但是从长远来看，特定代码可能成为我们软件的设计债务。

Svn确实具有锁定文件的设置以防止并发访问(类似于Source Safe)，但是我建议围绕可怕的代码构建一些自动化的单元测试和集成测试。希望我们也有一个可靠的质量检查小组作为安全网。

将其黑匣子存储在库中，这样就不会被弄乱。妥善记录接口。

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

进行完整的单元测试，以便在必须进行更改时知道它仍然可以工作。

告诉他们别管它。

它起作用了，而不是修改它(除了潜在的成本很高)之外，还有什么好处，所以我们只需要解释成本/收益分析。

我希望开发人员足够聪明，能够理解这一点，如果不能，我们可以使用紧密汇总的源代码控制系统日志，将其打死：-)。

• 编写自动化的单元测试。如果我们有测试可以测试要维护的代码，则可以确信所做的任何修改都不会破坏代码。测试框架(例如JUnit)可以提供帮助。
• 获得马丁·福勒(Martin Fowler)的经典著作《重构》并阅读。特别注意代码气味的概念。这将为我们指出可以解决情况的特定重构。
• 获得一个内置了重构支持的优秀IDE。IDE将不支持本书中的所有重构，但是其中很多都会有很多重构。 Java世界中的Eclipse和NetBeans是免费的，并且很好地支持重构。
• 考虑使用像Hudson这样的连续集成服务器来跟踪测试是否失败。

如果我们有Subversion，除非代码只是几个文件，否则锁定文件并不是很困难。 Subversion不允许我们锁定子目录，而只能锁定单个文件。再加上锁可以被打破。

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

请参阅有关实现存储库挂钩的"带Subversion的版本控制"书。 Subversion发行版应该包含一些很好的例子来说明如何做到这一点。

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

另外，仅进行可以立即运行的更改。表示早期发布的敏捷方法论经常在这里有所帮助。这样，我们可以对代码进行更深入的了解。

基本上，如果可以的话，请从不改变功能的重构开始。然后在重构代码之上引入新功能。进行细微而刻意的更改，请慢慢执行。

在进行更改时锁定源可能不会像传达更改内容和更改位置那样有用。最好的方法是建立开放的沟通渠道。使用Slashcode之类的网站建立论坛，他们可以公开讨论问题并提出问题，并保留记录。