结对编程开发

结对方法在敏捷中的应用

上一期我们谈到了敏捷初期的遇到的一些问题：人员水平参差不齐，缺陷周期长，team之间的沟通差。那么怎么解决这些问题呢？我们从结对编程得到了一些启发。将结对编程的“结对”概念拓展一下不仅应用到编程上，也应用到测试上面，以及需求讨论等各个方面。...

上一期我们谈到了敏捷初期的遇到的一些问题：人员水平参差不齐，缺陷周期长，team之间的沟通差。那么怎么解决这些问题呢？从结对编程得到了一些启发。结对编程是两个开发结成一对共同开发。那么我们将结对编程的“结对”概念拓展一下不仅应用到编程上，也应用到测试上面，以及需求讨论等各个方面来解决不同的问题。

比如开发和开发结对来解决开发人员水平参差不齐的问题；开发和测试结对来解决defect生命周期过长的问题；以及不同team的开发测试结对来解决沟通成本太高的问题等。下面逐一讲解：

开发之间的结对

开发和开发之间的结对（结对编程）来解决任务失衡，将不同level的开发两两组合到一起，分成不同的小组，来完成一个任务，等任务完成后，我们还将不同的小组聚集到一起做codereview。这么做就是在结对编程的基础上，加上了groupcode review。

这么做，

程序员互相帮助，互相教对方，可以得到能力上的互补。
可以让编程环境有效地贯彻Design。
增强代码和产品质量，并有效的减少BUG。
降低学习成本。一边编程，一边共享知识和经验，有效地在实践中进行学习。
在编程中，相互讨论，可能更快更有效地解决问题。

子曰：三人行必有我师，其实两人行也可能有。在我们的项目里，有一个非常让人印象深刻的例子，在做groupcode review的时候技术大牛从应届毕业生的代码里受到的启示，提前拦截了一个defect。

开发和测试之间的结对

为了解决Defect周期过长的问题，我们将开发和测试结对。在story开始之前，测试人员先设计出比较粗糙的test case，开发一起进行review，双方一起对Testcase进行查漏补缺，同时完善自己的想法。对测试来说，增加其他的测试分支，对开发来说，更新代码结构。

在story测试阶段，开发人员和测试人员坐到一起进行测试工作。当遇到问题后，可以发挥开发的优势，快速定位这是真正的defect还是环境因素。在确定是defect后，双方人员可以讨论这个defect应该怎么改，并且在代码端快速改动、编译dll文件，使用本地的增量build里的dll文件替换原来的dll，验证defect。

通过这种方式，defect的生命周期被缩短到一个小时以下，甚至十几分钟二十几分钟都有，大大降低了等待的时间，避免了defect的track的时间、精力，大大提高了效率。

不同team之间的结对

为了解决不同team直接沟通成本太高的问题，我们在后面遇到问题以及讨论需求的时候，就将不同team的人叫到某一边，比如我们直接去B那边跟对方的开发坐到一起，讨论这个问题，并且现场修改代码，解决问题。

有一个例子，A产品的phone number发送过去后，在B产品端显示的phone type有问题，经常出现在A端上home phone number，结果显示在B端就变成了Mobile等等。为了解决这个问题，双方人员做到一起，A方人员给B方人员介绍player phone的结构，发现在B中player phone是三层结构：Communication Type/Phone Type/Phone Number, 而在A那边是两层结构，Phone Type/Phone Number，找到了原因，双方直接商议了解决方法，立刻就改了代码，编译，验证。问题很快得到了解决。

总结

结对有优点也有缺点，比如结对编程可以互相帮助，互相教对方，提高代码和产品质量，减少bug，降低学习成本等等的优点。但是结对编程也不是适用于任何场景。在不适合的场景使用结对编程有可能造成麻烦甚至矛盾，比如，程序员们会对一个问题各执己见，争吵不休，反而产生重大内耗；或者两个人在一起工作可能会出现工作精力不能集中的情况，程序员可能会交谈一些与工作无关的事情，反而分散注意力，导致效率比单人更为低下等等。比如groupcode review的人员过多，反而会花费更多的时间。

我认为适合结对的场景是：