关于结对编程的一些问题

前言

　　最近由于公司项目，有机会尝试结对编程（pair programming），实践了3个月，也有了自己的一些心得体会，本文以Martin.Fowler的《结对编程模糊概念》来展开叙述。

1. 实践敏捷过程一定要“结对”吗？

This is utterly false. 'Agile' is a very broad term defined only in terms of values and principles, most notably in the Manifesto for Agile Software Development.

　　正如Martin所言，敏捷宣言并未提及结对编程是必须的，敏捷只是一种思想，结对编程仅仅是实践中的一个非必须的组成部分。即使XP被强烈推崇，也不代表结对编程适用于任何公司或者项目。

　　就个人体会而言，目前项目组内会有Switch pair的过程，我的理解是pair的过程更多的注重团队成员间的知识分享以及相互之间的沟通、检查代码等，带来代码质量上以及、知识流动上的优势，要因项目或成员而异。

2. 极限编程迫使你结对吗？

I would say that pair-programming is usual for XP teams. I wouldn't say that a team that doesn't do pair-programming thus cannot call itself an XP team. I should also point out that to most XPers I know the question of whether a team is XP or not is uninteresting; the real issue is whether a team is effective.

　  Martin所赞成的是团队开发效率或者说结对编程是否适合团队。

3. 如果我不喜欢结对编程，我就没必要去实践它？

　　Make sure you have someone who really knows how coach you, so you can be sure you're evaluating the real thing.

　　针对这一点，我觉得我还是有切身体会的，真的很同意Martin的观点。如果你经历过一个不好的pair体验，你就要回忆并且追问下，是否你找到了“合适”的parter来一起pair，而不是那种话不投机半句多、我写你看着，这种同伴。

　　往往pair的过程中两个人的水平会有所差距，这个问题要从下面几个角度考虑：

　　1. 如果你是low的一方，你需要一个什么样的同伴，你希望同伴是如何回答你的各种疑问，如何正确提出问题，怎么样提问能让对方乐意回答你的问题，如何让pair的对象不觉得你很low，如何找一个有耐心的同伴交流，而不是讽刺挖苦？

　　我觉得这个问题是一个很难平衡的问题，可能在大多数的情况下，要虚心请教、加速学习，努力跟上设计思路，并且提出自己的观点，让对方觉得你不是一个“无用之人”，诚然，最开始总是最难熬的，“命运”是公平的，如果有一个更Nice的同伴，可能你的学习努力程度就会稍若些；如果你的同伴很自傲，说话略带讽刺，这可能会激励你更快的学习。尽可能找一个适合自己的parter才是开始pair的关键。

　　2. 如果你是High的一方，你是否思考过，low的一方的感受，你应该如何帮助low的一方提高能力水平，如何能在你累的时候，low能替你完成你的思路？

　　俗话说的好，授人以鱼，不如受人以之渔。可能做为能力稍强的一方如何引导同伴去融入代码，融入设计思维，而不是我自己也行，不需要知识分享也能完成，或者你水平太low，问题太多，我不需要你这样的累赘。其实pair的一方面是分享知识的过程，如果简单简单理解为完成项目任务，则会错失很多提升自己的机会，如果是这样你要考虑你是否适合pair。

　　3. 两个人水平相当，有时，大家思路一致，互相抢键盘来完成代码，而有时，甚至两个人为了一个命名争的面红耳赤？

　　这是一个相当普遍的情景，而往往后者出现的次数更多。这里有一些对代码理解上的冲突，有一些实践上的规范，还有一些人内心的虚荣（不接受别人对自己的否定，即使是错误的也要坚持），这时首先要思考下自己坚持的东西是否是正确的，自己是否能承认不足（不完美），其次可以找“第三方”来决断矛盾。从实践的角度出发，如果事事都要第三方决断的话，极有可能你们两个之间的pair关系早以不存在，我觉得处理pair矛盾的过程是两个人互相理解、互相包容的过程，一味最求自我，这样只能单打独斗。

　　当然，如果两个人，“化学”作用比较好的话，会非常happy ：）

4. 结对编程对降低工作效率？

that would be true if the hardest part of programming was typing

　　一些结对编程的支持者认为，结对编程的效率会更高，他们（她们）可以持续讨论、互相review代码，这样可以保证高质量的代码。而更多时候“工作效率”是无法衡量的，特别是在解决很困难的问题时，一个人可能会陷于某种“极明显”的错误中，而不得要领，这个时候如果两个能保持独立思考的人往往效率更高。

　　在我的pair中，有时我的任务是当代码开发遇到困难时梳理代码的作用，从新overview代码思路，解决困难，一个人的能力是有限的，而两个互补的人会产生1+1>2的效果。

5. 结对编程只适用于解决困难代码场合？

Except this: writing boring rote code is a smell. If I'm writing boring repetitive code it's usually a sign that I've missed an important abstraction, one that will drastically reduce the amount of rote code to write. Pairing will help you find that abstraction.

　　简单并不代表没有重构机会或者说没有机会写出更完美的代码。

　　在我的pair过程中，partner总是在提醒我要重构，抽取代码段，也许这就是一种外在的推力，来开发更优质的代码。结对编程是提成代码能力的过程，你如何知道你写的代码是最最优美的呢？看看codewars上大牛们代码，你自己都会觉得汗颜。