处理一个可以访问稳定但没有那么漂亮代码、很容易引入错误的大团队的最佳方法是什么?
我正在寻找类似于 SVN 锁定文件的东西。
如果您还没有单元测试,请编写单元测试。然后开始重构,并在每次提交时继续进行回归测试。
告诉他们别管它。
它有效,改变它除了美化它有什么好处(并且潜在的成本很高)所以你只需要解释成本/收益分析。
我希望您的开发人员足够聪明地理解这一点,如果没有,您可以使用源代码控制系统日志,紧紧卷起,将他们打死:-)。
Svn 确实具有锁定文件以防止并发访问的设置(类似于 Source Safe),但我建议围绕可怕的代码构建一些自动化单元测试和集成测试。希望您也有一个可靠的 QA 小组作为安全网。
编写自动化单元测试。如果您有测试您正在维护的代码的测试,您可以确信任何修改都没有破坏它。JUnit等测试框架可以提供帮助。
获取 Martin Fowler 的经典著作Refactoring并阅读它。特别注意代码气味的概念。这将为您指出有助于解决您的情况的特定重构。
获得一个内置重构支持的好 IDE。IDE 不会支持本书中的所有重构,但其中许多会有很多。Java 世界中的Eclipse和NetBeans是免费的,并且很好地支持重构。
考虑使用像Hudson这样的持续集成服务器来跟踪您的测试是否失败。
是的,锁定它,直到你可以为它写一个更易于维护的替代品。
Michael Feathers 关于遗留代码的书对于该团队来说是一本不错的读物。当然,说起来容易做起来难,但从长远来看,特定代码可能会成为您软件的设计债务。
在库中将其黑盒化,以免被弄乱。很好地记录界面。
生成完整的单元测试,这样如果它必须改变,你知道它仍然有效。
如果您有 Subversion,除非代码只是几个文件,否则锁定文件并不可怕。Subversion 不允许您锁定子目录,只锁定单个文件。加上锁可以被打破。
您可能想要的是一个预提交挂钩脚本。你几乎可以做任何事情,但我用它来限制对特定子目录的访问(分支、SQL 脚本)。此外,除非您有权访问服务器,否则您无法打破预提交挂钩。
请参阅有关实施存储库挂钩的版本控制与 Subversion书。Subversion 发行版应该包含一些很好的例子来说明如何做到这一点。
我的想法更像是重构,如果代码很难使用,那么它需要重做,这可能需要一些时间,但从长远来看它可能会更好,因为你不会引起那么多问题。
设置自动构建和单元测试。任何跟踪更改的存储库都是好的,但不会防止错误。
此外,只进行可以立即运行的更改。提早发布的敏捷方法通常在这里有所帮助。这样,随着您深入了解代码,您可以更好地理解代码。
基本上,如果可以的话,从不改变功能的重构开始。然后在重构的代码之上引入新功能。慢慢地做一些小的、有意识的改变。
在进行更改时锁定源可能不会像传达正在更改的内容和位置那样有帮助。你最好的方法是建立开放的沟通渠道。使用诸如 Slashcode 之类的东西建立一个论坛,在那里他们可以公开讨论问题并提出问题,并留下记录。