RUP/XP 方针：成对编程
Robert C. Martin
Object Mentor, Inc.
Rational 软件白皮书
翻译整理：BrokenDoor 2002/3/4
--------------------------------------------------------------------------------
简介
成对，概要说明
--------------------------------------------------------------------------------
成对编程是软件开发中两个人一起编写一个项目的一种技术。每个伙伴工作在同一台机器上，当一个程序员在写代码时，另一个伙伴在一旁观看，同时认真所写的代码。写代码者从战术上考虑具体实现，其伙伴则从战略上考虑整个程序。他们之间频繁的交换角色，这样将使得可以更快写完代码，并且减少错误，更重要的是：代码将至少有两个人非常清楚的掌握。
成对的案例
--------------------------------------------------------------------------------
考虑一个典型的代码审视的工作。一个需要一人8小时开发的模块由8个人花一小时审视。也就是等于总共要花费16个工作人日。然而，审视者不能保障必需的时间去熟悉代码，而且他们的审视也相当的肤浅。单个人开发确实能非常熟悉该模块，但是可能太熟悉了以至于不能发现漏洞。
对比成对编程的实践方法。如果这个模块需要两人合作8小时来开发，总共需16工作人日。然而，这种情况下，两个伙伴将会非常熟知这个模块的代码。在开发过程中所隐含的一些错误也将被另一个伙伴发现。
成对编程的实践是简单的，但是是一种简单而有效的编写和审视代码方法。两人同时熟知代码，并且将错误漏洞出现在代码中的可能性大大减少。代码将有一个良好的结构。当然成对还有更多的益处：
成对更有勇气：一个人不敢尝试的东西他的伙伴将有勇气去尝试并扼杀其原有的评估；
成对能鼓励团队：由于代码不是一个人独立完成的，而将是属于整个团队所有。
成对促使知识的传播：由于在开发的过程中不断的交换伙伴，而使每个成员将熟知系统的每个一个模块。
成对能提高生产力：一个人在开发的过程中将会出现一段疲劳、消极的时期。如果双人变成，则可以相互促进，当一方疲劳时，他们可以交换角色。他们将能保持强度（比一个人工作强）。
成对是一件有趣的事：和他人一起工作是一件有意义的，非常刺激而且简单的游戏。它将会提高工作满意度和提高士气。
实践规则
成对
--------------------------------------------------------------------------------
成对开始于某一个程序员承担了一个任务的责任并且请求其他人帮助的时候。规则是：当你被请求提供帮助的时候，你必须说可以。这并不是说你需要立刻停下正在做的事情。这其实时说你必须商定好一个时间你能够提供帮助而另一个时间获得帮助作为回报。
成对中的伙伴并不承担任务的责任。这个责任还是归任务所有者保留。并且成对中的伙伴也不保证说一定要和任务所有者一起直到任务完成。成队的伙伴指保证完成提供帮助。
成对中的一个成员成为驱动者，而另外一个则在一旁观看。驱动者键入代码，运行编译器，运行测试程序，并继续任务。旁观者则检查每一个键入，每一个命令，每一个测试结果，并且提供帮助和建议。在所有的时间里每一个成员都被充分使用了。
某些时候驱动者会更了解要完成什么工作，而旁观者则只是简单的跟随。而另外一些时候，旁观者将会替驱动者决定要做什么。有些时候驱动者失败了并且将键盘递给旁观者，然后两人互换角色。还有些时候，旁观者会要求拿过键盘并且互换角色。这些情况将在成队的过程中经常出现。
交换成对
--------------------------------------------------------------------------------
成队的伙伴并不是长期固定的。一个典型的成对过程将仅仅持续半天左右。每一个伙伴都可以因为任何原因选择退出成对。当这种情况出现的时候，任务的所有者必须找到另外一个成对伙伴。这也可能意味着是该任务所有者回报帮助给上周的某一个伙伴的时候了，也可能他或她需要请求一个对当前特殊的问题有着合适经验的人提供帮助。
这种成对的交换会形成系统的相关知识在整个开发队伍中的传播。在很短的时间内，每一个团队成员就将有在系统的几乎每一个部分工作过的经验了。这急剧地减少了项目重写的程度，并且让每一个程序员在处理整个系统的时候更有信心。
集体代码所有权
--------------------------------------------------------------------------------
因为每个人都在为系统的不同模块工作，因此没有人拥有某一个特定的模块。这表明对系统的责任不会按照每个模块为基础分割开来。更好的方式是，整个团队拥有整个系统的集体责任。每一个团队成员都可以为任何原因签出并修改系统的任何一个模块。当一个双人组合修改模块X而导致了模块Y的单元测试失败的时候，这个组合将会直接修订模块Y。
漫步和协作
--------------------------------------------------------------------------------
成对编程时一个非常热烈的交流形式。口头的对话经常会变成争论，局外人通常会有理解的问题。作为一个局外人，你也许会听到两人发出特别的单词好像：“分号”，或者“关闭花括号”。或者你可能只是听到一些不清楚的噜噜声作为程序员们同意或者不同意屏幕上出现的内容。俩人都忙碌于正在出现的代码中以至于很多交流都是无声的。肢体语言占了很重要的位置。一个成队的伙伴不需要出声询问就可以说出他的同伴什么时候对代码不满意。一个鬼脸，一声叹息，一阵不安——所有的集合起来都增加了伙伴之间的交流带宽。有些时候一个伙伴会抢过鼠标，而另一个则操作键盘。拿鼠标的人控制需要在模块中工作的位置。拿键盘的人控制在此位置修改和添加的内容。另外一些时候，一个伙伴可能在键入代码，而另外一个伙伴将预知一个需要的函数调用并且打开API文档中相应的说明页。
当一个伙伴疲倦的时候，另外一个人可以接过手来，允许他或者她的伙伴休息一下来充当相对的角色。其它的时候，两个伙伴都会有高昂的精神面貌并且会经常的交换鼠标和键盘。
总而言之，这里只有很少的规则和过程。真正需要约束的仅仅是两个伙伴都必须维持高昂的精神面貌并且俩人之间交流必须是热烈的。如果成对中的一个伙伴正在键入代码而另外一个家伙正看着窗外的话，则成对只是虚有其表。
单独的一个程序员能做什么呢？
--------------------------------------------------------------------------------
你不可能在所有的时间内都保持成对。一些项目——那些选用极端编程(XP)(参考资料1?)——遵循的一个规则就是必须由成对完成所有产品代码。在这种情况下，在你没有成对时你可以去查看一下电子邮件，阅读一些有关新技术或者API的技术资料，看一下那些你不太熟悉的代码，或者跟投资者探讨一下当前的迭代状况或者未来的计划。实际上，总有一些适合的事情可以让一个程序员在没有找到伙伴的那几个小时里去做的。
有一些项目对成对要求的没有那么严格。有一些会允许单独的程序员们去编写测试代码。还有一些允许单独的程序员们去编写抽象类和接口。也还有一些只是简单的允许程序员们决定什么时候最好需要成对。有一件事是很清楚的，无论如何——研究已经表明当实践成对编程的时候错误率会很显著地降低。
有一些人不喜欢成对
--------------------------------------------------------------------------------
一些人对成对编程的概念感觉不适应。在我们的经验中，这些人实际上在尝试了一周左右后发现他们的不适应消失了，并且他们喜欢成对和发现它是很用处的。只有很少的人会继续不喜欢这个实践。因此，对大多数人来讲，尝试并且习惯它是一个很简单的问题。对于那些真正了尝试过并且依然感觉到不适应这个实践的人们，团队就必须去找到一些适合他们做的事情。
设备，方便以及后勤
显示器和键盘的布置
--------------------------------------------------------------------------------
设备的布置对成功的成对实践是很重要的。如果伙伴们不能坐到彼此的旁边并且很快的交换键盘的话一个成对很难实施得很好。规则是：你必须能够来回的拿到键盘和鼠标而不需要交换座位。
最好的安排通常是一个漂亮的长平板桌。将显示器放在中间然后正对着显示器放两把椅子。坐下来让显示器在你们之间。确保很容易能在你们之间挪动键盘和鼠标。同时确保在你拿到键盘的时候，你能够很舒适并且能够坐直。确保显示器能够让两个伙伴都看得清楚而不需要转动它。
大房间
--------------------------------------------------------------------------------
为了便于交换成对的伙伴，一般都希望能够在一个类似棒球候补球员区的环境下工作。在一个房间里放置多个成对用的工作站。使用有轮子的椅子和油布或者瓷砖地板。排列工作站让成对的伙伴们都能面对面。这样做的目的是为了增加交流。有些时候最重要的交流就是那些偶然发生的。我们想让这种交流出现的几率能够增加。
在角落里
--------------------------------------------------------------------------------
现今的许多小单间都将工作站放置到角落里。程序员们面对着角落坐下来在他或她的面前是一个显示器。当然这样会便于单人工作，但是在这种环境下成对编程几乎是不可能的。如果你有一个将工作站放在角落的小单间，那么在其他地方放置一些成对用的工作站——也许在一个会议室。在一个会议桌上使用一个笔记本电脑进行成对编程常常是很有效的方式。
问题和关注
成对让生产力减半
--------------------------------------------------------------------------------
这种说法建立在以下的理由上，两个人在一个任务上一起工作会消耗两倍于一个人在同样的任务上工作的所花费的时间。这看上去合情合理，但这却并不是真实情况。根据研究(参考资料2?)表明很少的，即便有，生产力会在成对工作的情况下丧失。同样的研究证明了成对可以大大的降低错误率，以及程序代码的大小，同时极大地增加了工作的乐趣。
成对伙伴间的争论
--------------------------------------------------------------------------------
任务的所有者有所有设计争论的最终决定权，但是处理争论的最好的方式是对两种设想都进行尝试并选择工作得最好的那种。
专家
--------------------------------------------------------------------------------
传统的至理名言给出的建议是对某一个特殊领域有专长的程序员，例如数据库或者图形用户界面，应该独自在这些领域发挥作用。但是在一个成对编程的环境下，这些专家成为那些没有这方面特长的伙伴的最好的导师。程序员们可以签上一个不在他们的专长领域范围内的任务然后征求专家们的帮助。这样，专家的知识就开始在整个团队的范围内传播，极大的减少了项目反复的程序。
噪音
--------------------------------------------------------------------------------
一个成对地伙伴可能在他们编程时产生噪音。一个坐满成对伙伴的大房间会保持频繁的低低的嗡嗡声。有人会感觉到这些噪音令人烦闷以及分散注意力。这并不能证明是一个重大的问题。如果你觉得这些噪音令人烦闷，你可以走到会客室坐一会儿。
牛仔
--------------------------------------------------------------------------------
许多团队会发现他们是一到两个牛仔式编码者的足以自豪的拥有者。这些牛仔是一些比其他任何都能更快地完成任务，不能和其他人合作，并且任何人都不被允许（或者是如果允许的话，也没有能力）去阅读他们的代码。对于这些开发者最好的处理方法是让他们离开项目或者承担一个不需要他们编写产品代码的角色。也许他们能够编写一些临时的工具或者做一些疯狂折磨式的测试工作。
习惯障碍和障碍形式
--------------------------------------------------------------------------------
有一些人使用QWERTY式的键盘。另一些人更习惯于DVORAK式的。一些人需要特制的键盘，鼠标，显示器，脚踏开关，等等，等等。一些人在编程时不能没有耳机和喧闹的音乐。另一些人必须在他们周围摆满空箱子。一些人喜欢用emacs编辑器。另外一些人喜欢VI。甚至还有一些人喜欢用WordPad?.
实际上，这些可以指出的障碍是数不清的。但是每一种障碍和每一个人都可以通过一些想法解决并且有办法进行折衷。一个让这些事情阻止他们的团队是不可能在他们尝试的任何努力中取得成功的。
团队如何规划成对的计划？
--------------------------------------------------------------------------------
我们并不认为任务需要指定给一个双人组。更好的方式时每一个开发者需要承担一些任务的责任。我们喜欢非正式地成对。每一个开发者，从事他或她自己承担的责任，请求其他开发人员提供暂时的帮助。任务的所有者保持着所有权和责任。成对的伙伴仅仅是帮忙的人。
每一个开发者必须在评估任务的时候计入他或她作为其他人的开发伙伴的时间。
总结
成对编程是一种成功试验过的，令人满意的代码审查的替代方法。不仅如此，它还是一种编写软件系统的革新的途径。带来的好处也不仅限于生产力和质量，而且对一些像团队士气和精神风貌等方面带来好的影响。
参考资料
(1) 解说极端编程(eXtreme Programming eXplained)， Kent Beck, Addision Wesley, 2000.
(2) 强调成对编程的案例，Laurie Williams, 犹他州立大学， 7/8月 IEEE 软件。
文章来源于领测软件测试网 https://www.ltesting.net/
