请停止结对编程

（根据真实事件改编，情节有所夸张，请勿对号入座。）

这是一个风和日丽的星期五下午，Ben和Martin本应该在Costa咖啡馆喝一杯下午茶，一起聊聊周末的计划，然而PM的一个微信通知打乱了这一切。原来产品出现了一个bug需要紧急修复，下班之前必须要搞定。两人收到消息疾步走回到岗位，也没了心情去喝刚泡好的咖啡，连忙打开邮箱查看问题报告。

Ben：看来这不是一个很大的问题，就是处理一个来自于远端服务的异常。现在的情况是BFF(backend for frontends)在内部的远端服务有异常，会将异常直接返回到客户端，这样只要一个保单出了问题，前端所有的保单也都没法用了。

Martin：那怎么解决？

Ben：感觉可以在异常的地方加一个异常处理。这个涉及到RxJava和Java8的stream特性，我不是太熟悉，要不我们一起Pair吧

Martin：好。

两人喝了一口炙热的咖啡，摆好键盘鼠标，打开了IntelliJ工程。几分钟后，这个故障重现了。

Martin：可以重现的故障通常比较好解决。我们在这里先弄个try...catch试试。 两人似乎很有信心，然而重启项目后，故障并没有按照预期停下来。

Ben：hmm，这里为什么停不下来呢？

Martin：可能是RxJava的延迟处理，没有正确的捕捉到。这样，你在这里再写一个逻辑，然后在这里设个断点……

在这个过程中，Martin只是对着屏幕指指点点，时不时看看手机、在微信上聊聊天。Ben对RxJava并不是很熟悉，他想紧紧跟随Martin的思路，然而增加多个逻辑以后，依然都不能解决问题。15分钟已经过去，Ben这时候心生怀疑，是不是哪些地方没弄对？

Ben：我们理一下思路看看？

Martin：恩，来吧，一起看一下代码。

Martin领着Ben一起看了一下代码，并且一直在旁边指点Ben进行单步调试。由于RxJava的延迟特性，使得断点很难设置。而抛出异常的调用栈会出现在某些莫名其妙的地方，这让他们根本不知道把try...catch放在哪里才能奏效。

Ben：可能是要这样，在这里加一个OnError看能不能解决。

看似问题能够解决，其实是又一次的失败。在两人的激烈讨论中，时间过得很快，一晃眼已经是1个小时以后，咖啡早已经凉了，然而两个人完全没有心情，甚至都忘了咖啡的存在。

Ben对Martin的解决方案越来越没有信心，两人开始重新讨论起解决方案。然而方案是越讨论越复杂，看起来想在下班前解决这个问题是不可能了，通宵是必然了。

Zen是组里的Tech Lead，今天在忙另外一个事情。这个周五真是不得安宁，恨不得想到美国去过过昨天。

Zen听到两个人的讨论，虽然并不了解这个问题的细节，但直觉上认为是跑偏了。马上提醒Ben和Martin：

这不是一个很难的问题，我感觉你们想复杂了？是不是走偏了？能给我说一下你们怎么想的么？

被Zen打断的Martin说了一下之前的解决方案，也说试过了其他的方案了，都不行。由于Zen对这个事情也不是很了解，所以只是提了一个醒：

“Keep it simple，别把事情整复杂了。”

两个人的讨论依然在继续，Ben有点无法跟上Martin的思路，艰难地写着代码，但每次都不对。Pair的气氛犹如冬日里冰冷的咖啡一样凝结，不知道孰是孰非。Ben已经有些不高兴，Martin则依然在一旁指指点点但并不动手。

Zen一看表已经3点钟了，又插了一句嘴：

Martin，既然你对这个更熟悉，你来操刀吧。你来写代码吧。

可能由于之前的讨论过于激烈，Martin反驳Zen：

我们在Pair啊，他对RxJava不熟悉，我应该指导他。我看着他写就可以了。

Zen说，

你们的解决方案是什么，给我看看。

解释了一通以后，Zen也没有更多的想法，就让他们继续吧。但Zen建议道：

在这个紧要的关头，我们应该改变一下Pair的方式。现在不是教授知识，而是要高效的解决问题。在这种压力的情境下，你可以直接实现自己的思路，带着别人飞就好了。

Martin稍微冷静了下，拿过键盘，继续开始修复问题。Ben这时候在一旁观察，也适当的休息一下，之前手忙脚乱的按F8、F9的神经也得以缓和。

Ben：看来还是不行。我们再理一下代码吧。

Martin：你说的这些我之前都试过，都不行，要这样才行。

Ben：我说的是这样做的，既然我们还没讨论清楚，我们再来看一下代码吧。

两人拿出了纸和笔，对着屏幕一边画一边讨论，然而Ben并不认可Martin的方案，说要采用另外个方案。Martin则坚持认为这是一个可行的方案，得试试。Ben拿过键盘，准备按照Martin的方案写代码，但心里面颇为不爽，一直在想说服Martin采用他的方案试试。

到此时，时间都已经不知不觉过去两个小时了，然而问题似乎离真相总是忽远忽近。两个人已经疲劳不堪，再加上解决方案的不一致，两人的言语中开始显露出一些怒气。

Zen在运行测试的空档，打断了两人的对话，建议道：

既然大家已经产生了分歧，要不然两个人分开，各自实现一个，看谁能够先实现，然后再来讨论。

Martin对于Zen并不认同，认为Zen指责他和Ben没有Pair好。

Zen解释道：

其实我听出了两人意见的不统一，言语中已经有一些怒火，这样下去Pair的效率很低。首先，大家带着不爽来干活，互相质疑。更关键的是，解决问题已经用去了两个多小时，大家都比较疲惫，可以适当休息。我让你们分开的目的是让大家冷静一下，在不受打扰的情况下工作一段时间，可能会不一样。

Martin回到了电脑面前，按照他的思路一步一步做下去。Ben去上了个厕所，倒掉了那杯冷冰冰的咖啡，泡了杯热茶。回到电脑前专注的重新按照他的思路一步一步走下去。

其实两个人已经接近了真相，只是这之间不停的对话把注意力消耗殆尽。两人企图达到一个统一，然而口头的对话并不能解决问题，反而暂缓了这个过程。

10分钟后，Ben兴高采烈的说已经搞出来了一套可以运行的方案，叫Martin一同过来看看。Ben的临时解决方案比较简单好理解，但并不完美。熟悉RxJava的Martin指出了一些可以改进的地方。

然后两人又开始了新一轮的Pair，重新将这个方案完善。有了这个基础的解决方案，两人都很高兴，是朝着一个正确的方向大步向前。

下午6点半，虽然比正常下班晚了半个多小时，但还好整个解决方案都正常了，交付的任务也顺利完成。

Ben和Martin都总结道，我们应该停止结对，当：

• 两人的思路不统一但无法说服对方时：我们可以考虑分开一阵，安静一下，各自用可运行的代码来证明思路的可行。这里只需要相对粗糙的代码即可。
• 时间已经超过番茄时间而感到疲惫时：人的专注力是有限的，在Pair时非常累，特别是在能力方面存在较大差距的时候。在这时候我们可以试试番茄工作法，让大脑得到休息。
• 注意力不集中或者有其他事务要处理时：在Pair的时候，彼此要尊重对方，不要玩手机、看其他无关的网页，除非事先取得别人的同意，否则就要等到停止结对、处理完事务后再继续。

---

更多精彩洞见，请关注微信公众号：思特沃克