我们团队6个人，做的是一个老Java系统改造，Spring Boot 2.3升到2.7，代码量大概12万行。老板听说结对编程能提高质量，要求我们两两结对。第一周，我和另一个后端同事结对，用VS Code Live Share。结果呢？我打字他看，他打字我看。一天下来，我们只改了3个类，平时我一个人能改8个。更糟的是，Live Share免费版音频延迟大概300ms，他说话我这边要等半秒，经常互相抢话。那周我们的燃尽图直接躺平。
不是结对编程不行，是方式不对。我们复盘发现，两个人同时盯着一块屏幕，认知负荷其实很高。一个人写代码时，另一个人如果只是看，很快就会走神。而且我们犯了经典错误：没有明确角色。驾驶员和导航员应该分工，但实际中经常变成两个人都在想同一行代码。后来我们查了一些资料，也问了其他团队，发现结对编程的ROI在复杂逻辑和知识传递上最高，在简单CRUD上最低。我们那个老系统改造，其实有大量重复的DTO转换，这种任务结对就是浪费。
我们改成“乒乓模式”+“25分钟轮换”。具体步骤：1. 选一个任务，拆成2-4小时的小块。2. 两人都打开IDE，用Tuple（音频延迟40ms，每月20美元/人）或者VS Code Live Share（免费，但音频用Zoom）。3. 一个人写测试，另一个人看，然后交换。4. 用番茄钟，25分钟一到，立刻换键盘。5. 每45分钟休息5分钟，不聊代码。6. 每天结束花5分钟记录：今天学到了什么，明天谁导航。这样试了3周，我们的缺陷率从每千行1.2个降到0.7个，代码审查时间从每周6小时降到2.5小时。但功能交付速度还是慢了15%，因为两个人一起思考会陷入细节。
我们后来只在这三种情况用结对：1. 新人onboarding，大概2周，老人带新人，新人写，老人导航。2. 复杂算法或遗留代码重构，两个人一起理逻辑。3. 生产事故排查，一个人操作，一个人查日志。其他情况，比如写简单的增删改查、改配置、写文档，坚决不结对。我们还试过远程结对和面对面结对，远程更适合内向的人，因为可以文字聊天补充；面对面更适合快速白板讨论。但远程时，如果时区差超过3小时，基本没戏，我们有个同事在温哥华，和北京差15小时，结对一次要熬夜。
工具参数对比。我们试了4个工具：VS Code Live Share免费，支持5人，端口转发方便，但音频差，需要配合Discord；Tuple收费，音频延迟40ms，屏幕共享60fps，每人每月20美元；Code With Me（JetBrains）免费版30分钟限制，适合IntelliJ；Pop.com免费，但只支持macOS。如果预算有限，VS Code Live Share + Discord 足够。如果追求音频质量，Tuple值那个钱。另外，屏幕分辨率建议至少1920x1080，不然共享代码时字太小。网络带宽建议上行5Mbps以上。
很多人说结对编程是两个人写一份代码，我觉得不对。结对编程其实是两个人共同维护一个思维上下文，代码只是副产品。所以，如果两个人的认知风格差异太大，比如一个喜欢自顶向下，一个喜欢自底向上，结对就会很痛苦。我们团队有个架构师，特别喜欢先画UML，另一个同事喜欢直接写代码，他俩结对时，架构师花了40分钟画图，另一个同事已经不耐烦了。后来我们按“认知带宽”匹配，而不是按职级。还有，结对编程的社交能量消耗很大，连续结对超过3小时，质量断崖式下降。我们后来规定每天最多结对4小时，分两个时段。
如果你要试结对编程，先别全员推广。找2-3个志愿者，选一个中等复杂度的任务，预计2-4小时。准备好工具，定好轮换规则。记录三个指标：缺陷率、周期时间、知识共享（可以简单问卷）。试两周，如果缺陷率没降，或者大家很痛苦，就停。别为了结对而结对。我们最后只在20%的任务上用结对，但就是这20%的任务，贡献了60%的bug修复。所以，结对编程不是银弹，是一把手术刀，用对地方才有效。