一对交换:什么是Pros和Cons？

Question

大多数敏捷/ XP理论家所支持的总体观点似乎是，对应该定期交换。例如，每个程序员应该每天交换一次对；一半的人在一天开始时交换，一半的人在午餐后交换:由于会议、假日等外部因素，大多数人倾向于每周翻转一到两次交换时间，以便这两种配置在整个团队中分布相当均匀。

频繁交流背后的一个理由是，知识在团队中迅速而均匀地传播，而不是将特定的技能和知识集中在特定的个人身上--这意味着如果人们离开或离开公司，工作就可以顺利地继续下去。另一个理由，也是围绕对编程本身的教条的必然结果，就是每次有人交换你的代码时，都会得到一双新的眼睛，所以它只能提高代码质量。

这两种说法听起来都是合理的；从管理的角度来看，这听起来似乎在稳定性和质量上都得到了提高，因此，在我已经看过的大多数敏捷/ XP书籍中，频繁的交换几乎是一个标准理论。

所以，当实际付诸实施时，人们会怎么看待对的交换？

• 程序员的观点？
• 经理的观点？

和

• 什么时候应该确定某人换掉/换成一对？

Answer 1

配对编程是很困难的。

这很难，因为当两个人的技能水平接近的时候，效果最好，而在某些工作环境中，这可能是很困难的。当你交换的时候，这可能会更加困难，因为你需要找到另一个具有适当技能水平的人，然后让他们跟上当前的问题。好处是有更多的人接触到任何给定的代码，而这些代码都是对的。这将导致代码无法修复的次数减少，因为没有人对它有足够的了解。它还应该宣传团体所有权和任何人都能拿起任何作品的能力。

我发现，即使在完成配对的环境中，交换配对也不值得。然而，这可能是因为我们的任务从来不超过1.5天。我们发现，把任务分解为不超过1.5天的工作量是有很大好处的。在较长时间运行的任务中，对交换可能更有意义。

Answer 2

我既是程序员又是经理。以下是我的看法：

经常交换是很棒的。我喜欢每天换2-4次，这是我认为你能做的最快的。对我们来说，这是在自然的临界点:通常午餐和午后。每隔一两天换一次可能没问题，但我担心的时间会长得多。(我听说过每隔六周就有一个地方交换，我认为这是疯了；在这么多时间在一起之后，你就准备好刺伤一个圣人了。)

作为一名程序员，我喜欢它，因为我获得了新的视角，可以查看代码的其他领域，并且可以坚持或继续做我喜欢的事情。我最近刚从单独编码转到配对，我很兴奋:我学到了更多，玩得更开心，做得更多。

作为一名经理，我认为这是很棒的，因为它解决了很多卡车因素和瓶颈问题。这个周末我要为一个朋友的婚礼度一个漫长的周末，我一点也不担心:我做过的每件事都是别人做的。我还认为它确实有助于团队成员欣赏彼此的长处和弱点，并鼓励集体代码所有权。

至于谁会留在目前的工作中，我觉得这主要取决于所涉及的人。有时候你想看透一些东西，有时你已经准备好接受改变了。我们有时也会以交换的方式引进专业知识，或者说有些人可以学到他们感兴趣的东西。我们试图保持我们的工作单位相当小(0.5-2.0双天)，所以这不是什么大问题，但交换进行。

Answer 3

Okie，答案来自一个自称务实的敏捷/xp程序员。我已经做了两年多的配对编程了。如果配对编程是好的，经常交换成对(最好每两个小时，如果不是每半天)。在我们的办公地点，我们每天(通常)或每两天(更糟糕的情况)交换对。这样做本身就可以使我们对我们所提交和学习的代码的质量有很大的信心，或者对每对轮换都有一定的信心(我们知道代码评审是好的，越早越好。这就是“对编程，包括交换对的实践”所实现的)。

为什么我们不每两四个小时换一对？嗯，事实上我也参加过这样的团队训练。当然，这样做会更酷，也更有效率。但这是交易，交换对的时间间隔不应该是一个规则，它应该发生在它自己；只有这样，经理或企业才能看到它的好处。

我亲眼目睹和经历过这一切。我现在是它的传道人了。这不是理论。更确切地说，它是完全实用的:)快乐的乒乓球配对和交换配对。