结对编程的成熟度模型

上周，我花了四个工作日的时间和Tim Ottinger坐在一起来开发FitNesse的一项新功能。考虑到Tim在FitNesse上还是个新手，于是我就从先为他介绍一些底层架构开始，然后再一起开发新功能。看来Tim觉得这样还挺管用，随后他就要求把自己添加到了可修改FitNesse的人员列表中。

我们一起开发的功能是一个新的导航功能，叫做“向后查找”。它支持你按照如下方式来定义页面：<SomeAncestorPage.ChildPage

其中的SomeAncestorPage可能是一个当前页面的诸如父、祖父或是曾祖父等的页面。这就好像是在unix路径中使用..，除非你能准确地告诉它回退的路径名称，否则就回到上一层。

让这项功能运行起来并不难，我们一起结对编程了几个小时就已经能跑起来了。但随后我们就碰到一个更有趣的问题，那就是如何去影响旧有的那些功能，更准确地说是该如何去重新整合它们在一起。

FitNesse提供了让作者重构其wiki（译注）的功能。比如说，你可以改变页面的名称，也可以把页面转移到新的位置。不论是哪种操作，FitNesse可以提供选项让你搜索出整个的wiki中对当前更名或是换位置页面的所有引用，并且随之更新这些引用。当然，我们也希望去更新这些使用了“向后查找”功能的引用。

这件事情之所以复杂的原因有二。首先，这个问题本身就不简单。为一个页面指定一个路径，如果它们重命名了，那么就改变这个路径去适应新的名字。听起来可能简单，可这个问题确实有点儿绕脑子。即使那个原先编写这些代码的人（噢...那人是我）已经处理了关于路径名称语法的一些额外的复杂问题，但问题也并未因此而简化。

结果，我和Tim几乎盯着这段代码看了两个小时，而且就只是想去看明白代码。我们碰到的一个困难就是结对编程对于仔细研读的复杂代码这种事情来说没那么奏效，尽管它在开发那些你们都相对清楚的代码上是很不错的。实际上，结对的双方会很快的把注意力从理解深奥晦涩代码中转移到讨论那些没完没了的随意想出的无聊点子上了。每当我想理解其中的意图的时候，Tim会说：“噢！看看这里的代码！”，然后我的思绪就被打乱了。每当Tim想出了一个好点子，我都会拉着他谈一些其他话题。于是，没多久我们的结对就没法进行下去了。

结对编程是个了不起的工具，这四天来它在我们的大部分合作中都发挥了很好的效用，但有时结对却会妨碍事情，有时候你们最好还是先停下结对直到你们读懂了那段代码。因为这是需要时间、专注和沉默的。对于这种事情，结对编程并不适合。

还忘记了提到，实际上，通过结对编程我们完成了此项功能。我们激烈的讨论问题，随后找到了一些简单的重构方法，并且也使得代码更加易读。我们是逐步求精的，而不是一下子就写出了整个算法，通过一连串的简单改进让它变得更清晰，直到这个算法在理解和修改起来已经足够的简单。我们的主要方法是把语法和语义问题区分开来。于是我们一步步将所有语法相关的代码（例如识别是断点还是wiki单词的代码）分离成单独模块，让算法着重于去处理路径的抽象而不是那些文本的细节。

作为一份学习的经历，这对我们来说都很棒。而且我觉得我们在努力度过结对的难关以及重构出更简化的方案上所做的是对的。

尽管如此，问题依然存在。有一些模块通过结对方式来理解反而不如他们各自分开并且静下来独自专著的领会来的好。

我开始观察到，成熟的敏捷团队参与结对编程的时间往往占据了稍微超过一半的工作时间，或许是70%的样子。我认为这个比率是健康的，我并不支持100%的结对。相反，我认为你对待结对编程就应该像是对待其他工具一样--当它们奏效的时候就用它们。还要提到，我还是认为结对编程在大多数情况下比不结对更有效，而且应该积极倡导去这样做。然而，结对编程也并非一种教条，而应该像是对待其他事物一样的加以辩证去运用。

译注：

Wiki，常译作“维基”，源自夏威夷语的“wee kee wee kee”，本是“快点快点”之意。在这里wiki指的是一种可在网路上开发多人协同创作的超文本系统，是由“wiki之父”沃德.坎宁安（Ward Cunningham）与1995年所创。