结对编程的十个场景( 三 ) _编程

场景七：按自己的节奏走

...A啃哧啃哧编码...无讲解思路...
B：你在不同的文件之间跳来跳去的，是在干嘛?
A：我们要修改测试环境的配置。
...A继续啃哧啃哧的编码...无讲解思路...
B：这又是在干嘛?我们不是要先去查看一下XX方法，然后看看能不能拿到我们想要的结果吗?
A：嗯，对。
...A继续啃哧啃哧的编码...无思路讲解......
B很懵，不知道A的思路是什么，也不知道A是按怎样的顺序处理问题...

共同贡献，团队拥有。结对编程实践下，开发软件功能是两个人的事情，Senior 不要大包大揽独自完成，只按照自己的节奏，而在没有讲解思路的情况下忽略了peer是否能跟上。Junior 也要为卡负责，不懂就问，进度太快就提出来，不要独自承受压力。
高频率的沟通。结对编程实践下，做卡是两个人的事情，这需要高频率的沟通以确保结对的两个人都清楚理解该卡的上下文、解决思路以及当前正在做的事情是什么。在讲解实现思路的时候，要细致到每一步(参考美食主播讲解菜谱的过程)，毕竟peer的思路可能完全不同。
场景八：表现出被针对

项目组每周交换一次结对伙伴，刚交换结对伙伴后，A新加入该功能的开发。
...B给A同步正在实现的功能的上下文...
A：停，打断一下，这个方法为什么要先过滤再遍历数组呢?
B：因为...
...B反应激烈，声音拔高...
...A感觉peer竖起了盾牌...

当有新成员加入卡时，同步卡的上下文。需要同步卡的范围(scope)，当前进度，是否有阻塞(blocker)等。在同步的过程中，讲解者能再次梳理卡的内容，有可能发掘之前忽略的小细节，接听者通过提问等也有可能提出不合理的地方，为卡的质量增砖添瓦。
结对编程时，大家的建议和争议都是对事不对人的。在结对编程的过程中，意见并不总是一致的。当发生争议时，作为被挑战的一方，应该客观地倾听别人的意见。如果之前没有充分考虑，要勇于承认并接受别人的意见，而不是认为别人在攻击自己，急于辩解并不断反驳。即使别人提出的建议很有道理，也不要因维护自己的虚荣心而拒绝采纳。可能团队成员缺乏足够的上下文信息，而挑战只是发出需要同步上下文的信号。要相信别人提出建议是为了让我们的代码更加可靠或者需要更多的上下文信息来理解我们正在做的事情。作为挑战的一方，我们需要注意用词和语气。我们的目的是提出想法，保证代码质量，而不是通过发表建议来展示自己的能力和不凡。我们应该保持客观的态度，使用平和的语气。如果感到对方比较排斥，要及时澄清情况。
场景九：因为私人事情离开

...A正在思考着解决方案，边思考边讲述着自己的思路...
...B突然离开...
...A猜测B是因为私人事情离开，感受很不好...

团队信任很重要。首先，我们不能主观评价peer离开的原因，也不能评价事件的重要性。其次，我们需要具备基本的职业素养，尽可能专注于结对编程，不在未沟通的情况下无故离开，除非情况紧急。
在每天开始结对编程前，要检查当天的日程并同步可结对的时间段。提前同步可结对时间可以帮助规划卡的工作，例如在两个人都能结对的时候确定解决方案，或先实现一些复杂逻辑。这样，在一个人离开后，另一个人可以无障碍地继续编码，避免遗留下来的人无法确定解决方案或无从下手处理复杂逻辑。
如果需要在结对编程过程中离开，尽量使事情透明。结对编程需要两个人频繁互动，因此考虑到peer的感受可以建立良好的关系，有利于结对编程的顺利进行。如果我们正在专注于结对编程，因为突发情况需要离开，尽量告知peer，方便的话讲清离开的原因及预计返回时间，这是对他人的一种尊重。
相信 peer 是专注于结对编程的。在专注于结对编程的同时，我们也要相信 peer 也是专注于结对编程的。如果peer在没有通知的情况下离开，我们应该相信是因为情况紧急而没有来得及通知，而不是因为工作态度有问题。
离开的人回来后，留下的人应该主动同步这期间的代码改动等。代码改动等同步可以让peer了解卡的最新状态，方便在下一步的编码中提出有效的建议。如果留下的人没有主动同步，离开的人也要主动询问改动内容，以便及时将注意力集中到当前的任务上。