结队编程的好与坏

作者：Gigi Sayfan 时间：2015-9-4

在我看来，结队编程是最古老的敏捷实践方法之一，却也是最不常用的敏捷实践方法。我相信这是有原因的，也许不是所有人都这么认为。

结队编程要求两个程序员坐在一起，执行一个给定的任务。其中一个人写代码，另一个人观察、给建议、提醒错误或提供其它协助方式（如查阅文档）。

好处是众所周知的。需要更多信息可以下载这篇文章《结队编程的好处与代价》。
但是，为什么它不能像其它敏捷实践一样成为主流呢？通常会提到的原因是：经理们不愿意看到两个有经验的工程师一整天坐在一起写着同样的代码。在某些公司可能是这样的。但是，通常是开发者他们自己不喜欢结队编程。

有很多原因导致开发者不喜欢结队编程。许多开发者都喜欢独处，倾向于关注手边的工作。频繁的交互会干扰他们的专注力。许多开发者喜欢在非工作时间工作，或者在家里或咖啡厅工作，这使结队变得困难。原始的极限编程要求40小时的工作，每个人都要同时到达或离开公司，但如今的弹性工作环境也使得这一点不太现实。

就我个人而言，从来没有见过真正的结队编程实践，结队编程也从来没有公开地被当作备选方案。我的经验基于多年的不同创业公司工作，并使用了多种敏捷实践。我尝试在一些公司中实行结队编程，但是都没有流行起来。

那么，结队编程只会被那些理论派的敏捷狂热粉丝使用吗?未必。在有些情况下，使用结队编程是非常重要的。
最常见的一种场景就是调试。我使用过结队调试很多次了。每当我遇到困难不知该如何继续时我会邀请一个开发同事一起，然后困难很快地突破了。其实我们所做的只是“解释发生了什么”（又被称为橡皮鸭）。

另一种典型的结队编程场景就是组内一个成员向另一个新成员展示编程规范。这使得新成员能够很快的学会这一系列工作的每一步，以及会用到的框架、工具和方法。