7个你需要知道的结对礼仪

结对编程远远不是两个程序员坐在一起写代码那么简单。 — 鲁迅(没有说过)

结对编程

结对编程可能算是比测试驱动开发更具有争议的敏捷实践了,事实上,仅有很少的团队可以很好的实施它并从中受益,对于更多的团队来说,即使在践行敏捷的团队中,也常常会分为旗帜鲜明的两个阵营。提倡者往往会强调结对编程在“传递领域知识”,“减少潜在缺陷”,“降低信息孤岛的形成”等方面的作用;而反对者则认为结对编程在很多时候都是在浪费时间:开发者在实践中很多时候都难以聚焦,容易产生分歧,另外个人的产出往往也难以度量。

这篇文章不打算讨论结对编程对效率的影响,也不讨论要不要进行结对编程,当然也不会涉及以何种力度来执行结对。这里的假设是团队决定采用结对编程,但是对于如何实施存在一些疑虑;或者已经在采用结对编程的团队里,发现很多时候结对编程并没有很好的发挥作用,需要一些更有实践意义的指导。

结对编程远远不是两个开发者坐在一起写代码那么简单。作为一种科学且充满趣味性(才不是)的工程实践,事实上它是有一些基本原则的,团队里的开发者需要正确的实施这些原则,结对编程才有可能为团队带来实际的受益。

假设你找到了另一个程序员,并且已经准备好一起来编码实现一个具体的业务需求。在开始着手开始结对之前,你首先需要setup环境。

硬件设置

工欲善其事,必先利其器。首先你和你的peer需要一个大的外接显示器和有一个可以调节高度的桌子(当然也可以用纸箱子DIY一个低配版)。这一点往往被初学者忽视,而事实上它可以直接决定结对能不能作为一个可持续的团队工程实践。如果你的颈椎长时间处于不舒服的状态,你的注意力很快会退散,精神会变得难以集中,而一个处于病态的身体是无法支撑长时间的编码工作的。

在开始之前,请将屏幕调整到舒适的高度,以不仰头不低头为度(身高不一样的两个人可以通过调整椅子的高度达到基本一致)。此外还要注意看屏幕的角度,如果你需要抻着脖子才能看清楚屏幕,那么当时间稍长一点时,你的颈椎也会非常吃力。因此,如果条件允许的话,你和你的peer可以使用双屏来进行结对。

当然,还有一些常见的其他关于硬件准备的细节,比如:

  • VGA/HDMI转接头
  • 充足的电源
  • 键盘/鼠标转接头
  • 便签和笔

纸和笔永远是你(们)的好朋友,在实际动手写代码之前,请拿出纸笔来将要做的事情划分成更细粒度,可以验证的任务列表,贴在显示器的下边缘。最后,另外记得将手机调成震动模式,利人利己。

软件设置

硬件准备好之后就可以进行软件的配置了。软件问题远比硬件复杂,因为大部分开发者都有自己钟爱的工具集,小到curl/wget,大到Vim/Emacs,不要期望在这个问题上和peer达成一致,这是可遇而不可求,可望而不可即的。

根据我自己的经验而言,高级一些的IDE比如JetBrains出品的Intellij,WebStorm等都可以随意切换快捷键集合(keymap)。如果你和peer就快捷键的使用上无法达成一致,在轮到你输入代码的时候,你可以切换到自己熟悉的Keymap,反之亦然。

在Intellij/WebStorm里,你可以通过ctrl+来切换各种设置,比如选择3就可以切换不同的Keymap,然后在下一步的窗口中按照自己的喜好进行切换预设的Keymap。某项目的王晓峰(Vim党)和张哲(Emacs党)尤其擅长此技,他们两人结对时,可以做到在抢键盘的瞬间将keymap切换到自己的挚爱而对方无察觉的地步。

这种技法事实上仅仅对于结对双方都有很高超的键盘操作能力的前提下,也唯有这种场景下,双发可以互不妥协。对于另一种场景(可能在实际中更为常见),比如结对一方键盘技巧和操作效率低下,影响结对流畅程度的场景,则需要效率低下的一方自己摒弃陋习(使用鼠标而不是键盘),快速赶上。

和别人结对之前,你需要至少熟悉一个IDE/编辑器,比如通过纯键盘的操作完成

  • 按照名称查文件
  • 按照内容搜索
  • 定位到指定文件的指定行/指定函数
  • 选中变量,表达式,语句等
  • 可以快速执行测试(可以在命令行,也可以在IDE中)

熟常基本Shell技能和常用命令行工具的使用,可以完成诸如

  • 文件搜索
  • 网络访问
  • 正则表达式的应用
  • 查找替换文件中的内容

等操作,这样在结对时可以大大提高效率。这些都是稍加练习就可以掌握的技能,并没有多少技术含量在内,而且学会了可以收益很久。

当知识不对等时

好了,铺垫了这么多,终于到了正题部分。最理想的结对状态是,双方的技能水平相当,知识储备基本类似,可以非常流畅的进行交流,在结对过程中可以完全专注在需要解决的问题本身上,讨论时思想激烈碰撞,编码时键动如飞,不知日之将夕。这种场景下完全不需要任何技巧,随心所欲,自由发挥即可。与此对应的另一种场景是双方都没有任何储备,技能也无法胜任,这种情况我们需要在项目上完全避免。

这两种极端的情况之外,就是不对等的场景了,这也是现实中最为常见的case:很多时候,结对双方会有一个人比较有经验,而另一个人则在某方面需要catchup。比如一个老手带一个新手,或者一个擅长业务的开发和另一个该领域的新人结对等。

一般而言,需要双方有一个人来做主导,另一个人来观察,并在过程中交互,答疑解惑,共同完成任务。与传统的教与学不同的是:结对需要的是两个智慧头脑的碰撞,而不是单方面的灌输。因此观察者不是单方向的被动接受,主导者也并非完全讲述。事实上结对是一个会有激烈交互的过程。

主导者

对于主导者来说,千万不要太投入,而无视peer的感受。这种场景非常常见,我自己有时候也会不自觉的忽略掉peer,自顾自的写代码,很多时候把peer当成了小黄鸭。这时候你的peer会有强烈的挫败感,也很难跟上你的节奏,从而影响结对的效果。作为主导者,需要更耐心一些,不断的和自己的peer交互。

另一个极端是,主导者太热心的coach,而忽视了给新人实际锻炼的机会。这时候需要主导者给peer更多的实践机会:比如在带着新人编写了一个小的TDD循环(红绿重构)之后,可以抑制住自己接着写的冲动(我知道这个非常困难),然后将键盘交给你的peer,让他模仿你刚才的做法来完成下一个。

有时候,当你看到peer正在用一个不好的做法来完成任务时,你可以即使让他停下来,并通过问问题的方式来启发他:

  • 还有更好的做法吗?

如果peer仍然在迟疑的话,你可以进一步提示:

  • 你觉得XXX会不会更好?

一个实际的例子是,你们在写一段JS代码来迭代一个列表,你的peer正在用for循环来操作一个数组,而你可以提议使用Array.map。有些时候,你的peer会给你一些惊喜的回答!他的回答甚至比你预想中的更加出色,你也可以通过这种方式来向他学习。

观察者

另一方面,作为观察者而言,结对毋庸置疑是一种特别好的学习机会,你应该抓住一切可能的机会来向你的peer学习。包括快捷键的使用,命令行工具参数的应用,良好的编程习惯等等。保持你的专注力和好奇心,比如你看到peer神器的通过快捷键删除了花括号(block)中的所有代码,或者将curl的返回值以prettify过的样式打印到控制台,或者通过命令行merge了一个PR等等。

在实践的时候,可以采取Ping-Pong的方式来互换主导者和观察者的角色。比如,A写一个测试,B来写实现,A来重构,然后换B来写测试,A来实现,B来做重构等等。开始时,可能会由一个人来主导,随着合作越来越顺畅,你们可以提高交换的频次。

保持专注

在选定了要两人一起解决的问题之后,你们需要一起完成任务划分。这样可以确保你们可以永远关注在单一任务上,避免任务切换带来的损耗。

在做完一项任务后,用mark笔轻轻将其从纸上划掉(或者打钩)。千万不要小看这个小动作的威力,它既可以将你们的工作进度很好的表述出来,也可以在任何时候帮助你们回到正在做的事情上(特别是在吃完午饭之后),另外这个微小的具有仪式感的动作是对大脑的一个正向反馈,促进多巴胺的分泌(代码写的这么开心,还要什么女朋友?)。

很多时候,我们需要暂时搁置争议,保持前行。

无法统一的意见

如果你遇到了一个固执己见的同事,而不凑巧的是你也是一个难以被说服的人,那么如何处理那些无法避免的争论呢?特别是那些没有对错之分的技术问题。比如那种编程语言更适合Web开发,比如如何践行TDD(比如自顶向下的TDD和自底向上的TDD)等等。

有时候,我们会非常坚持自己觉得对的东西,觉得那就是真理。挑战这个真理的不是傻就是二,但是用不了多久,我们就会发现,换个角度好像也说得通,特别是在和其他人结对,并突然意识到以前的那个完全无法接受的做法似乎还是有几分道理的。

在我刚做完的一个前端项目中,做技术选型时我自然的选了更早项目中使用的scss module,而团队里的另一个同事则提议使用styled-component。我们谁也没有说服谁,最后写代码的时候就有两种风格。直到有一天,我在代码库里看到了用styled-component写的很漂亮的组件,我自己尝试着把相关的scss重写成styled-componet,结果发现确实比单独的scss文件要更好维护一些,而且也不影响既有的测试。

我突然意识到,我所坚持的只是一个假的“真理”,先前的坚持和做技术选型时的理由就变得很可笑:那只不过是为了使用自己熟悉的技术而编造的理由而已。保持open mind是一件知易行难的事情,希望大家在争辩时能念及这个小例子,可能会少一些无谓的争辩。

对于这种难以统一意见的场景,我建议可以将其搁置,先按照某一种提议进行,知道发现明显的,难以为继的缺陷为止。往往你们会发现一条比较折中的路,或者一个人被另一个人说服。

棘手的任务

即使很有经验的程序员也会遇到新的领域,或者在熟悉的领域遇到新的困难。有些情况下,作为结对的两个人都对要完成的主题没有头绪。这时候非要挤在一起反而会降低速度,无助于问题的解决。

一个好用的实践是,两人分头研究,并严格控制时间。比如Time box 30分钟。不过很可能在30分钟后,你们中至少有一个人已经对要怎么做有了头绪,如果30分钟还没有头绪,则可以求助团队其他成员。

比如我在最近项目上遇到了Kerberos认证的问题,我和peer都没有接触过,在经过20分钟的独立spike之后,我发现了一篇细节很丰富的,看起来很靠谱的技术博客,而我的peer则在内部github上找到了另一个团队的可以工作的代码(虽然代码质量不是很好)。我们最终决定copy+paste,然后做重构的方式继续前进。而那篇技术博客则是一个很好的课后学习的资料。

张弛有度

注意力是一种非常稀缺的资源,普通人很难全神贯注在某件事情上超过30分钟。一旦超过这个时间,大脑就开始偷懒,开小差。这时候一个短暂的break可以让大脑得到很好的休息。人类的大脑有一个非常有趣的特性,就是它的后台任务处理能力 — 而且后台处理能力好像远远强大于前台。你可能会在去冲咖啡的路上,突然灵光一闪,那个困扰你多时的问题有了思路,而此时此刻的你的大脑明明在想如何用咖啡机冲一份拿铁。

如果遇到一个难以理解的bug,或者在设置测试环境是遇到了困难,休息一下很可能帮助你找到解决问题的新角度。为了避免长时间纠缠在冥思苦想中,你和你的peer可以采取比如番茄工作法之类的时间管理工具:

  1. 从Todo列表中找出下一个任务
  2. 设置一个不可中断的25分钟,开始工作
  3. 时间到了之后,休息5分钟
  4. 重复2-3,4次之后休息15分钟

这里有一个在线工具可以直接使用 ,你也可以用手机的闹铃工具。

结对轮换

如果结对的对象长期固定的话,pair本身又会变成新的信息孤岛。比如A和B长期负责订单模块,而C和D则一直在写门店管理,那么毫无疑问,一段时间后,A和B就不知道C和D在做什么了,不论是领域知识还是技术实践,都很难得到有效的知识传递。当一个团队规模变成10+之后,这还可能演化成更为严重的项目问题。

因此需要定期或者不定期的轮转,比如一周轮换一到两次,A和C来写订单,B和D来写门店管理,这样可以保证领域知识,工程实践,工具的使用等等知识都很好的在团队内部共享。

在一些场景下,团队采取前后端分离的方式进行开发。前端和后端的技术栈选择大相径庭,每一端都有不同的约定和复杂的配置,这会对结对轮换的实施造成障碍,而且短期来看还会影响开发效率。如果团队再大一些,DevOps可能会独立出一个小组来负责,这将导致结对的轮换更加困难。

在实践中,我发现让不同角色的团队成员轮换结对所带来的好处(伴随着短期阵痛的)远胜过知识的隔离带来的坏处。团队中的前端开发如果花费一些时间和DevOps一起结对,他会对系统的整个架构更加清楚;而后端开发和DevOps结对则可能让他意识到代码中的潜在缺陷和解决方法(比如会话外置,缓存策略等)。

尊重

作为一个最小单位的团体活动,你常常要站在你的peer的角度来看问题。如果你不愿意和某一特性的人结对,那么首先不要让自己成为那样的人。比如你讨厌只闷头写代码,不理会peer有没有跟上的那种结对方式;又或者你不喜欢和用鼠标完成又低效又别扭操作的人一起写代码(我在和这样的人结对的时候,都需要费很大力气抑制自己,才不会从peer的手中把鼠标抢过来扔掉),那么首先让自己不是那样的人。

除此之外,尊重还体现在很多其他细节中。当你不得不中断结对而去做其他事情时,务必让你的peer知道。而且在离开之前,你应该表示歉意,不要凭空消失,然后若干分钟后又凭空出现,没有人喜欢和一个不靠谱的人工作。比如10点30分的水果时间到了,你看到有人拿着你喜欢吃的桃子从厨房方向走了回来。你可以示意peer暂停一会,然后去厨房拿点水果,记得给你的peer也带上一些。

另一方面,当你的peer回来之后,你需要及时和他catchup,告诉他你正在做什么,已经做到了哪一步等等。快速的将他带入到上下文中。

控制情绪

情绪是一件非常微妙的事情,它具有很强的传染性。当你们的工作任务收到各种blocker,被各种其他事情干扰而导致进度难以推进时,一定要注意自己情绪的控制。如果你的peer一直在旁边唉声叹气,或者抱怨连连,你会变得非常沮丧,并且很难集中精力在积极解决问题上。

你可以通过积极的寻求外部帮助,或者将blocker更快的可视化出来,让团队了解,并提供可能的帮助。

课后练习

和你的peer完成了充实而卓有成效的一天之后,你需要总结一下自己记录的知识点,这是一个绝佳的提升自己能力的方法。通过实战,发现自己的缺点,并通过近距离观察别人如何解决该问题,最终会以很深刻的印象记录下来,这时候针对性的查漏补缺是可以取得非常好的效果。

比如你已经习惯使用grep来做搜索,结果你的peer娴熟的awk技巧使你打开眼界,你可以在课后专门学习一下这个工具的各种选项,并尝试熟练应用。或者你们在代码库中探索到webpack的一些特殊配置,它可以良好工作,但是你不是很明白背后的原理,这些都可以放在结对结束之后自己消化。花一些额外时间来更新你的技能可以让你在第二天的结对中更加得心应手,也可以更好的融入到结对编程带来的快乐中。

这些结对的基本礼仪,都是一些微小的细节,做好了可以让和你一起工作的人比较舒服,也会帮助你自己建立一个更加高效的工作环境。

小结

在这篇文章中,我总结了一些有关结对编程的常见的问题和解决方法。在开始进行结对之前,首先需要确保硬件设施正确setup,这样可以保证大家可以在很轻松舒适的环境中工作。在软件设置上,保证效率的前提下,可以有不同的偏好设置。当能力不对等时,恰恰是结对编程最能发挥作用的场景,不但对于观察者来说是绝好的学习过程,对于主导者而言,也可以从coach过程中看到一些不同的东西。

在结对编程过程中,你们需要始终保持专注,可以通过任务拆分的方式来帮助一直关注在单一事项上。此外,应该有定期的休息,让紧张的情绪得到缓解。为了避免大尺度上的信息孤岛,团队还需要定期的进行Pair的轮换。

总而言之,通过这些方法的使用,可以有效的促进工作效率,促进个人成长为前提,并和可以形成很好的团队氛围。


更多精彩洞见,请关注微信公众号:ThoughtWorks洞见

Share

这个夏天,再一次coding with her

“毕竟我们只有这一次结对的机会,一个题目总要善始善终,所以不知不觉就写到了凌晨两点,和小伙伴用git协作,寝室只有我的电脑屏幕发出微弱的光,感觉夜晚如此静谧,而我们的大脑和手指都在激烈又高速运转着,我喜欢这样忘我的感觉。”

再遇见

在参加完第三季ThoughtWorks最佳编程体验之旅活动后,凯欣在自己的博客中写下了这样的回顾,这是她第二次参与最佳编程之旅。同样经过了为期四周的线上编程挑战,同样是从一千多名网申报名者中脱颖而出,最终与其他127名学生一起来到ThoughtWorks位于北京、武汉、西安、成都、深圳五城的根据地体验结对编程。

(第三季最佳编程体验——五城集结)

这次活动从开始报名到最终落幕共历时一个月,大家在其中学会的第一课可能就是——坚持。平心而论,今年的线上题目难度并不高,在题目截止之前,ThoughtWorks工程师还在线上分享过程中“无心插柳”的讲解了考题,并对同学们在这一过程中所遇到的问题进行解答。意在让大家遇到难题时能够选择直视问题、正面出击,毕竟在真实的工作场景中,“退缩”从来都不可取。

但即便如此,仍然有近90%的报名者在两轮线上答题赛中退出。最终,留到最后的128名同学在6月8号聚集在了一起。提到这次相聚,凯欣用了“久违”二字。这其中并不全是怀念,在去年的编程体验中,她算是抱憾而归。在侧重于“交付完整产品”的比赛中,由于纯粹追求设计思想与代码质量,忽视了内部研究,最终与第一名失之交臂,还错失了心心念念的“无人机”奖品。在朋友圈看到活动信息后,她第一时间报了名,想看看今年的玩法会有什么不同。

确认过眼神,遇上对的人

第三季最佳编程体验之旅的主题是“Coding with her”,作为全球最佳女性科技雇主,ThoughtWorks认为在科技领域男性和女性没有差别,在校招过程中也一直坚持男女比例1:1。在第一天的碰面中,同学们就见到了来自ThoughtWorks气场全开的几位小姐姐,她们都是公司内部非常厉害的程序媛,能文能武,可以利落的解决技术问题,也可以很好的兼顾工作与家庭,被内部同事称为“刀马旦”。

初遇“刀马旦”,倾听她们讲述ThoughtWorks的文化理念、职业经历与个人实践,学生们也在这个过程中“确认眼神、找到对的人”,定下后面两天结对编程的coach。凯欣选择了北京办公室的大姐大——禚娴静作为coach,因为“喜欢她的气场,感觉莫名亲切,喜欢投缘的人。”

紧张Coding,快速交付

作为第二次参加的“过来人”,凯欣对结对编程的概念及方法、TDD(TDD是敏捷开发中的一项核心实践和技术,也是一种设计方法论。TDD的原理是在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代码)等实践方法都有所了解。在听完讲解、拿到需求后,就迫不及待的想要开始做整体设计。

这时大姐大却提醒她们,要着眼于当下需求,“我们就很听话地从实现第一个需求开始测试驱动开发,我写测试,小伙伴写实现,一路乒乒乓乓,极其尽兴,几乎忘了所有人的存在,沉浸在程序世界无法自拔,不知不觉就到了五点半截止时间,代码还有一点不太完美的地方,纠结要不要继续改,担心犯规什么的,我们俩最后一致决定要完成它,在最后完成所有基础需求的时候,我们给大姐大做审阅,大姐大咔咔咔指出n个不足,最有感触的一句话是:测试要从需求层面写,我当时好佩服啊,架构师就是不一样,一眼就能看出问题,给我们宏观的把握,接受完指点后感觉自己好幸运,那天晚上非常愉快地从大厦出来,和小伙伴一路商讨,回顾大姐大的点评,想到代码有哪些不完美,我们俩就哪哪都不舒服,也顾不上什么规则了,决定晚上回去继续做。”

在为期两天的编程和showcase过程中,大姐大一直守护在身后,对凯欣小组所遇到的问题进行引导。在这个过程中,回答问题并非主要目的,更重要的在于“授之以渔”,让她们拥有解决问题的思路。这不同于课堂上的直线教学,在真实项目中,问题是无法精确预见的,只有解题思路能够常存心中。这也是为什么ThoughtWorks要把最终脱颖而出的学生聚集到一起、让大家去体验真实的开发过程和工作场景。

(凯欣小组)

最终,在最后一天三分钟的showcase过程中,凯欣和小伙伴赢得了在场coach的称赞,并成功拿下“小蜜蜂”奖品。更让她开心的是,这次奖品的设置是从多个角度进行衡量的,——“这和平时的单一评判标准(分数)决定学生好坏的片面评价不一样,衡量一件事就该多方面衡量,每个方面做的出色的同学都该得到鼓励和表扬,这一点就比第二期的活动做的更好, 很走心。”

尾声

6月10日下午,为期两天半的线下结对编程结束,走在回去的路上。凯欣在回味大姐大点评的同时或许也会想到大姐大的开场分享,“我不知道我50岁的时候会在做什么,但是,一想到很可能是在写代码,我就很开心。我也曾经无数次的想过要选择放弃,但是我站在这里就是最好的答案。”


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

Share

请停止结对编程

(根据真实事件改编,情节有所夸张,请勿对号入座。)

这是一个风和日丽的星期五下午,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的时候,彼此要尊重对方,不要玩手机、看其他无关的网页,除非事先取得别人的同意,否则就要等到停止结对、处理完事务后再继续。

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

Share