
在伦敦 QCon 技术大会 上,Ola Hast 和 Asgaut Mjølne Söderbom 就结对编程实现持续交付的话题做了分享。他们的团队采用基于 TDD 的结对和群体编程方式,不设单独任务和独立代码审查环节。这种做法提升了代码质量、减少了浪费,还促进了知识共享。此外,频繁的休息有助于保持专注和心流状态。
该团队采用共同进行代码评审的方式,而不是来回发送拉取请求,Mjølne Söderbom 解释说:
2021 年,我和 Ola 刚加入同一个团队时,我们决定一起完成所有工作。当时并非所有人都认同这种做法,因此部分成员仍然独自工作。但如果 Ola 或我参与其中,他们别无选择——必须结对编程。
Mjølne Söderbom 指出,团队中至少有两人愿意进行结对编程,这个非常关键。仅靠一己之力说服整个团队会很困难。他们还大量运用结对编程来培训新成员。过了一段时间,大家逐渐认识到,这确实是一种正确的方式,他说。
所有任务都适合一起完成,没有人会独自负责某项任务,Mjølne Söderbom 说。一项任务始终至少有两人参与。如果其中一人不在(例如,某人要去开会时),另一人可以单独编码,然后再一起同步。
Mjølne Söderbom 的团队共有四名开发人员,他认为这是一个理想的规模。如果四人都在,他们会分成两对进行结对编程。有时也会四人一起进行群体编程,尤其是在处理新任务或需要做出重大决策时。这样,他们可以在分头行动前传播知识。如果是三人,他们总是以群体形式工作,他说。
Mjølne Söderbom 解释说,他们每 7 分钟轮换一次驾驶员和领航员的角色,结对时则是每 10 分钟轮换一次:
在办公室时,我们会用一个廉价的厨房计时器来计时。我们楼层上还有几个团队也买了同样的计时器,所以当你听到计时器频繁响起时,会觉得很有意思!当有人远程办公时,我们也会结对编程,通常只需在 Teams 上共享屏幕即可。
Mjølne Söderbom 说,如果换驾驶员时需要更换机器,他们有一些别名可以快速提交并推送到 Git。大家的键盘和按键映射设置各不相同,有时直接换到另一张桌子会更方便。他还提到,GitHub CLI 的别名也能帮助他们在完成后快速创建和批准/合并拉取请求。
Mjølne Söderbom 表示,他们对所有工作都采用了 TDD,并且非常喜欢这种方式。由于评审是整个流程的一部分,因此无需额外花时间进行单独的评审。由于他们结对编程并对所有代码进行 TDD,因此所有的评审和架构决策都是实时进行的,他解释说:
仍有人认为结对编程仅适用于某些通常较为复杂的任务。然而,我们发现事实并非如此——所有任务都适合一起完成。从长远来看,结对编程将以一种与以往截然不同的方式提升速度和促进知识共享。
Mjølne Söderbom 表示,他一直对整洁代码和代码质量非常感兴趣,而结对编程与之相辅相成。他想不出还有其他方法或工具能比一起工作提供更高的质量,他总结道。
InfoQ 采访了 Ola Hast 和 Asgaut Mjølne Söderbom,了解他们团队的工作方式。
InfoQ:你们如何衡量和减少浪费?
Ola Hast:结对工作的妙处在于,当构建或流程耗时较长时,大家会开始讨论。第一次通常没问题,但如果连续多次耗时过长,就会成为问题。我们随后会开始讨论解决方案和变通办法。
通常,耗时过长是一种直觉,而交接问题往往只有亲身体验后才被注意到。如果你无法在不涉及团队外人员的情况下重复执行某项任务,或者团队中的特定任务依赖特定人员,那么这就是导致延迟和浪费的根源。
我们发现,当人们单独工作时,他们对等待、缓慢的构建等情况的容忍度会更高,而结对工作确实能自然地推动我们减少这种浪费。
InfoQ:代码在进入生产环境前需要审批吗?
Asgaut Mjølne Söderbom:任何形式的单独工作都意味着你需要他人来审查和批准代码。大多数公司将审查作为合规要求。而在结对编程时,这部分工作已经在开发过程中完成了。
InfoQ:休息有多重要?
Hast:一起工作,尤其是当你全神贯注时,会很紧张。因此,适当的休息很重要,要离开屏幕和键盘。
去街区走走,呼吸些新鲜空气。无论你做什么,都不要尝试做其他事情,比如查看邮件或 Slack。
原文链接:
https://www.infoq.com/news/2025/07/pair-programming-speed-flow/
评论