结对编程踩坑指南

最近，我开始重新审视这些融入日常的工程实践方式，去尝试找出实际与理论的差距，分析差距成因，基于分析结果，尝试找出可以逐步弥补差距的实践方式，从而让日常软件交付工作变得更加“顺滑”。,本文作为“沉思录”的第一篇，将列举实际交付项目中，在结对编程时遇到的几个实际问题，并针对具体问题给出一些尝试过的解决方式。,,注意：以下话题不在本文的讨论范围中，并且默认读者已经具备下列问题相关的知识：,Dev轮换表大概是这个样子（每个周期内团队采用同一编号的配对组合）：,,基于以上的上下文，我们遇到了以下实际问题：,Switch Pair 时，需要交接的内容过多时，可能会漏掉一些细节信息。为了补充遗漏，会陷入更多、更深的讨论。,张三和薛霸经过了一周的结对编程，手头的一张复杂 User Story （无法进一步拆分）没有完成，薛霸被留在了当前工作上，准备和阿乐开始工作。,可是，在薛霸向阿乐介绍当前的工作进度时，无法清楚地给阿乐说明之前所写代码与 User Stroy 的对应关系和一些必要的上下文。,于是这对 Pair 不得不将张三重新拉回来，进行上下文交接，三人讨论时间较长，并且会将之前已经讨论过的问题重新讨论，降低了工作效率。,后来，张三，薛霸，阿乐对这次效率不尽人意的 Switch Pair 进行了回顾，尝试利用问答的形式进行分析：,另外，薛霸无法解答的问题，基本都是张三在薛霸请假期间完成的。,于是，大家总结出了如下可以实行的行动：,其实上述的问题是有一定的内在逻辑联系的，可以通过下面的具体场景来进行复现。,肖兰和阿发在结对编程过程中，肖兰使用自己的笔记本电脑外接显示器，并通过笔记本的键盘和触控板完成操作，阿发则可以通过外接的显示器看到肖兰的操作。,起初，两人会对着外接显示器进行一些讨论。,但在深入调查代码时和一些代码编写时，肖兰开始对着自己的笔记本屏幕进行操作，随着肖兰逐渐地集中精力，讨论和解说停止了。,在连续几次的进入某个类查看细节代码，再切换到另外几个文件中查看配置文件后，肖兰写了几行代码试了试。,如此反复了几次后，阿发已经不清楚肖兰所进行操作的目的了，但他看着肖兰投入的样子，欲言又止，不忍心打断她的操作。,于是阿发又努力了3分钟尝试跟上肖兰的思路，可是猜透一个人的心思何其难也，阿发最终无奈放弃，于是默默转向自己的电脑（手机），去看看邮件（朋友圈），等待肖兰等下有了结果再同步给他。,可是，肖兰在完成的调查整个过程中获得的信息，却不一定都能同步给阿发，阿发也就无法掌握当前工作的全貌了。,至此，Pair 终成 Solo…,(1) 硬件设施准备不充分。,肖兰掌控了所有的操作，阿发更多的时候都处于一种“被动”状态，结对编程的参与感不高，特别是当肖兰“全情投入”后，阿发的参与感几乎被全部“剥夺”。,说明：在了解 “如何进行结对编程” 的部分有说明过，结对编程的两人在硬件准备上，应该尽量平等，至少两人都有可以各自操作的键盘。,(2) 没有分配、交换角色的活动。,结对编程是两个人共同合作的活动，那么两人中每个个体在活动中的体验感就直接影响这项活动的效果。,在上述例子中，肖兰一开始就掌握了”操作权”，到了代码调查阶段时，肖兰又直接“抢夺”了思维的“导向权”，随着自己的想法去调查、尝试。,导致阿发在这次结对编程中的参与度极低，体验感也极差，并最终转向独自工作。,说明：为了保证结对两人的参与度，结对编程存在多种不同的实践方式（Navigator-Driver 模式、乒乓模式、键盘 + 鼠标模式），但无论采用哪种方式，两人都应在实践一段时间后，交换角色，从而使每人都有机会从不同的视角分析、解决问题。,(3) 缺少有效沟通。,结对编程与其说是编程方式，不如说更多是一种“社交”活动。那么，在整个过程中，结对两人需要进行大量，高强度的沟通交流。,在上述场景中，一方面，当肖兰要开始进行一些深入调查时，没有说明意图，从而使阿发开始产生迷茫。,另一方面，当阿发努力尝试后，依然认为自己跟不上肖兰的操作时，没有与肖兰说明情况，从而使两人的“信息鸿沟”进一步被扩大。,针对上述问题，可以：,Pair 过程会产生大量的沟通交流，频繁的 Switch Pair 会使这种交流的成本扩大，那么如何从这种高频的 Switch Pair 活动中获得更高的个人收益呢？,团队最近在尝试提高 Switch Pair 的频率，从之前的每两周提升到现在的每周一次，之后视情况仍有提升的可能。,而这给阿花造成了困扰，因为几乎每次结对编程，阿花都和搭档会讨论很多问题，而几乎每次 Switch Pair，阿花都需要花费不少时间将这些讨论的结果和新的搭档解释。,阿花认为这降低了工作的效率，并且自己也没从中获得额外的收益，那为什么还要提升 Switch Pair 的频率呢？,其实，阿花遇到的工作效率降低问题，可以利用问题1中提到的实践进行尝试。,另外，随着频率的提升，需要传输的信息量也会下降，再加上合理的拆卡，工作效率问题的影响应该微乎其微。,可是，阿花提出的另一个问题，“如何从高频 Switch Pair 中获得更高的个人收益问题？” 这却不是一个单靠结对编程技能就能解答的问题。,先抛开 Switch Pair 的初始目标（信息流动）不谈，因为这其实是对于团队的收益（一定程度上降低团队人员变化带来的风险）。 ,那么，对个人而言，要想从 Switch Pair 中受益，就需要从敏捷软件工程实践的相关理论和目的出发，如果能结合“快速反馈，识别变化”，那得出的结论就不难了：,想要在高频 Switch Pair 的实践中最大化个人利益，那么就需要充分利用此时的机会和资源，即不同的搭档的视角，再结合 Feedback 机制，就可以很容易构建个人有目的，有针对性的提升计划。,那么就从每次 Switch Pair 前，向上一个搭档收集这段时间合作的反馈开始吧。,注意：Switch Pair 的频率不必一味求高，只要能够确保工作所需的关键信息在团队内充分流动即可。,结对编程也只是程序员工作中会用到的一项技能而已，那么只要是技能，通过时间的堆积，去磨炼，去思考，就会有所提升。,稳扎稳打，时间会给予最棒的回馈！