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