转向代码所有制

在我最近的代码所有制 文章中，我描述了我对代码所有制问题的看法。我的许多软件开发朋友都是极限编程的拥护者，并且倾向于集体代码所有制。然而，这类实践并非绝对的，应该始终根据当地情况进行调整。我的一位同事给我发了一封邮件，其中讲述了一个故事，我认为这个故事很好地说明了什么时候必须改变你的实践，即使你是XP的忠实粉丝。（由于他谈论的是他的团队，所以他希望匿名。）

为了应对一些开发人员的不规范编程，我将我们团队从“集体”模式转变为“弱”模式。结合一些相当坦率的反馈，结果是速度有所提高，因为现在“拥有”我们关键代码区域的程序员不必再不断地修改不合格的代码，而那些在这些关键区域做着不合格工作的程序员则在做一些诸如错误查找和低风险代码更改之类的事情——这进一步解放了其他人。

我们的士气也有所提高，因为除了那些不合格的代码生产者之外，每个人都对不得不检查他们每次提交的代码并修复他们没有及时发现的问题感到沮丧。这种改变奖励了那些认真对待质量、TDD、非投机等的人。

但是，我们还需要一些额外的实践和政策来进行平衡

- 更频繁地交换结对编程伙伴（我们实际的政策是，你仍然可以处理代码的任何部分，但如果它不在你“自由发挥”的区域内，你需要与在那里“自由发挥”的人结对编程，或者先让他们仔细审查你的想法）

- 回归的途径是通过所有者。如果他们对你的代码质量感到放心，你就可以在那里自由地接手任务。

- 如果情况没有改善，那么我们将不得不采取进一步的措施。

这对我来说是非常有教育意义的，因为我以前从未走到过这一步，而且我真的不愿意“扮演严厉的角色”。对我来说，引入指导性而不是赋能性的实践真的很困难，但从那以后情况已经有了很大的改善。

这种本地化调整是极限编程或任何敏捷方法的重要组成部分。在所有条件都相同的情况下，我的同事仍然更喜欢集体代码所有制，但所有条件很少相同。