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

B：......
全程无回应(我是谁?我在哪?我在做什么?) 。
是peer没听到吗?是我声音太小了吗?是peer太专注没心思搭理我吗?
及时回应。沟通需要至少两个人的参与才能正常进行，就像讨论需要有来有往才是有效的。如果A讲了话却没收到来自B的反馈，有三种可能情况：1. B没听到。2.B听到了但是没有回答。3.B听到并回答了，但是回答的方式没有被A理解到。对A来说，若不确定B究竟听到没，可以加大音量重复所讲的内容。如果还是没有回答的话，可以问A是否有听到。为了让结对编程更顺畅，建议我们听到他人说话后，及时给出回应，以示意我们听到了。这个回应可以是语言、动作甚至眼神，所以如果我们正在思考，不能被打断或不方便给出回应时，可以选择动作等非语言的形式给出示意。
及时反馈。如果我们讲话后没收到对方的回应，要及时反馈。如果该现象发生了多次，我们可以建立一次反馈会议，跟peer针对该问题进行正式的沟通，分析原因，明确及时回应的必要，商讨对应的解决方法。
场景五：你怎么都不会

A：我们用 reducer 方法来对数组进行处理吧!
B：这数组遍历的 reducer 该怎么写呀?
A：你这都不会!
...A讲解 reducer 的使用方法...balabala… 一顿解释...
B：测试要mock外部依赖了
...B开始编码，尝试了两种mock方法，都没有达到预期效果...
A：这块结合实际情况，要这样mock
...A讲解该处mock外部依赖的方法...balabala…
B：对的，这样写测试结果符合预期。
A：你怎么这也不会!这很简单呀。

注意沟通技巧、用词和语气。我们在沟通的过程中，一定要以平和的心态，不带偏见的、尽可能客观地表达我们的意见。有些用词对你来说可能不带任何含义，但是在他人来说就不一定了，所以斟酌用词也是必要的，尽量使用常见的中性词。当然我们也没必要对每一个用词语气都反复斟酌，否则会过犹不及影响正常的沟通，毕竟都是项目的成员，说话的人和听话的人的感受都值得被关注、被考虑。重要的是在发生不愉快的时候，我们都要有去解决的意识，能及时沟通讲清前因后果及双方的理解，解除不愉快。
正确处理peer的能力低于预期的情况。peer 的打字速度好慢呀，都不用快捷键，方法定位也不会，这么菜吗？针对这些情况，要明确：闻道有先后，术业有专攻。如果 peer 某方面表现很不好的时候，不要随意批判轻视对方，要知道 peer 在这方面比较 junior，但是在其他方面，我们也可能会是初学者，所以我们要换位考虑对方的感受，同时还要意识到发展他人的机会来了。针对具体问题也要具体分析，通过沟通等手段寻找问题根因。是因为 peer 刚接触该技术栈呢？还是 peer 最近压力比较大，没休息好，所以有时会反应比较慢呢？亦或是文件搜索这块正好是 peer 的短板呢？不管是客观原因还是主观原因，都要结合实际情况，多方沟通探讨可行的解决方法并进行追踪。
场景六：建议被忽略

针对一个问题
A：...balabala…(讲完自己的思路)
B：...balabala…(提出一种新思路)
A：...coding…(按自己的思路开始编码)
B：...%#@$%&
...…B很懵，貌似自己的方案更合适吧?怎么就开始编码了呢?...

关注并重视自己和peer的感受。结对编程实践下，一天的大部分时间我们都在和peer进行协作，如果心有隔阂，那么结对工作很难顺利进行下去，所以在内心感到不适的时候，我们要重视自己的感受，及时反馈给对方并进行沟通，针对具体情况协商解决。
针对不同解决方案要沟通达成一致再编码。如果结对的两个人针对同一个问题分别提出了几个方案，这时要针对这些方案进行沟通，确保双方都理解了这些方案，并对方案的优缺点、工作量等有一定的理解，双方都赞同采用某方案后，再开始编码，避免实现到一半再出现分歧。这个过程中，可以对每个方案都从头到尾梳理一下，能提前识别一些存在问题的方案并过滤掉。如果针对要采用的方案无法达成一致，可以考虑暂时搁置争论，寻找支持论点的证据后，再开始新一轮的相互说服，也可以考虑引入第三方，TL或在该领域经验丰富的组员都是较好的选择。
及时反馈。反馈文化是我们所提倡的，可以建立多维度的反馈会议，比如peer的某种行为让我感到不适，如果不想打断工作进度且可以接受暂时不适时，可以选择一天工作快结束的时候再进行反馈交流，总结一天的工作，识别一些做得好或值得深挖、保持的地方。