《敏 捷 教 练：如何打造优秀的敏捷团队》—11.2 集体代码所有权

11.2  集体代码所有权

和团队谈谈，尝试一下集体代码所有权，即任何团队成员可以编辑任意代码。这样一来，任何一名开发人员都可以开始下一个故事的工作，不必等原来编写代码的人空出来。团队协作是发挥集体代码所有权的重要组成部分。协作程度若不到位，开发人员可能会各自背道而驰还不自知。留意团队开发人员之间的交谈深度(the level of conversation)。如果他们相互间不说话，这个苗头说明他们的工作可能没有关联。没有硝烟的战斗可能正在代码中上演：每个开发人员都按照自己的品位重写代码，结果就是东拼西凑而成的破棉被。你的挑战在于如何让“团队”联手，像一个真正的团队那样工作，而不是敢怒不敢言。

编码风格

团队若能遵循一致的设计和编码风格，集体代码所有权就比较容易实现。我们并不是说他们需要创建一份正式的编码标准文档。建立一个所有人均认同会遵守的“排字规格”(house style)[1]即可。

带领整个团队一起明确编码风格。这可是一个很艰巨的辩论。至于哪种风格最好，并没有标准答案，开发人员往往对代码布局有强烈的个人偏好，这取决于他们是如何学习编程的。不过，这个值得推动，因为只要团队能保持一致的风格，他们的代码就会更具可读性，了个人口味而重塑代码格式所浪费的时间也会少很多。可以使用同意梯度(参见2.4节)来确定你们是否已有足够共识，可以遵循提出的所有指导原则。或者更简单一点，就像我们这个故事里的团队那样，来一次拇指投票。

团队同意一些编码准则

团队聚集在他们的新白板周围。Joe站起来，清了清嗓子：“好吧，我召集这次会议，是想我们能够开始清理我们的代码。”

他走到白板前，拿起一支记号笔。“让我们先从一些大家都同意遵守的风格准则开始吧。”

Damian翻了翻白眼：“我们就这么没事干，还要讨论花括号放在哪里这种事？”Joe提醒团队：“上次回顾会议上，我们谈到了要清理代码。我们必须立刻统一采取行动，否则新代码会变得跟PLib一样糟糕。”

Joe满怀期待地环顾团队一周：“谁手头有你认为值得我们所有人遵循的一份准则？”

Larry凝视着窗外，眼神阴郁。Joe点名问他：“Larry，你在想什么呢？”Larry慢慢回过神。“当然，我希望我们能定下来如何命名测试。一些人用Test开头，其他人以Test结尾，我觉得这样太过随意。虽然我个人没有偏好，但是如果我们能选定一个坚持下去，做测试会更容易一些。”

Damian看似有些诧异：“对！这对我来说很重要。”

 “有其他反对意见吗？”Joe一边问一边在板上写下“从今以后，我们应该用Test×××命名我们的测试类，不是×××Test。“好的，让我们来一个拇指投票。”Damian说，“这个非常容易！”接着就竖起了他的大拇指。

Larry和Joe也举起大拇指。Damian看着Rebecca：“那样你可以接受吗？”她点点头，举起她的大拇指。然后，她脱口而出：“所有函数都要做到尽可能短，这个准则如何？这将有助于我们确保每个函数只做一件事情。你知道，就像Bob大叔在他的《代码整洁之道》[2]一书中说的一样。”

Damian向后靠坐在椅子上，嘴里咬起笔来：“这听起来不错，但我会投平放大拇指，除非我知道你说‘短’是什么意思。”

Rebecca沉思片刻，然后说：“大学时我们学过，一个函数长度不能超过屏幕的可视范围。但我们现在有了更大的显示器。因此我认为我们需要制定比现在的屏幕更少一些的代码行规则，以便每个函数只做一件事情。”

Joe再次拿起记号笔：“那我们决定代码不超过多少行呢？”

Rebecca挠了挠下巴，然后建议说：“我们所有的函数都不应该超过10行，怎么样？”

Damian皱了皱眉头：“我不是很肯定。记住，有些老PLib代码中，有些行相当长。”

Larry点点头。“有些函数超过200行，不打印出来真的很难知道它们做了什么，因为一屏显示不全。”

“我给你一个建议，”Joe一边说一边在白板上写上：“任何新的函数都应该少于10行”。“这听起来怎么样？”每个人都举起了自己的大拇指。

Damian往前靠了靠：“我们还可以使用我们的静态分析工具包进行度量。这样我们就能看到这些编码规范是否有差别。如果我们遵循这些规范，那么长函数的数量应该每周都会减少，并且我们可以图的方式化显示出来。”

“你会开始着手于此事？”Joe问。

Damian拿出一张索引卡，写了一个任务放到团队板上。“当然！我一直在做这些调研工作，想看看有什么是我们可以使用的。也许我们还可以把它挂接到我们的CI构建里面去。”

“在你把CI构建弄好之前，我愿意去打印这些统计，再放到我们团队的白板上。”Rebecca补充说。

一旦团队有了新的编码准则，就鼓励他们讨论这个问题：“基于选择的基准来度量进展情况，这样做是否重要？”

在我们的例子中，团队计划要运行一个静态分析工具来统计有多少函数超过10行代码。注意，产生太多数据，除了制造噪音之外，不会有任何帮助。帮助团队想清楚如何处理这些新信息。他们可以把结果绘制成图表钉到团队板上，或是用一个构建显示器屏幕进行动态显示。

保持结果的可视化能提醒大家不忘记约定，还能展示他们的遵守情况。几个星期或者几个月以后，团队应该会发现他们已经有所提高，不再需要绘制有关长函数数量的图表了。但如果形势的变化不如预期，团队就需要了解原因。团队回顾会议就是讨论此问题的良机。

与专家共事

虽说让团队商定一致编码风格听起来让人觉得就是采用集体代码所有权最难的部分，但是实际上，让团队开发人员停下来不再专攻他们心中的代码“自留地”，更是难上加难。交给曾做过某个模块的人来修复它的任何缺陷或是增加更多相关特性都会更快一些，但这样做会造成安排上的瓶颈。

术业专攻还会导致团队互相讨论设计的必要性降低，只有受阻时才会寻求帮助。你会看到，如果他们选择了这种专攻方式，开发人员彼此之间就会不愿意再多说一句话。结对编程可以预防这种情况的发生。我们合作过的一些团队遵循的是一个简单的规则，每天必须更换结对中的一个人。这样能督促团队所有人多轮岗几个用户故事，而不是钉牢一个就不动了。

修复破窗

还需要密切关注，别让集体代码所有权降级为开发人员放弃自己对代码的职责。在《程序员修炼之道》一书中，安迪·亨特(Andy Hunt)和戴夫·托马斯(Dave Thomas)谈到“破窗”理论。不关注代码的微妙迹象可能会导致更大的过错。

尝试运用我们提过的PrOpER教导循环(参见1.4节“如何开始教导”)。跟开发人员谈谈，和代码相关的哪些事情最让他们感到困扰。可能需要单独和他们聊，了解他们内心深处的顾虑。可能是因为某一段代码特别糟糕，或者是团队在某个设计问题上有冲突。或者，该团队接手了一个老旧杂乱无章的代码基，被清理任务压得喘不过气来。协助他们针对清理代码制定一个行动计划。只要能认识到问题并把它分解成一小块一小块，就可以使情况大为改观，有助于已放弃的开发人员重新投入进去。