如果你已经跟着这个系列一路做到第九篇大概率体验过那种感觉测试先行的节奏一旦跑起来推进会变得极其顺滑绿灯一亮整个人都清爽了。但我也敢打赌你也有过这样的时刻——某个边界条件死活写不对测试失败的信息看了三遍还是一头雾水这时候旁边要是有个人直接点一句可能一分钟就解决了。这篇要聊的 Pair Programming结对编程就是冲着这种时刻来的也是我在 TDD 实战里反复验证过、觉得最值得单独拿出来讲的一个主题。文章会覆盖三件事一是为什么 TDD 做深了之后绕不开结对二是结对开发里最常见的几种模式怎么跟红绿重构循环结合三是团队落地时那些文档里不会写的坑。我尽量用实际例子讲不堆概念。已经掌握 TDD 基本节奏、想提升开发效率的读者或者团队正准备引入结对编程的负责人都可以重点看看。1. 为什么我坚持把 Pair Programming 写进 TDD 实战系列1.1 单打独斗的 TDD 会漏掉什么先说一个我观察了很久的现象单独做 TDD 的时候大多数人会在不知不觉中把红绿重构压缩成红绿两步。红灯亮了之后脑子里想的已经不是这个测试到底在表达什么行为而是赶紧让这个红变绿。一旦开始赶进度最小的那个测试会被跳过去直接写一个复杂的实现测试通过之后重构环节又经常被省略因为反正测试过了别动它。这些问题不是态度问题而是反馈回路太短、太私密导致的。你自己脑子里有一个假设写出来的测试也围绕这个假设最后代码当然会在你假设的范围内通过。旁人多问一句你为什么要写这个测试这个断言真的能测出你想要的吗往往就能挡住一大批假绿灯。结对编程在这里起的作用不是多一个人盯屏幕而是让 TDD 的三个阶段从我的私事变成我们之间正在进行的对话。红灯阶段需要说明白下一个行为是什么绿灯阶段需要说清楚为什么这是最小实现重构阶段需要讨论这个写法还有没有坏味道。每一句话都在逼你把测试先行的意图显性化。1.2 结对不只是两个人坐在一起而是把测试节奏显性化很多人觉得结对编程就是两个人用一台电脑写代码有人甚至把它简化成轮流打字。如果只是这样那结对编程的价值确实不大速度还可能更慢。真正的差异在于一个人在键盘前写代码时脑子里的大部分决策是不可见的——为什么取这个变量名、为什么先处理这种分支、为什么这个测试放在这里。但当两个人协作时每一个决策要么被说出来要么会被同伴追问。这个被迫说明理由的过程恰好是 TDD 最需要、也最容易被忽略的部分。我可以用一个例子说明。假设你正在写用户注册的逻辑单独干活时测试可能是这样的只覆盖正常注册流程密码强度规则直接写在实现里测试跑绿就收工。但有人坐在旁边局面会完全不同。他会问注册失败时提示什么用户名重复算异常还是返回结果错误这个测试是单元测试还是集成测试的分工这些问题单独时也问得出来但只有在结对环境下它们才会被稳定地、持续地问出来。1.3 这篇到底适合谁读如果你是刚接触 TDD 的开发者前面几篇已经把基本循环讲透了这篇想进一步解决一个人坚持不下去的问题内容可以重点看前两章和第四章。如果你所在团队已经引入结对但总觉得结对是形式大于内容那第五章的坑和第六章的落地思路会更贴近你的处境。如果团队远程办公第三章单独给你准备了远程结对的流程细节目标是让远程结对和线下结对尽量接近。2. 结对与 TDD 的三种结合方式从乒乓对到强风格结对编程的模式有很多种但结合 TDD 的实践我实际用下来觉得值得深入的是三种乒乓结对、强风格结对、巡航模式。前两种和测试开发的关系尤其紧密第三种是大多数团队的默认状态但很少有人意识到它需要配合作息节奏来设计。2.1 乒乓结对天然的红绿交替乒乓结对是 TDD 和结对编程结合得最自然的一种方式。规则简单A 写一个失败的测试把键盘交给 BB 让测试通过然后写下一个失败的测试把键盘还给 AA 让测试通过再写下一个失败的测试循环往复。这个过程严丝合缝地对应了 TDD 的红灯和绿灯阶段。我实际用它做过一个模拟项目需求是计算订单运费。当时和我搭档的同事先写了一个测试Test void shouldReturnZeroWhenWeightIsZero() { ShippingCostCalculator calculator new ShippingCostCalculator(); assertThat(calculator.calculate(BigDecimal.ZERO)) .isEqualTo(BigDecimal.ZERO); }这个测试明确表达了第一个行为重量为 0 时运费是 0。我让测试通过之后接着写下一个测试超过首重后的每公斤单价是 5 元。他再去实现。就这样一来一回大概 40 分钟我们把首重、续重、免运费门槛、异常订单处理全测了一遍代码逻辑非常干净。乒乓结对最大的好处是两个人都会被强制参与到测试的编写中不会出现一个人包办测试、另一个人包办实现的分工失衡。但它也有一个明显的坏处如果两边心态不对容易变成我这轮要把你难住的比赛。为了防止这种情况我一般会在一开始约定每轮测试只描述一个明确的行为不引入新的复杂概念如果一个行为需要两个人讨论超过两分钟就停下来先聊清楚不硬写。2.2 强风格结对一个人给意图一个人打键盘强风格结对是我个人的偏好特别是用来带新人的时候。规则大概是导航员只描述意图驾驶员负责把这个意图转化成代码。注意导航员不能说出具体的函数名、变量名、实现步骤只能说我想让这个函数在输入为空时返回一个默认值然后由驾驶员来思考具体怎么写。这套规则对 TDD 特别友好因为它把写测试这件事的职责明确到了导航员头上。红灯阶段导航员说我需要一个测试验证用户名超过 20 个字符时会被截断驾驶员负责把这个需求写成 JUnit 断言绿灯阶段导航员说现在让它通过但不要加多余的逻辑驾驶员负责做最小实现。我试过很多次强风格结对能非常有效地防止一个人动脑、另一个人动手的失衡。因为导航员一旦开始描述得太具体比如直接说用某个工具类截断到 20 个字符我会立刻提醒他这是实现不是意图。时间长了导航员会慢慢养成用业务语言描述需求的能力这个能力对写测试、对写用户故事都有帮助。2.3 巡航模式导航员做设计驾驶员做验证巡航模式是绝大多数团队默认的协作方式一个人坐在键盘前另一个人看着屏幕偶尔指指点点、提提意见。它听起来最平常但我发现真正做好它比看起来难得多。巡航模式里最容易出现两个极端导航员忍不住抢键盘驾驶员变成纯打字员。在 TDD 流程里巡航模式更适合重构阶段。红绿循环中红灯阶段更倾向于强风格或乒乓因为要明确行为等到功能已经跑通两个人都看到测试变绿了这时候可以切换到巡航模式导航员开始审视全局这个类的依赖是不是太多了这个测试命名是不是没表达清楚意图驾驶员负责逐步实施修改每改一步就重跑测试确保重构没有破坏已有行为。2.4 三种模式的适用场景对比我整理了一张对比表方便你根据任务性质选择模式适用场景核心优势主要风险乒乓结对新功能开发、教学、练习 TDD强制交替写测试和实现节奏公平容易演变成比谁难住谁需约束范围强风格结对带新人、抽象接口设计、需求分析逼迫用业务语言表达意图驾驶员可能跟不上导航员的思路巡航模式重构、代码审查、复杂问题攻坚一人深入实现、一人保持全局视角导航员抢键盘、驾驶员摸鱼三种模式不是互斥的一次结对 session 里完全可以切换。我的常见做法是新功能用乒乓开头把基础行为测出来中途切换到巡航模式做重构如果团队里有新人红灯阶段用强风格让新人练习把需求翻译成测试。3. 远程结对的技术选型与流程适配远程办公普及之后很多团队对结对编程的第一反应是这玩意儿线下都难搞线上肯定不行。我的看法正好相反远程结对只要把几个关键点处理好体验甚至可能比线下更专注因为干扰更少、语音沟通更明确。3.1 远程场景下的工具组合远程结对最忌讳只开一个屏幕共享然后轮流操纵桌面。延迟、光标位置、键盘焦点这些都会让两个人失去耐心。我所在的团队现在的标准做法是一个稳定的语音频道加上支持多人实时协作的代码编辑工具屏幕共享只在看测试运行结果、调试浏览器页面时才单独打开。具体说语音频道唯一的刚需是稳定。代码编辑方面建议直接用支持多人同时编辑的协作功能每个人都有独立光标谁打字谁没打字一目了然。这会极大减少现在轮到谁操作的混乱。我在几个跨团队协作的项目里都实验过凡是只靠屏幕共享的远程结对基本撑不过两周凡是换到实时协作编辑器加语音的结对就可持续下去。3.2 权限切换与过屏权问题远程结对最容易忽略的细节是权限切换。线下结对时键盘在谁手里物理上是清楚的远程结对时两个人都能打字整个画面就乱了。我给团队定的规矩是明确当前阶段的主控人这一路我来写你负责描述然后另一方的角色切换到观察和提问不要动键盘。每完成一个测试-实现的循环主控人主动说一句换你了再交接。这个过屏权的显式交接在 TDD 里尤其重要。因为红绿循环的交接点非常多如果每次都含糊效率会大打折扣。我们现在习惯把交接点定在绿灯亮起之后。也就是当前主控人负责把这一轮的测试写红、再实现到绿然后交接下一位拿到的是一个全部绿灯的稳定状态从这个基础上开始写下一个测试逻辑非常清爽。3.3 远程结对的异步补充用测试列表维持节奏远程结对还有一个线下不那么常见的补充手段异步结对。由于时区、会议安排等原因两个人在同一个时段不一定总有完整的并行时间。我们会约定先把接下来要完成的行为写成一个测试列表每一条就是红灯的候选两个人轮流各自实现列表里的条目每隔一段时间同步一次用结对评审的方式看对方写的测试和实现是否符合约定。这种做法算不上严格意义上的结对但它保留了结对最重要的东西——测试列表是两个人共同讨论出来的实现过程中有任何偏差都会在同步时暴露。我团队里有一组人长期用这个模式维护一个支付模块缺陷率比之前单干时低了不少值得作为远程下的补充方案推荐。4. 结对过程中的节奏控制一分钟一小步十分钟一检查很多人结对失败不是因为不会写代码而是因为节奏崩了。TDD 本身已经有一套节奏——红、绿、重构但那是工作流层面的结对还需要在人的层面控制节奏。这里分享几个我反复验证过的控制方法。4.1 红绿重构循环中的角色划分把 TDD 的三个阶段跟结对角色绑定是我用过最稳定的分工方式。红灯阶段的主导者通常是导航员。导航员的任务不是打字而是说清楚下一个测试描述的行为是什么。这句话本身就要足够精确输入是什么、期望输出是什么、异常情况怎么处理。说完之后由驾驶员负责把这个描述写成断言。绿灯阶段的主导者换成驾驶员。这时候聊的内容是怎么用最少的代码让测试通过不需要展开完整设计更不要顺手优化结构。重构阶段两个人平等参与导航员负责找坏味道驾驶员负责改代码每改一步重跑一次测试。如果你发现结对过程中沉默时间超过三分钟基本可以断定节奏已经断了。正常的结对应该是对话密度很高、每 30 到 60 秒就有一次小互动的状态。4.2 时间盒的设定从 25 分钟到 90 分钟给新手强调一次扎扎实实的时间盒。25 分钟的番茄钟适合刚接触结对的人它把疲劳控制在一个很低的水平也不会让两个人因为意见不合僵持太久。45 到 60 分钟是一个常见的标准区间大多数技术任务可以在这段时间内完成几个完整的红绿循环又不至于太累。超过 90 分钟的结对我一般不建议注意力会明显下降到了第 90 分钟讨论同一个 bug 的时间成本会成倍增长。我自己的实际操作是每天安排一到两个结对 session每个 session 45 分钟左右中间休息 10 到 15 分钟。休息时要求两个人离开屏幕散散步或者喝水。这样一天下来结对的总时长大概 2 到 3 个小时产出效率通常比全天结对更高。4.3 如何应对导航员过度设计和驾驶员机械打字结对过程中最常见的两种失衡在这里单独说一下。导航员过度设计的表现是明明当前测试还没过去导航员已经开始规划第三个或第四个子系统的接口了。这是结对效率最大的杀手。我的解法是强制导航员回到当前测试这个粒度。只要讨论的话题超出当前测试一步之外就把它记录到测试列表里等当前循环结束后再讨论。测试列表就是一张白纸好处是既能继续推进又不会丢失想法。驾驶员机械打字的表现是完全不加判断地执行导航员的指令哪怕指令明显有问题也直接照做。这会让导航员变成唯一的思考者结对退化成单人开发加一个翻译。解决方法是明确告诉驾驶员你有权对任何指令提出质疑尤其当指令和测试目标冲突的时候必须停下来。强风格结对里说的驾驶员负责思考怎么实现就是这个含义。5. 实战中踩过的五个坑附排查思路这些坑不是从教科书上看来的是我在真实项目里一个个踩出来的。写在这里相当于帮后来者把排查思路也一起铺开。5.1 键盘争夺战谁该碰鼠标症状两个人共处一室时光标在两个人之间来回跳动键盘上同时出现四只手远程时编辑器里出现两套光标互相覆盖。这不是协作是战争。根因角色定义模糊。大家嘴上说我们是结对但没有约定当前由谁控制输出设备。排查与解法先停下来明确回答三个问题——现在处于 TDD 的哪个阶段这一阶段的主控人是哪一位另一位此时应该做什么把这三个问题的约定写下来粘贴到显示器旁边或聊天频道置顶。实测下来规则越简单越好绿灯亮起之前键盘归驾驶员绿灯之后交接。5.2 一个人写代码另一个人看手机症状驾驶员从头到尾手不停导航员不时刷手机偶尔抬头说一句嗯行。这可能是团队里最普遍的结对变形。根因导航员没有具体任务。如果你只告诉一个人你负责看他很难不摸鱼因为大脑在缺少交互输入时天然会走神。排查与解法给导航员安排一个必须产出的任务而不是泛泛的看。比如记录测试列表、检查测试命名是否符合业务语义、跟踪每次红绿循环的时间。最有效的一招还是切换模式直接把巡航模式换成乒乓结对或者强风格结对让导航员必须频繁开口。凡是导航员长期摸鱼的结对任务基本都因为模式选错了。5.3 结对时间过长效率不升反降症状上午结对的时候神清气爽下午同一个组合继续结对两个人开始无意义地争论变量命名一个简单功能改了五遍都没定稿。根因我把这个叫过度耦合的认知疲劳。两个人持续共享上下文大脑里没有独处恢复的时间判断力会快速下降。排查与解法控制时长以 45 到 60 分钟为一个 session中间强制休息。另外一个人在同一个 session 结束后单独待一会儿梳理一下刚才的决策这是一个非常好的习惯。别小看这几分钟的独处它能把结对时讨论过的设计在脑子里固化下来。5.4 老带新变成老师写学生看症状资深开发者带着新人结对表面上是强风格结对实际上资深者一边说这个你会吧我直接写了一边把实现敲完了。新人全程没有碰过键盘。根因资深者低估了新人的动手能力也高估了自己的表达能力。他害怕新人写得太慢影响进度选择自己上手结果知识传递完全失败。排查与解法这种情况我强烈建议用严格的强风格结对。资深者只允许用意图描述我需要一个测试验证传入 null 时返回 false。新人负责写出来哪怕慢一点、丑一点。我在某项目带过一个应届生前两次结对时我用巡航模式他基本没说话切换到严格的强风格结对后第三次他就能主动说出这个测试是不是应该先检查异常分支能力的提升肉眼可见。5.5 结对编程被形式化打卡式结对症状每天固定时间两个人坐在一起但各写各的只有开周会时才想起来我们这一周结对了吗回答是结了每天都坐在一起。根因结对被当成任务指标而不是工作方式。当团队用结对次数作为评估标准时大家自然会选择最小成本的形式主义。排查与解法在复盘时不要问结对了几小时要问结对期间产出了哪些测试、完成了几个红绿循环、发现并解决了几类分歧。把这些内容写进结对话术里形式主义会自然消退。换句话说结对编程必须和 TDD 的产出物绑定否则它就只是一个办公位安排。6. 从试点到常态团队落地 Pair Programming 的三步走最后这部分写给想推动团队采用结对编程的管理者或技术负责人。我见过不少团队一开始热情高涨一周后就崩盘原因往往是直接把结对编程当成了新制度全面铺开。这里分享一套我验证过的三步走思路。6.1 第一步选对试点任务试点任务的选择决定成败。任务是学习性质的新人需要熟悉代码库还是攻坚性质的一个长期无人能解决的 bug 或一个边界情况极其复杂的模块这两种最适合作为起点。前者适合教学后者适合验证两只眼睛好过一只眼睛。千万不要把写新页面这种机械劳动选成试点因为新页面往往路径清晰、没有太多决策空间结对的优势无从体现。我在某团队选的第一个试点任务是重写一套促销规则引擎边界极多。两个人结对后拿出来的测试列表比原先整个模块的测试还完整这个结果极大地说服了观望的成员。6.2 第二步定义结对话术和反馈机制结对编程需要一套固定的对话模板否则两个人坐下来不知道该聊什么。我们团队使用的模板很简单三句话现在我们要测出哪个行为这个行为在什么输入下成立当前实现的最小改动是什么反馈机制比对话模板更重要。每次 session 结束后两人用两分钟轮流回答三个问题本轮我最认可同伴的一个做法是什么、本轮最别扭的时刻是什么、下一个 session 我要调整什么。这个反馈不追求完美只需要真实。因为许多人第一次经历结对时其实很不好意思指出对方的节奏问题这种结构化的小复盘能降低开口的门槛。6.3 第三步用数据评估而不是靠感觉结对编程的效果感性上很难判断因为短期效率大概率比单干低。要说服团队坚持下来必须有客观数据。我自己会关注四个指标红灯持续时间一个测试从变红到变绿的时间结对时应该更短、提交频率TDD 要求频繁小步提交结对时通常更高、缺陷逃逸率生产环境发现的缺陷数量结对后中位数会下降和覆盖率结对时测试覆盖往往更完整。不需要等一个月两周就能看出趋势。我团队的数据是同一个模块结对后的红灯平均持续时间比单干时少了约 40%缺陷逃逸率在三个月内下降了大约三分之二。当然不同团队基线不同但至少给你一个可参考的方向。6.4 特别提醒不要一开始就全面铺开最后一点建议是给管理者的五分钟就能教会开发团队结对编程的规则但真正接受它需要时间。全面铺开的结果通常是大量形式化的结对、甚至是打卡式结对。先在小范围里跑出真实收益让试点小组在其他成员面前展示他们的测试列表和重构记录这种同伴影响比制度推动有效得多。我自己在两家团队试过把结对时间从每天 8 小时改成每周 3 个 45 分钟 session之后采用率不降反升说明大家缺的不是热情而是一个能接受的起点。写到这里我其实更想说的是Pair Programming 的价值不在于是不是坐在一起也不在于是不是用了同一块屏幕而在于它让 TDD 这种强调反馈和展示的实践真正变成一件需要公开讨论、不断对齐的事。我个人的体会是每次结对结束最有收获的往往不是刚写完的那个功能而是那个我在解释过程中被同伴问住的问题——那正是我理解里的盲区。如果你准备尝试我的建议是从一个 45 分钟的乒乓结对开始挑一个边界条件多的模块别选那种脑子里已经有完整答案的任务。规则越简单越好先跑起来再慢慢调整。