结对编程

《人月神话》的作者Fred Brooks声称他在20世纪50年代的时候与同样是研究生Bill Wright一同编程过。他说：“我们一起创造了1500行没有缺陷的代码。它第一次就可以正确运行。”

到了20世纪80年代早期，Larry Constantine参观了P.J. Plaugher的软件公司。Larry发现了一个房间里每一个电脑前都有两个程序员在工作。他把这个称作“动态二重奏”。而这些程序员产出的代码是没有缺陷的。他说：“两个程序员串联在一起并不是累赘，而是一个最直接的提升效率和质量的方式”

后来在1998年，在克莱斯勒实践的极限编程中，结对编程是它的核心实践之一。

结对编程可以在不影响交付事件的前提下提高软件质量。这是反直觉的，但是两个人在一台计算机上工作与两个人单独工作将产出一样多的功能，并且前者的质量还会更高。伴随着质量的提高，可以给项目后期提供更多的节省。

通常情况下人们倾向于关注总体思路而不是具体细节。而结对可以让程序员更快的发现错误。没有任何两个程序员会以相同的方式看待代码。这通过分配特定角色—“驾驶员”和“领航员”来辅助。

将两个角色拆分可以给代码带来两种不同的视角。“驾驶者”的想法应该更具有战术性，聚焦于细节，聚焦于当前正在写的代码；而“领航员”会思考更多具有战略层面的内容，他们会在脑海中绘制更大的蓝图。

在结对编程中，开发人员需要讨论代码并提出问题。提出正确的问题可以挑战假设并引发新的观点。因此结对编程不仅仅是代码，也是积极主动的学习。表达自己的想法有助于帮助我们达到正确的理解和共识。

遇到复杂问题时
结对编程可以提高开发人员在处理概念上复杂的任务时的工作表现，因为这些任务的细节可能会非常之多，以至于单个开发人员的处理速度会显著下降并且犯错误的可能性会更高。而有另一个开发人员在旁边会减少这些问题的发生。
 
当需要加速重要的任务时（例如：为了达成冲刺目标）
为了尽快达成冲刺目标，当冲刺待办事项列表的任务已经为空，但是还有和冲刺目标相关的任务正在进行的时候，程序员需要结对一同处理这些任务，而不是去产品待办事项列表中去领取新的任务进来。这可以让两个开发人员的全部开发能力能够承担冲刺中最关键的工作。
 
需要培训时
结对编程对于新手上手工作和流程非常有效。一个有经验的开发人员可以和一个新人结对来快速的、有效的分享项目上的信息和常用的研发技巧。结对还有助于新人保持参与度并确保他们自己编写代码，而不是将工作留给有经验的开发人员。

遇到瓶颈时
当可用的开发人员多于任务数量时（例如，任务有依赖关系或者有阻碍的任务时），配对可以让多个开发人员的全部力量集中在需要处理的任务上。

还有其他的场景欢迎你的补充...

使用结对编程的最佳方式就是并排坐在显示器前，经常互换键盘和鼠标。两位程序员都专注于正在编写的代码。

而“领航员”是观察的角色。当“驾驶员”在敲代码的时候，“领航员”会随时随地的审查代码、提出建议并且分享他的想法。同时，“领航员”应该关注更大的问题、缺陷漏洞并且记录下潜在的下一步或者障碍。

在审查的过程中，“观察员”同时需要考虑工作的战略性方向，提出改进的意见以及应对将来可能要解决的问题。这样做为了让“驾驶者”将所有的注意力集中在完成当前任务的“战术”方面.

一个常见的流程如下：

• 团队可以从一个定义合理且清晰的任务开始
  * 一次设立一个小目标并达成一致。这可以通过单元测试，提交备注（commit message）或者写到便签纸上来进行定义。

• 经常性的通过切换键盘使用权和角色。这份共享的积极参与可以让能量提升，并且让大家更好地学习和理解事物。

• 作为“领航员”，需要避免使用“战术性”思维，也就是不要关注于细节。将细节留给“驾驶员”。“领航员”的工作是退后一步，给你的同伴补充更多的“战术性”思维。把下一步要做的内容、潜在的障碍和写在便签纸上的想法先放一放，等小目标完成了之后再去沟通。这么做是为了不打断“驾驶者”的思路。

1. https://en.wikipedia.org/wiki/Pair_programming

2. http://www.extremeprogramming.org/rules/pair.html

3. https://martinfowler.com/articles/on-pair-programming.html#Styles

4. https://hinchman-amanda.medium.com/debunking-the-myths-of-pair-programming-7db756326b4c

结对修改线上问题

2012年左右麦哲思科技在为某客户咨询时实践了该做法。

问题： 系统上线后，紧急修改时往往修改了一个Bug，又引入了新的Bug，导致进一步的生产事故。

解决方案： 系统上线后，遇到了修改任务，无论是需求变更还是缺陷修复，此时要安排两位开发人员守着一台电脑，互相协商着修改代码，两人达成一致后，才可以动手修改代码。