作者:我是思聪

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

这是一个风和日丽的星期五下午,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的时候,要尊重对方,不要玩手机、看其他无关的网页,除非事先取得别人的同意,否则我们停止结对,处理完事务后再继续。
余下全文(1/3)
分享这篇文章:

请关注我们:

发表评论

电子邮件地址不会被公开。 必填项已用*标注