文章讲的一个故事，来源于真实的事件改编，情节有所夸张，请勿对号入座。

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

开始

Ben：看来这不是一个很大的问题，就是handle一个来自于远端服务的异常。现在的处理方式是BFF(backend for frontends)在内部的远端服务有异常会将的异常直接返回到客户端，这样只要一个保单除了问题，前端所有的保单都也没法用了。
Martin：那怎么解决？
Ben：感觉可以在得到异常的地方加一个异常的处理。这个涉及到RxJava和Java8的stream特性，我不是太熟悉，要不我们一起Pair吧。
Martin：好。

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

Martin：对于可以重现的故障通常比较好解决。我们在这里先弄个try...catch试试。

大家似乎很有信心，然而重启项目后，故障并没有按照预期停下来。

Ben：hmm，这里为什么停不下来呢？
Martin：可能是RxJava的延迟处理，没有正确的catch到。这样，你在这里再写一个逻辑，然后在这里设个断点……

焦急

Martin只是对着屏幕指指点点，时不时看看手机在微信上聊聊天。因为Ben对RxJava并不是很熟悉，Ben想紧紧的跟随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采用他的方案试试。

怒气

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

Zen在运行测试的空挡，打断了两人的对话，建议到：既然大家已经产生了分歧，那要不然两个人分开一个实现一个，看谁能够先实现，然后再来讨论。

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

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

冷静

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

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

10分钟后，Ben兴高采烈的说已经搞出来了一套可以运行的方案，叫Martin一同过来看看。Ben的临时解决方案比较简单好理解，但并不完美。熟悉RxJava的Martin指出了一些可以改进的地方。然后两人又开始了新一轮的Pair，重新将这个方案完善。有了这个基础的解决方案，两人都很高兴，是朝着一个正确的方向大步向前。

尾声

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

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

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