原文： ShiftingToCodeOwnership 敏捷 2006年5月15日 Bliki 索引
在最近那篇 代码所有权的帖子中，我描述了一下对代码所有权问题的思考。在软件开发行业里，我有不少朋友都是极限编程实践者，他们都对集体代码所有权偏爱有加，但推行代码集体所有并不是绝对的，往往需要根据对局部具体情况的考量做出调整。我的一位同事发给我下面这个实例，我觉得是对我们何时需要做出权变的一个很好的提示——哪怕你是一位XP的忠实粉丝。（他喜欢匿名谈论他的团队。）
为了抵控几位训练不足的开发者的不规矩行为，我把我们的团队从集体代码所有权调转成了弱代码所有权。一些公正可靠的反馈表明，这个调转提升了开发速度，因为现在“拥有”核心代码的程序员无需再为那些不关键代码不断操心了，而原来在那些关键部分却做着非关键工作的程序员则可以转做bug追踪之类的低风险代码修改工作——这也反过来促进了其他人的工作。
另外一份净收益是在团队士气的提升上。以之前的做法，除了那些做非关键工作的程序员，其他人在每次提交他们的代码时都不得不提防着会不会被一些没及时发现的问题纠缠一番，迟早被弄得身心俱疲。调转之后，实际上是褒奖了那些具备认真对待代码质量、TDD、不存侥幸投机心理等优秀品质的程序员。
然而，我们还需要另外一些实践及策略方面的权衡：
另外一份净收益是在团队士气的提升上。以之前的做法，除了那些做非关键工作的程序员，其他人在每次提交他们的代码时都不得不提防着会不会被一些没及时发现的问题纠缠一番，迟早被弄得身心俱疲。调转之后，实际上是褒奖了那些具备认真对待代码质量、TDD、不存侥幸投机心理等优秀品质的程序员。
然而，我们还需要另外一些实践及策略方面的权衡：
- 更频繁的结对拍档切换（我们实推的策略是：你仍然可以修改所有代码片断，但在那些别人比你自己更能“玩得转”的地方，你就需要跟他们结对，或者先把你的思路详细地告诉他们）。
- 回归集体所有制的路线就是切换所有者。如果他们觉得你的代码没啥可挑剔的了，你就可以当仁不让地着手那里的任务了。
- 要是事情还不见什么改善，那我们必须采取进一步措施。
这种局部调整策略是极限编程乃至所有敏捷方法的一条精华思想。我的同事们仍然偏爱代码集体所有，这是相同的，然而，世事往往不尽相同。
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
