TFS结帐锁定最佳做法

Question

我很难说服组织中的其他人在结帐时停止随意锁定文件。在哪里可以找到解释为什么应谨慎使用结帐锁定的“官方”文档的任何想法？ Microsoft建议:

As a best practice, use the Lock type option with discretion and notify your teammates why you are locking an item, and when you plan to remove the lock.

但不赘述。

我可以指出的任何内容都会非常有帮助。

Answer 1

尽管我没有Microsoft的官方消息，但我是Application Lifecycle Management的MVP，所以希望这足以使它引人注目。 :)

结帐时锁定文本文件(即代码)可能会严重阻碍生产力。我曾经在同事不在的时候亲眼看到过它，并且他们对文件拥有独占锁定。突然之间，这是个令人费解的时间。当您尝试对时间紧迫的问题进行故障排除或修复时，情况甚至更糟。

人们想要锁定文件以进行独占编辑的最常见原因是，他们不想以后再进行困惑的合并。

这通常是一件事或多件事的症状:

排他地锁定的文件太大(一个文件中包含很多类，一个“神类”做太多事情，等等)。解决此问题的方法是根据“单一职责原则”将代码重构为更小，更隔离的类。或者，如果绝对必要，并且您正在.NET领域中工作，请滥用partial关键字将同一类拆分为多个文件，尽管我想继续记录并声明每次在以下情况下看到此内容:代码库使我哭泣无穷。

排他锁定的文件正在进行长期的重大重构。此处的解决方案是隔离分支内的主要更改，并频繁地对从主干到分支的更改进行反向集成。

进行更改的人不喜欢合并。我帮不了你。如果您坚持提交代码的时间不够长，以至于合并会很痛苦，那么您提交代码的频率就不会足够高。如果您由于尚未完成代码而没有提交代码，但是更改正在进行中，并且您不想干扰其他人的工作，那么您就没有正确使用分支。

有时候，对代码文件的排他锁既好又有用吗？可能吧，但是我想不出一个问题，该问题解决了使用其他更合适的源代码控制功能无法解决的问题。

如果可以，请使用“本地”工作区，因为它们不强制执行排他锁。