李小波:结对编程实战解析

向作者提问
一名会在 B 站直播写代码,会玩杂耍球、弹 Ukulele、街头健身、跑步、写段子、画画、翻译、写作、演讲、培训的程序员。喜欢用编程实现自己的想法,在 Android 市场上赚过钱,有多次创业经历。擅长学习,习惯养成,时间管理。身体力行地影响他人做出积极的改变!目前就职于 ThoughtWorks,致力于传播快乐高效的编程理念。业余创立软件匠艺社区 CodingStyle.cn,组织超过30场技术活动。个人公众号:小波老嬉。
查看本场Chat

2017年4月19日,晚8点30分,就职于 ThoughtWorks 成都,致力于培养优秀的程序员,也是软件匠艺社区 CodingStyle.cn 创始人,组织过超过 30 场技术活动的李小波老师,带来了主题为《如何爱上结对编程》如何爱上结对编程的交流。以下是主持人小媛子整理的问题精华,记录了小波老师和读者间问答的精彩片段。


问:请问一般建议是高低配还是按领到任务的人来配? 有哪些情况不适合结对编程?

答: 熟手带新手进行知识传递是最典型的场景,不过并不是按工作经验来划分的。 举个例子,有两个程序员,都工作 10 年,A 专注前端,B 专注后端,在结对做前端开发时,A 是熟手,B 是新手;在结对做后端开发时,B 是熟手,A 是新手。从这个角度看的话,场景就很多了,比如工具、框架、语言、平台,也可能是业务模块。如果任务简单,每个人都具备解决问题需要的所有知识,并足够自律,结对的收益就不大了。


问:两个人的开发环境,开发习惯不同怎么办?

答: 有成熟结对文化的团队会选择保持同样的环境配置,可能一开始是很个性化的,但慢慢就会互相吸取对方好的配置,最终实现了统一的环境。

另外,切换也是很方便的,比如 IntelliJ 的快捷键方案切换,2 秒就可以完成操作。想我这样用 Dvorak 键盘布局的,会自带键盘,即插即用。实在环境差别太大,我们会在切换角色时换到自己的电脑上,频繁提交,小步快走。

问:Vim党怎么破?

答: IDE 很容易统一啊,不过还有命令行,快捷键,键盘这些需要慢慢磨合。

Vim 用得好,对方会忍不住学 Vim 啊。然后所有人都变成 Vim 党了。


问:请问如何判断可以在team中推广结对编程,判断条件有哪些?

答: 结对只是一个实践,问题可以泛化到如何在合适的时机引入一个实践,我认为需要考虑:

  • 团队成员接受新事物的能力。

  • 项目的进度压力。

  • 老板的认可度。

具体到结对编程,只要团队不是同质化的(大家掌握了完全相同的技能和知识),都值得采用。


问: 如果推进中发现团队的认可度不够, 有没有什么改进的空间?

答: 先找到不认可的原因,可能他们说不出来,说出来的也不是根本原因,你可以去观察。多半是没有注意好习惯和坏习惯。说白了是不会和人相处。


问:那么同质化是指技术栈完全相同的情况么?

答: 就是大家掌握的技术栈,业务知识都差不多,那样就没有什么好传承的了。


问:结对编程有什么要求呢?比如两个新手结对肯定效果不是很好,适用哪些场景?

答: 很好的问题,新手和新手不是很推荐,但如果两个人都不是「结对的新手」的话,也是可以享受到「提高有效工作时间」,「减少错误」,「加深友谊」的好处的。


问:请问当结对人员在当前编程环境中的熟悉程度和编程能力不同,那么在结对编程时应该采取哪些措施使结对工作更高效?并使两个人的技能都能得到提升?

答: 两边的知识和能力不对等,正好可以传递知识和技能,这时「老手」就是教练的角色,要更有耐心地示范和给对方积极的反馈,帮助对方提升;「新手」在得到指导后感谢对方的传授。形成积极的学习氛围。教学相长,双方都能受益。


问:新手和老手以学习TDD实践为目的结对,是不是只能使用领航员-驾驶员模式?

答: 可以用 Ping-Pong,领航员-驾驶员,或者两者结合灵活切换都可以。


问:我可以这样认为,pingpong模式比较适合能力相当,步调一致的人结对么?领航-驾驶员模式比较适合高低配么?

答: 理解很对。领航-驾驶员也适合能力相当的。


问:分析设计在结对中如何分工比较好呢?有无最佳实践呢?

答: 结对做,一起做,不用分工。


问:分析设计? 比如 spring mvc 和 spring boot 在选型上的冲突和抉择呢?比如: android 中的 glide 和 imageloader 的抉择?比如: iOS 中 SQLite 和 Core Data 的抉择?结对者是一人说了算,还是两人讨论? 如何出结果呢?结对的时候,设计和选型 如何做呢?什么标准? 比如: android 中的 glide 和 imageloader 的抉择?

答: 这事如果是一个人做就自己定了么?不用管团队其他人?我们通常是要团队共同做决定。技术选型跟结对没有关系。两个人讨论,如果没有结果,就找第三个人来,通常是 Tech Lead,三个人就可以投票了。找第三个人来投票,或者团队一起投票。


问:具体如何把任务切分成半小时?什么时候切?

答: 领取需求后,开始写代码前,一起做任务分解,可以看之前 TDD 的 chat 里有提到。


问:我们曾经试行过一个月的结对编程,后来大家觉得没有效果废纸了,这个怎么办?

答: 得找原因,对症下药。不过做为敏捷教练也要注意,结对编程和其他实践一样,都不是银弹,不是每个团队都一定要采用的,重点是搞清它的成本和收益,灵活采用。


问: 为什么我们因为一部分团队一部分人结对,还有一部分不是。而且每天只做2小时,很快又恢复到单人状态,领导还是觉得效果一般?

答: 主要是要让程序员学会结对。会在下一个问题里详细回答。


问:如何给团队洗脑,让团队能接受结对编程?

答: 结对编程真的是一门技术,是需要学习的,那作为 Leader 或教练,就需要为团队提供必要的培训,包括知识,态度和技能。自己多示范正确的结对方式,感染其他人,慢慢就能形成结对文化。


问:前后端结对,可以做知识传承,可以理解,是不是有些前提,毕竟现在东西很多,不是很快上手,另外一点,你接触的团队,一般来说,导入结对编程需要多久,技术上有没有哪些前置条件,比如TDD?

答: 重要的不是新东西多,是开放成长的心态,有老手手把手教比自己看书学习快多了吧。我所在的团队,都采用结对编程,包括和客户合作开发的项目,这也是一种咨询服务,通过结对 Coach 客户的程序员。所以也没有周期一说。技术上没有前置条件,跟用不用 TDD 没有关系的。


问:结对过程中如果打起来了,是让他们自己分出胜负,还是趁机开盘押注?

答: 应该拿出手机拍小视频发朋友圈,吐槽结对编程果然不是一个好实践。


问:请问下在带新人的时候结对编程是不是需要向新人先解释整个代码框架 再开始结队 在编程过程中需要对新人做更多的解释吗?新人可以打断提问吗?如果这样是不是会影响老手的效率?

答: 讲多少开始写取决于老手带人的经验,原则是要保持两个人思路一致地往前走哦,鼓励随时提问。

结对时不存在「老手的效率」,两个人的腿绑到一起的,一起到终点才算赢。如果不管新手是否跟得上,那就不用结对,老手录视频,新手自己回去看就可以了~


问:怎样去衡量结对的效果,比如提高了高效工作时间,提高了质量等,这些要怎么证明真的有效果?

答: 看团队的整体产出,不看个体。比如这两周用了结对,我们可以看一下和前面比,产出增加了多少,缺陷减少了多少。


问:回归测试通过率?有效代码怎么算?产出和缺陷又怎么算?

答: 有很多指标可以可视化质量:重复代码率,圈复杂度,测试覆盖率等。产出就是故事点数。缺陷就是 Bug 数量。


问:一天结对几小时比较好?结对人员和非结对共存时怎么协作比较好?

答: 我的经验是 8 小时是上限了,结对比较烧脑。我和同事结对,为了保证效率,不带电源线,两台电脑用到没电差不多晚上 7 点。


问:如果项目比较紧急,结对是否会降低效率?这时候还适合不适合结?

答: 有一个误区是以为并行就能提高效率,但现实是因为能力分配不均造成的等待而产生浪费。所有人都是最高效的时候,不一定团队的产出最高。推荐看 TOC(约束理论),《目标》系列小说。结对看的更多是长期利益,通过知识和技能传递,消除团队中的瓶颈,得到最大的产出。推荐《凤凰项目》。


问:好奇如果不爱接受新事物,如何导入结对,如何应对交付压力?

答: 抵抗变化(不管好的还是坏的)是组织的天性,导入结对和导入其他的实践本质来讲没有任何区别。前面说过一些了,知识培训,态度辅导,技能示范。从尝鲜者开始,影响早期大众再到后期大众。这时需要的是变革的套路,《影响力》,《管理变革:组织转型基本手册》,《拥抱变革:从优秀走向卓越的48个组织转型模式》之类的书。


本文首发于GitChat,未经授权不得转载,转载需与GitChat联系。


在此感谢人民邮电出版社异步社区,为本场Chat的获奖读者提供了《代码整洁之道:程序员的职业素养》一书。

enter image description here

微信扫描登录