# 结对编程 Pair Programming
## 定义
结对编程由两个程序员共享一个工作站（结对中的一个屏幕，键盘和鼠标）组成。键盘上的程序员通常称为“司机”，另一个也积极参与编程任务，但更侧重于总体方向的是“领航员”。期望程序员每隔几分钟左右交换一次角色。
## 也称为
更简单地说是“配对”；短语“成对编程”和“成对编程”也较少使用。
## 常见陷阱
- 两位程序员都必须在成对的会话中积极参与任务，否则无法预期会有任何好处
- 一个简单但经常提出的异议是配对“使成本翻倍”；这是基于将编程等同于键入的误解–但是，应该意识到，这是应用不良配对的最坏情况
- 至少应该对驱动程序以及可能的两个程序员进行实时注释。配对编程也“大声编程” –如果驾驶员沉默，则导航仪应进行干预
- 结对编程不能有效地强加于人，特别是在诸如最平凡的人际关系问题（例如个人卫生）受到阻碍的情况下；首先解决这些！
## 起源
各种名人的名字都被引用，以试图使成对编程具有一定的光环，即使不是神圣不可侵犯。John Von Neummann，Fred Brooks，Jerry Weinberg，Richard Gabriel或Edsger Dijkstra的轶事使人着迷，但有时难以证实。但是，以下可验证消息来源的时间表确实表明，以现代形式出现的结对编程早在敏捷运动之前就已经存在：
- 1992年：“动态二重奏”是拉里·康斯坦丁（Larry Constantine）创造的术语，该词是对Whitesmiths Inc.的一次访问，Whitesmiths Inc.是由PJ Plauger（C的实现者之一）创办的编译器供应商：“在每个终端都有两个程序员！当然，实际上只有一个程序员在每个键盘上削减代码，而其他人则在他们的肩膀上凝视着。” 白人铁匠从1978年到1988年成立。
- 1993年：Wilson等人的“合作对学生程序员的好处”。是一项早期的经验研究，表明配对特别有助于编程任务。后验研究更加丰富，在“ 极限”编程已经通过“ 极限编程”获得普及之后，人们就渴望“验证”配对编程。
- 1995年：吉姆·科普林（Jim Coplien）在第一本模式书《程序设计的模式语言》中的“一种生成的开发过程模式语言”一章中，以亚历山大模式的形式对模式“成对发展”进行了简要描述。
- 1998年：在有关极限编程的最早文章“克莱斯勒走向极限”中，结对编程被介绍为C3团队的核心实践之一；后来被正式描述为XP的原始“十二种做法”之一
- 2000年 ：（或更早的版本）–引入了Driver和Navigator的角色来帮助解释结对编程；最早的参考文献是邮寄清单 ; 但是请注意，这些角色的现实存在争议，例如Sallyann Bryant的文章“结对编程和导航员的神秘角色 ”
- 2002年：Laurie Williams和Robert Kessler撰写的“ Pair Programming Illuminated ”是第一本专门针对实践的书，并讨论了它的理论，实践以及迄今为止的各种研究。
- 2003年：C2 Wiki上的一篇匿名文章描述了Ping-Pong编程，这是一种适度流行的变体，它与测试驱动的开发配对。
- 2015年：James Coplien出版了《两个头脑比一个头脑要好》，该书概述了结对编程的历史，该历史可追溯至1980年代中期。
## 技能水平
如上所述，阻止有效配对的主要问题之一是被动性。当与测试驱动的开发同时使用时，一个叫做“乒乓编程”的变体鼓励更频繁地切换角色：一个程序员编写失败的单元测试，然后将键盘传递给另一个编写相应代码的程序员，然后继续进行操作。一个新的测试。此变体可以纯粹用于教学目的，或者由经验丰富的程序员用作有趣的变体。
- 初学者：
- 能够作为导航员参与，尤其是进行适当的干预
- 能够作为驾驶员参加，特别是在编写代码时解释代码
- 中间
- 可以告诉合适的时机放弃键盘和切换角色
- 可以告诉正确的时机“偷”键盘并切换角色
- 高级
- 能够在另一对正在处理任务时“插入”并平稳地接管导航器角色
## 使用迹象
- 设置房间的家具和工作站以鼓励配对（无论是新手还是敌对的团队，都可以容忍明显的错误，例如桌子的空间不足以容纳两把椅子）
- 房间的噪音水平受到控制：几对同时进行的静音对话会产生背景嗡嗡声，但不会升高到会干扰任何人工作的水平
- 如果在进入房间时发现任何戴着音频耳机的程序员，都将其视为“负号”，那么不仅团队中可能没有进行配对，而且成功采用的条件可能不满足
## 预期收益
- 更高的代码质量：“大声编程”可以更清晰地表达编码任务中的复杂性和隐藏细节，从而减少出错或掉入盲区的风险
- 更好地在团队中传播知识，尤其是当不熟悉组件的开发人员与了解得更好的组件配对时
- 初级开发人员从经验丰富的团队成员那里学习微技术或更广泛的技能，从而更好地进行技能转移
- 大大减少了协调工作，因为要协调N / 2对而不是N个单独的开发人员
- 与单独的开发人员相比，提高了团队对中断的适应性：当团队中的一个成员必须参加外部提示时，另一个可以专注于任务，并可以在以后帮助重新获得焦点
## 潜在成本
尽管经验研究尚未就收益或成本产生确定的结果，但相对于单个工作，通常被引用的最佳案例是系统配对的15％开销。据称，这种开销（再次获得了一些经验支持，尽管并不完全是结论性的），但可以通过代码质量的提高来弥补，这通常会给以后的维护带来重大损失。
## 学术出版物
理论上
- 在更有趣的理论论文中，有一些是由Sallyann Freudenberg（néeBryant）倡导的人种学方法，他们对程序员的日常工作进行了仔细的考察：
- 配对编程的实际工作原理概述了一些攻击“驾驶员/导航员”区别的工作
经验
- 劳里·威廉姆斯（Laurie Williams）的博士论文“协作软件过程 ”报告了该问题，它的质量有所提高，并且没有明显的统计开销
- 结对编程的有效性：一项荟萃分析，调查了18项主要的实证研究，报告了质量提高和进度紧缩的情况，但费用有所增加；计划压缩主要用于初级开发人员执行的较简单的任务，这种情况也与较低的质量有关
- 大多数经验研究（上述18个中的14个）都存在一个常见缺陷，通常被认为是得出普遍结论的障碍：研究是针对研究生或本科生的“便利样本”，而不是针对现实工作条件下的专业人员
点击看敏捷名词地铁线路全图