模板
教程
环境
性能
功能
管理
交换编程——结对编程的延伸实践
“结对编程技术是一个非常简单和直观的概念：两位程序员肩并肩地坐在同一台电脑前合作完成同一个设计、同一个算法、同一段代码或者同一组测试。与两位程序员各自独立工作相比．结对编程往往只需花费大约一半的时间就能编写出质量更高的代码， 但是，人与人之间的合作不是一件简单的事情——尤其当人们都早己习惯了独自工作的时候。实施结对编程技术将给软件项目的开发工作带来好处，只是这些好处必须经过缜密的思考和计划才能真正体现出来。”（引自《结对编程技术》，原名为《Pair Programming Illuminated》，作者为Laurie Williams, Robert Kessler）。下面我们分析一下结对编程的特点：
◆ 结对编程在很多项目中得到应用，也作为XP（极限编程）一个非常著名的观点和做法被很多人大为推崇。
◆ 结对编程是两个人同时做同一件事情的一种方法。表现上会给人一种浪费一个开发人员的感觉，实质上这的确是可以提升效率的。
同样的这个做法，2002年我在上海进行的一个类ERP项目中用过一次，当时在我做完权限系统的全部功能后，和一个兄弟合作了一个模块，我们两个人只用了三四天时间，就完成了这个新的模块的全部功能。相对于我们此前做的功能模块来说，时间不到那些模块开发时间的十分之一。但由于结对编程会让人感觉到资源被浪费了一半，在2002年的一个项目中，我提出进行结对编程的时候被领导拒绝了。这件事以后，我就开始考虑如何才能降低这种表面的浪费，而又能让大家交流起来，同时能提高团队的稳定性。
产生背景
2002年我的项目组要做如下这样的一个项目：
这是电信MSS系统的核心业务系统部分，包括了规划、设计、施工、验收、财务、合同等多个重要环节和多个部门的业务。当时团队开发人员数量较少，人员技能较为均衡，没有水平超出其他人过多的技术人员。这个项目在最初评估的开发周期就是第一个版本在五个月内完成，整个项目至少要做上一年以上，而最后的实际情况是，这个项目随着不断的升级和调整一直开发了三年多。最初的开发团队是十一个人，后来扩展到二十三个人，主要开发人员总数为十六个人，其中有四个人技术水平相对较高，另外的七个人技术水平相对较低但是也都有三年多的实际项目开发经验，其中有三个是我2001年带的三个应届毕业生。
由于开发团队中没有技术水平超出其他人很多的人员存在，因此技术方案的论证过程都是在大家的共同讨论中制定下来的，只是在团队整体控制上，当时我有相对较强的发言权。因此在权衡了整个项目的实际情况后，完成需求工作我就告诉弟兄们——第二阶段设计模型的开发大家交换来做。
刚开始很多弟兄不理解，因为相对而言我的开发经验比其他人多了几年，所以当时我说的一些话兄弟们还可以接受，于是我就直接要求大家按照我的计划执行。在设计模型开发完成后，我再次要求大家进行交换。两次交换完成后，保证了每一个模块都有至少两个人对其十分熟悉，一方面不会因为人员的变动造成团队的不稳定（这一点考虑相对较少，因为当时的团队合作时间比较长，大家彼此十分熟悉和了解），另一方面保证每一个模块的开发人员都能找到人进行讨论，从而增加了团队内的沟通，方便了协调工作的进行。
因此在那个团队的开发过程中，我们经常是大呼小叫，无论走到哪里，都是十分热闹的场景。
方法定义
◆与结对编程类似，交换编程也是一个非常简单和直观的概念：两位或者多位程序员轮流开发同一个软件系统的同一个模块的不同阶段的任务。交换编程的方式更合适的说法应该是交换开发，这种方式不仅仅可以应用于软件项目，也适合其他研究开发型项目。相对而言，这更是一种更容易被人们接受的方法，在前文大家已经看到了它在实际项目中的事实，这里先分析一下它与结对编程的不同之处：
◆ 它仍然采用传统的一人一机的开发方式，结对编程是两人一机。
◆ 它在每个迭代间进行多人交换或者两两交换，结对编程没有交换的概念。
它与传统的编程方式之间的差别是在每个迭代间进行多人交换或者两两交换，而传统编程没有交换的概念。
这里说明一下两个概念：
轮轮流交换：三个以上的程序员之间相互交换所开发的工件，不仅限于三个。例如：A1的开发内容交给A2，A2的交给A3，……，An的交给A1。这种方式称为轮流。
两两交换：两个程序员之间相互交换所开发的工件。仅限于两人之间。
建议实施方式
交换编程中的操作与其他过程有较大的差异，根据经验，建议在软件工程实施的各个阶段按照如下的方式进行：
◆ 需求工程中，需求调研和需求分析进行轮流交换，轮流交换至少是三个以上的人进行互换，不是两两互换；
◆ 概要设计（分析模型）开发中，需求分析到概要设计也进行轮流交换；
◆ 详细设计（设计模型）开发中，概要设计到详细设计再进行一次轮流交换；
◆ 编码实施启动后，详细设计到编码的交换采用两两交换，注意这个时候不再采用轮流交换了。
在全程建模的开发方法下的交换编程应用方式如下图：
由于目前没有进行实际数据的度量对比，本文也无法从量化的数据上来说明问题，只能通过一些具体的事实来进行说明和验证：当时这个项目的模块从7个扩展到了11个，人员数量从11人扩展到了23人，我们在七个月内满足了南方11家省级电信公司和集团公司的基本业务需求，从2003年4月到2003年12月期间，基本完成了这些省公司版本的二次定制开发任务。
在编码以前全部采用轮流交换的目的就是为了让更多的人了解项目进展的全部内容，有利于增加团队内的交流，使更多的人对项目所开发的内容熟悉，并能让他们提出自己的观点，也有利于使更多的人从更多的角度来研究某个系统模块所需要实现的功能和用户需要解决的实际问题，不会因为某个人的定式思维而出现理解偏差，从而造成对需求的理解不到位。
详细设计到编码的交换采用两两交换，这是因为前期需求已经基本上都稳定下来了，这时候不需要对用户需求进行更多方面的理解，只需要进行实施并进行纯粹的编码工作即可。此时做轮流交换就不存在任何意义了，相反只能影响开发进度。
优劣势分析
这里所提到的优势都是和具体的开发方法相关联的，大部分是相对于XP方法中的结对编程，同时也会分析它与传统开发方式间的优劣。
开发时间“浪费”不明显
◆ 表现
这个开发时间“浪费”不明显是相对于结对编程与传统开发模式而言的，至少让老板没有感觉到人员分配方式带来了人员的浪费。大家都知道，结对编程需要两个人共用一台计算机、一套键盘、做同一个故事，这样的开发方式往往会给人感觉浪费了一个人，虽然事实上未必如此。但是如果哪个项目经理第一次甚至说前几次这样做，估计大多数老板都会表示反对的，因为他会感觉自己的技术人员只有一个人在做事情。同样，在2006年的敏捷中国开发者大会上，ThoughtWorks的总经理也提到了这个问题，他的解释是这样的：当两个人合作三个月以后，效率会超过两个人单独编程的效率！但请注意：这里有一个时间前提——三个月以后。
三个月这个时间未必是真实确凿的时间分界线，它只是一个模糊的大概的时间范畴，如果两个人配合的好，也许只需要两个多月，如果配合不好，也许需要四五个月的时间，或者更长的时间……。我相信这样的说法连Martin也不会反对的。从这个时间界限上，大家可以看看国内公司的项目状况，然后再继续我们的讨论。
◆ 分析
项目情况：国内很少有时间限度较长的项目，大多数项目都是在三个月到半年时间内结束，有些甚至只有一个月。这样的时间特性，将使得这个三个月的期限变成了一句空谈，也就是说，当两个人磨合好的时候，项目已经结束了。这时候，有人会说，下一个项目还可以继续合作呀，好，那我们来看看国内项目团队的人员变动情况，然后再继续。
◆人员情况：国内大多数的公司都处于一种为了谋生而存在的状态下，有很多技术人员都有三五个月就跳槽的经历。不仅仅是技术人员，往往公司也是这种状态，很多公司就是为了某一个项目而建立的，老板在招聘技术人员的时候，都是往最低限压低技术人员的工资，当一个技术人员对项目了解到一定程度的时候，这个时间往往是在三个月到半年时间之间。半年，或者一年，是一个人最容易发生跳槽行为的时候，因为这个人了解了公司的实质情况，如果老板当时骗了人，那么这个人必然要离开公司；如果老板当时过分地压低了他的收入，那么这时候这个技术人员就希望能够获得加薪等等，除此之外，还有很多很多其他的因素，都会给人带来未知的行为。也可以说，国内很少有团队成员能够合作达到一年以上的时间。这样的话，第一个项目磨合好了，第二个项目就是在考虑跳槽，第二个项目未结束人就走了，这是我们平时很常见的现象。
这个时候做结对编程，效果就不会那么明显，因为在人员相对成熟的时候，人的心理发生了较大的变化，工作的积极性和配合程度也远远不及刚刚进入公司的时候。那么结对编程在这样的环境下还能进行下去吗？估计不用分析就可以知道了。这时有人会说，如果配合不好，那就换人结对，不一定非要这两个人结对。那这就要从项目组人数说起了。
◆项目组人数：在我所开发过的项目中，大概有不到一半的项目有十个人以上的开发团队。最大的团队开发人员是不到三十人，这二十多人还要分成几个组，每个组也就五六个人而已。在这种情况下，结对的问题就出现了，在组内的你只能和这么三五个人结对，是不是都很容易配合起来呢？这个事情很难说。配合不好怎么办？换人？换项目？还是换公司？当然，如果配合了三个月还配合不好，站在公司的立场上，是肯定要考虑开除掉某人了，至少也要将他降薪或者调离这个项目组，因为公司承担不起这么大的风险。项目经理更是在担着风险，因为结对编程的事情老板本来就不太乐意看到，本来老板就有意见，而项目组如果发生了这样配合力度很差的情况，项目经理的处境可能就非常危险了。
综合上面这三个方面的情况，我们可以得到如下的结论：
结对编程在中国这些短小项目过多的情况下是不太适合的！结对编程其实更适合一些相对人员较为稳定的开发环境，否则，三个月的低效率配合时间会让老板将项目经理的脑袋当球踢的。但是，结对编程还是有其好处的，比如，提高项目组的稳定性，当一个人离开后，另外一个人可以很快地将新人带到位，项目组不会因为人员变动而发生较大的风险问题。同时，结对编程提高了程序员之间的交流，团结了项目组内成员，同时容易形成人月神话中提到的胶冻团队的效果。另外，在三个月后还是有效率提高的情况发生，的确能够带来很好的效益的。
这时候，交换编程就带来了很好的效果，一是没有老板担心的两个人做一件事情的风险，同时增加了项目组内成员的沟通交流，也提高了团队的稳定性。但如何提高团队的稳定性？
项目组稳定性提高
◆ 表现
在我前面的例子中可以看到，一个模块至少有三个人对他它很熟悉，因此在后面的开发过程中，无论哪个人发生变动，都不会影响这个团队的稳定性，所有的任务都能够很好的延续下来。每一个系统的模块都会至少按照阶段数量（不同的项目会有不同的开发周期，同时也就有不同数量的人会对这个模块十分熟悉）分给不同的人来进行开发。如果和结对编程配合起来使用，则将会使得对同一个模块了解的人数达到一般交换编程的两倍人数。
◆ 分析
有了这样的对每一个模块都很熟悉的人员数量的存在，团队的稳定性就会表现出来，任何一个人的变动或者少数人员的变动都不会对团队和开发进度产生较大的影响。因为随时都可以有其他人来接替这个发生变动的人的全部工作，也很容易培养新人进入到团队内来进行工作。
更适合没有绝对高手的团队
◆ 表现
当团队内没有绝对高手存在时，也就是说，系统的架构设计将是更多的人一同讨论出来的，并在开发过程中不断的修改和调整。
◆ 分析
没有绝对高手存在，系统架构设计就不能够在系统进行分析设计前完成，而同时架构的不稳定，就无法更好地安排任务计划和制定故事，这些都会影响到整个系统的开发进度和过程，同时，敏捷编程所倡导的很多做法就无法在这个大前提下来进行实施。
国外能够很好地采用敏捷的做法来实施项目的一个原因是，他们有很多有一二十年工作经验的开发人员。这些人员的经验积累是非常重要的，他们可以更好地在项目开始的前期对项目进行整体的控制和把握，同时做好项目计划和制定好任务故事，而这一点在国内尤其是软件公司中还不具备这个条件，因此，很多项目我们都处于的状态类似于我前面所举的电信项目的团队情况，甚至情况比那个团队还要差得多。
团队内交流增加
◆ 表现
前面已经提到,“因此在那个团队的开发过程中，我们经常是大呼小叫，无论走到哪里，都是十分热闹的场景。”这种频繁的交流，无形中使得团队的凝聚力提高，相互之间的关系和合作也都更为密切。
◆ 分析
如果是一个人从头到尾开发一个模块，他就几乎不需要和团队内非管理人员进行交流，甚至在某些情况下他只需要和客户做好沟通就足够了。而这时候，即使进行了同行评审，这个技术人员也可能会认为两三天的时间内这些人不可能了解这个系统模块的内容。这种评审也就容易流于形式而无法得到真正的重视。其他人也会认为评审是浪费自己的开发时间，于是到了一定程度评审就会成为可有可无的状态。如果有较多的人参与了这个模块的前后期分析和开发，每一个阶段都可以找到别人来进行讨论，在评审时对这些人提出的意见也就更容易接受——因为他至少会认为这几个人比他更早介入这个模块的分析，在某些程度上会比自己了解的更为深入。
唯一可能的劣势
◆ 表现
由于存在多人之间的交换，在某一个具体工件的开发的时间上会比一个程序员一直做下来略有延长。
◆ 分析
由于在任何一次交换之间都需要前一阶段开发者队后一阶段开发者进行关于业务和技术方面的沟通和交流，因此会延长项目在初期的开发时间。尤其当团队成员相互之间的熟悉程度不够或者配合不协调的时候，这个问题会表现得较为突出，甚至可能影响一些项目的进度以及开发工作的进展。
但是，这个影响会在相应的程度上促进团队内人员之间更快地相互熟悉，这个周期要比结对编程短很多，一般来说，不会超过一个月的时间就可以让团队成员之间相互熟悉（由于不是坐在一起开发，这个熟悉的程度比结对编程的要求低很多，因此时间也相应会缩短很多）。
深入讨论
交换编程的应用方式是有其适用环境的，另外在我的实践和研究中还建议如果团队合适，可以考虑与结对编程配合使用。
适用环境：这种开发方法的适应性较强，这里分为团队状况和项目情况两个部分进行一些说明。
团队状况：交换编程适用于人数超过两个人的开发团队，因为交换一次至少也需要两个开发人员。大的团队也可以应用交换编程的方式，来进行项目开发。要求团队内的成员有一两个具有两三年以上开发经验的，这是对于一般的项目（哪怕没有什么技术难度）的最基本要求。
项目情况：项目规模不限，开发周期的适应性也较强，对于任何类型的项目都可以适用。
与结对编程配合使用：如果领导比较认可结对编程的开发方式，这个时候，您引入交换编程也会带来同样的好处，比如团队稳定性，至少从对系统业务模块熟悉的人数上来看增加了一倍，以及团队凝聚力，因为频繁的交流，从而更多地降低因为少数人的思想和考虑偏差造成对用户需求理解不足等问题。
有了上述的情况表现，也使得团队的规范化操作能力更强，也可以使得很多问题能够在有效的沟通中的到解决。
由此可见，交换编程的存在是有其道理的，没有用过的朋友不妨尝试一下，至少对您的团队没有什么伤害和大的变动。
