结对编程实践心得

结对编程（英语：Pair programming）是一种敏捷软件开发的方法，两个程序员在一个计算机上共同工作。一个人输入代码，而另一个人审查他输入的每一行代码。输入代码的人称作驾驶员，审查代码的人称作观察员（或导航员）。两个程序员经常互换角色。——源自结对编程 - 百度百科

实践背景

大部门为了研发提效，提出了一揽子的工作计划，最近要落地的就是结对编程，对部门内所有前后端同学都适用。

这种方式之前我一直是听说过，经历的公司都没有具体的实践，现在就来实践了。

结对编程的好处

1、项目视角，质量左移

从项目视角，提高了产品质量。两个人互相check。通常个人的想法难免有局限性，自己看自己写的代码总是觉得怎么都对。还有通过结对，代码至少有一个程序员进行了审查，这样可以让设计、测试和编码更加友好，减少了缺陷，从而提高了产品质量。

2、个人视角，个人能力提升

review的时候可以相互学习，知识点盲区互补，还有逻辑思维方式的互相学习

3、团队视角，人员互相buckup，成员之间关系更融洽

人员互相备份，成员之间增加沟通与信任

结对方式

1、团队内两两结对

人员固定，后面不定期轮换

2、固定时间固定频率，做以下4件事情：

①、故事描述
②、设计思路
③、CodeReview
④、测试问题回顾

3、以上执行过程中，产生的所有问题，记录在固定位置【结对文档记录】

结对有记录，有总结

时间和频次

1、具体时间：

我们现在实行的是敏捷开发，具体时间为每个冲刺的【第一周的周二—最后一周的周四】

2、频次：

每天下午5:00

其它与注意事项

1、整个过程建议时间：15-30分钟
2、整个结对过程中大家秉持着相互尊重、相互学习的心态
3、结对的讨论必须围绕着故事本身，切勿发散讨论

---

如上是领导宣贯时的计划与愿景，可以看出，我们并没有突出驾驶员和领航员的概念，或者可以理解为每个研发都为驾驶员+领航员，或者再简单的理解一下，我们其实算是两两code review + 问题回顾

目前我们执行了近一个月了，简单的做一下实践回顾

我们的具体实践

• 落地执行
  我们项目的后端同学是两两结对，由于我们前端小组是3个人，所以我们是三个人结对编程

• 具体实施
  我们每周下午5点，在某个同事的电脑旁边，逐个展示自己今天做的故事、代码，以及自己遇到的一些问题+思考，然后其余的两个人来review

看到其他小组，也差不多是这个形式进行的结对

结对文档记录

结对人	结对时间	冲刺故事	问题类型	问题描述	优化措施/待跟进事项
张三、李四	2022.07.04	https://jira.net/123	需求/设计/编码/规范	Promise.reject 处理逻辑冗余	优化Promise.reject逻辑处理
张三、李四	2022.07.05	https://jira.net/123	设计	通用弹窗组件参数逻辑不清，接口请求混乱	将接口请求从通过弹窗接口中摘出，组件接收Promise请求作为参数，具体接口请求由外层的业务组件控制
张三、李四	2022.07.06	https://jira.net/123	编码	未发现问题	无
……

遇到的一些问题或特殊情况

• 会耽误一些coding的时间
  毕竟每天固定的时间去做review，而且我们是三个人，通常我们都会在半个小时左右完成结对，这样的话，就少了半个小时的coding，以及时间上的思维打断

• 复杂模块的backup，短时间内难以做到
  有些很复杂的模块，现在在做修修补补的工作，这样的话，紧靠每天的结对编程，去了解整体模块的情况，是不够的

• 当天没review出问题来咋办？
  那也不需要处理，我们每天写代码，有的时候写的少，或者逻辑很清晰，这样的话就无需review出问题，不过结对记录照样记录，如上面表格的最后一行

心得收货

之前我们也做过几次大部门内部的code review，由于参与的人比较多，会议比较长，而且准备讲的同学，需要事先准备好内容

现在的这种结对编程的方式，是把code review日常化、碎片化了，不需要准备抽出大的整块时间来专门去做code review

现在对我们最大的收获，是技术点+编程思维的碰撞，不一定是谁说服了谁，我们借此机会更多了交流了技术

事情重在坚持，结对编程是件长期坚持下去才能见成果的事情，等我们在具体实践中坚持一段时间再来回顾，收获会更多一些