敏捷开发之结对编程最佳实践

         讲到结对编程，我想大家首先想到的是XP极限编程中描述的，两位程序员并排坐在一台电脑前，面对同一个显示器，使用同一个键盘，同一个鼠标一起完成编码工作 。这种编程方式为众多敏捷爱好者所向往，但实际工作中尝试采用的却寥寥无几，究其原因：喜的是它可以提高代码质量，增进沟通，并起到传帮带的作用；忧的是它需要投入更多的资源，灵活性不强。结对编程和传统编程模式有着很大不同，对程序员的能力也有着更高的要求，要求结对双方高度集中注意力，保持步调、思维一致。

如何做才能既享受结对编程带来的好处，而又能有效的避免相应的影响呢？本文阐述了实际项目过程中的一些结对编程的实践活动，希望可以给读者一定的启示。

 

1、结对认领任务

         项目启动后，开发人员两两结对，共同认领开发任务，作为owner，他们相互协作，一起对所承担的开发任务负责。在需求理解、设计阶段双方一起设计和讨论，编码阶段独立实现。对过程中发现的问题，随时进行沟通和讨论，通过这种小范围、高效的沟通，解决项目中的绝大部份问题。从而，实现更高的开发效率和代码质量。

         结对成员一般由一位能力强、经验相对丰富和一位相对欠缺的工程师配对，能在一定程度上形成互助、互补；结对小组认领的任务模块在不同迭代中进行交替轮换，让项目组成员对项目的所有模块功能、代码都比较的熟悉，提升开发团队的战斗力。

通过结对认领任务的活动，结对成员在需求理解、设计思路上充分的沟通和讨论，尽早的发现和解决问题，避免因需求理解偏差、设计问题造成返工。对于新员工或经验稍微不足的开发人员，通过经常性的沟通和讨论，能迅速的进入角色并积累经验，发挥了传帮带的作用。此外，结对成员之间互为backup，当有一方因故资源不能保证时，另一方就能非常顺利地接手遗留下来的任务，减少项目风险。

 

2、交叉单元测试

         我们知道单元测试是众多敏捷实践的基石，无论是重构还是持续集成都离不开单元测试。因此，如何做好单元测试就显得尤为重要。在实际项目过程中，我们会更多关注功能实现的进度和质量，而忽略了对单元测试完成情况及质量跟进。

         交叉单元测试活动指的是结对双方对共同认领的开发任务进行更进一步的分工，一方负责某些任务业务功能的实现，另一方就负责完成对应功能的单元测试。每个人在项目中既会承担功能实现部分，也会承担单元测试部分，通过任务墙上的小卡片分别对这两部分任务进行进度跟踪。

相比传统的一个人同时负责功能实现和单元测试，交叉单元测试可以加强大家对单元测试的重视程度，提高单元测试的覆盖率，同时在编写单元测试过程中，必然会去了解对方的实现代码，这样也能尽早发现业务逻辑、代码设计上存在的问题。

图1：交叉单元测试

 

3、交叉代码审查

        通过代码审查(code review)，可以帮助我们提高代码质量和编码规范。交叉代码审查活动，是代码审查的一种组织形式，结对双方在完成或部分完成编码和单元测试后，相互交叉审查对方在本次迭代中所实现的所有代码，以发现代码中的编码规范及业务逻辑问题或潜在隐患，并且确保提出的问题得到妥善解决。

其他常见代码审查形式有很多种：比如集体review，组织项目成员一起到会议室，一人通过投影仪展示并讲解自己写的代码，其他成员一起寻找代码中可能存在的问题，并由专人记录所发现的问题，会后发出代码审查报告并安排修复解决。我们早期也曾多次采用这种方式来做代码审查，但总体效果不太理想，所发现的问题多数是编码规范上的，而很难发现深层次的业务逻辑问题。究其原因，大家认为review过程中思路跟不上讲解代码的人，且容易走神，所耗时间长而效果不佳；再有一种，项目组成员分头review，审查本迭代中除自己提交以外的代码，这种review形式工作量较大且没有重点，容易遗漏。

相比上述的代码审查形式，交叉代码审查由于结对双方在需求理解、设计编码阶段就有充分的沟通和讨论，对所需审查代码的业务逻辑较为熟悉，并且审查的代码和文件相对明确且数量适当。因而，交叉审查可以使review更加充分和细致，更重要是可以根据自己的时间安排随时开展，表现出更灵活、高效的特点。

         在做代码审查时，可以结合一些工具，比如Jupiter，ReviewClipse等eclipse插件，简单方便的提交、跟踪和解决审查的问题，提高代码审查效率。目前，我们结合团队的需要，采用自己开发的review工具Tala（现已release了第一个版本，正在技术团队中试用，后续也会考虑开源）。我们用此工具记录review中发现的问题，不仅可以方便跟踪，还可以按项目、问题类型等维度进行统计，通过定期的问题回顾，避免一些典型问题重复出现。工具主要视图如下：

 

图2：需要review的文件列表视图

 

图3：code review问题列表视图

 

图4：记录code review问题视图

 

         上述活动为我们正在尝试的结对编程实践中的三个重要活动，我们认为通过这些活动，可以有效的避免了XP中结对编程投入成本高、约束性大（需双方同时集中精力）等问题，同时，又获得了结对编程带来的好处，主要有如下几点：

         1)、提升代码质量；

         2)、通过充分的沟通和交流，成员间起到传帮带的作用；

         3)、互为backup，减少产品(项目)风险；

         读到这里，可能很多读者会有一个疑惑，那什么样的开发人员适合结对呢？并非所有的人都适合做结对，至少参与结对的开发人员应具备独立思考和解决问题的能力，并且具备较好的团队协作意识。否则，不仅不能带来结对的好处，反而引起一些新的问题。

         敏捷的实践不尽相同，没有什么实践活动可适用于所有团队，我们需要根据实际情况和客观条件，选择适合的实践活动，并在实践中不断的改善和调整，形成自己团队的最佳实践。本文所阐述的结对编程最佳实践亦是如此，我们认可的最佳实践也许未必适合你的团队，但我们希望通过本文可以给大家带来一些新的思考和尝试，相信通过你的努力，同样可以找到你的最佳实践。最后，欢迎广大敏捷爱好者联系我们，共同探讨敏捷项目管理实践。

 

        ps：最后非常感谢建法对此文的审阅和修订。