是什么
结对编程（Pair Programming）：两个人共用一台电脑（或一个共享环境），一起写代码。
两个角色：
- 驾驶员（Driver）：操作键盘，写代码；
- 导航员（Navigator）：观察、思考整体方向、指出问题、提出下一步。
关键是角色要切换（如每 15–30 分钟互换），保持双方都投入。
优点
一、实时代码评审
问题在写出来的那一刻就被发现——比事后评审快得多。
研究表明：结对能发现更多的缺陷（虽然代价是更多的时间投入）。
二、知识传播
- 新人通过结对快速熟悉代码库和业务；
- 避免"只有一个人懂某块代码"（巴士因子）；
- 隐性知识（如"这个系统有个历史遗留的坑"）通过结对传递。
三、减少分心
两个人在场，刷手机的概率会下降——注意力更集中。
四、设计质量
两个人的讨论往往比一个人的思考更全面。
代价
一、时间成本
两个人做一件事，直接的"人时"投入翻倍。
这是最大的争议点。 支持者认为缺陷减少和返工减少能抵消这部分成本（尤其在长期和质量敏感的项目中）；怀疑者认为在简单任务上，这个交换不划算。
二、疲劳
结对需要高度专注，通常一天结对 4–6 小时已经是上限。
三、性格与习惯的匹配
不是所有人都适合结对。有些人独立工作效率更高；有些组合会产生摩擦。
四、远程结对的技术要求
需要共享屏幕/代码的工具（如 VS Code Live Share、JetBrains Code With Me、Tuple）。
适合什么场景
适合：
- 复杂的、设计密集的任务（架构决策、棘手 bug）；
- 知识传递（新人 onboarding、跨模块学习）；
- 关键的高风险代码（安全相关、支付逻辑）；
- 解决长期卡住的问题（换个视角往往能突破）；
- 建立团队共识和代码风格。
不太适合：
- 简单的、机械性的任务（如批量改配置、写样板代码）；
- 需要深度独自思考的问题（有时一个人安静思考效率更高）；
- 纯探索性、需要大量试错的工作。
与其它实践的配合
结对编程 vs 代码评审：
两者不是替代关系。
- 结对：实时、高强度、适合复杂任务；
- 评审：异步、适合大多数常规改动。
很多团队的做法是：复杂任务结对，常规改动走评审。
Mob Programming（群体编程）：整个团队一起写一段代码——这是结对的扩展，适合需要全员对齐的关键设计。
一个实用建议
如果团队想尝试结对：
- 先从复杂任务开始，不要用在所有事情上；
- 定期交换角色和搭档；
- 控制时长（一天不超过半天）；
- 允许有人说"我想一个人静一静" —— 结对不应该是强制的；
- 远程结对等工具要提前配置好，避免把时间花在调试工具上。
一个诚实的看法
结对编程不是"银弹"，也不是"浪费"。
它的价值高度依赖任务性质、搭档匹配度和团队文化。
最务实的态度：把它当作工具箱里的一件工具，在合适的场景下使用，而不是教条地全盘推行或全盘否定。
说明：本文为软件工程实践的知识整理。