这个夏天,再一次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