敏捷开发实践之结对编程

　　结队编程是敏捷开发实践中的一种，这里略作简介，Kent Beck是结对编程定义者，他的定义大致可以理解为两个人共享一套开发设备，一个叫Driver 一个叫Observer, 说白了就是一个动手写一个在旁边看着，如果遇到问题两个人一起讨论，避免思路封锁。

　　对于结对编程，很多人各持己见，有的开发人员只想做一个安静的美男子，崇尚1+1>2的理论，不无道理，有的开发认为两个人更能打开思路相互补充。OK， 以下内容想通过结队编程在实践过程中优缺点以及实践过程中存在的问题进行分析。肯定会有总结不全或者不准确的地方，欢迎大家来辩。

1，知识传播

　　每个模块最好是有两到三个人熟悉，在敏捷团队中最好是所有的人员对模块都有一定的了解，这样，结对编程就可以规避在相应开发人员请假或者离职带来的工作交接的问题。结对编程是一种将知识传播下去的方式，有人说我有文档啊，对于绝大多数的项目而言，文档的维护往往慢于Coding，而且文档的描述往往又打不到会让读者百分百理解的程度，对于这种情况我认为会影响Transfer， 因此熟悉此处逻辑的老人可以和新人一起来编写一块逻辑，通过去修改BUG，写代码，老人带着新人将这块一起做下来，包括新成员进来的时候可以通过此种方式将知识传播下去。

　　问题来了，那是不是高级开发就完全将陷入不停的被中流砥柱型和潜力型开发人员要求指导中了呢？如果我是老板，绝对No，我想要我的高级人才发挥更多光热，是金子总是要把它花光的么！

　　Solution：高级开发人员可以有同一个问题不回答两遍的权利，，首先高级开发人员可以要求被Transfer的开发在了解了该模块后去整理相应文档。其次，已经接受Transfer的人员应该承担起该模块以后的知识传播工作，就像接力游戏一样。

　　这样会不会使潜力开发人员产生对学习产生依赖性而缺乏独立思考的能力呢。

　　Solution：老鸟的作用不是告诉小鸟应该怎么做，而是引导小鸟应该怎么做，老鹰教小鹰飞的时候不也是直接看膀子羽毛长得差不多了就一脚踹下悬崖么。对于小鸟如果是笨鸟，那就先飞， 如果是特殊品种，那可能它跑得快，如果是蠢鸟，个人认为没必要浪费粮食。

　　老带新有代沟，新手紧张，发挥不出来，老人烦躁，彼此不和谐怎么办

　　Solution：相互理解吧，乔丹也曾训出来了夸梅布朗这个水货状元。

2，协同合作

　　两个人一起看，总比一个人看发现问题的机会要多一些，协作开发可能会带来更加快速的反馈，更好的设计，更高的效率，更少的问题。

　　那问题又来了，挖掘机技术尚且要论哪家强呢，那么，两个开发人员总会遇到各自认为各自的设计好，而争执不下。

　　Solution：如果是设计思路上的冲突，不影响整体功能实现仅仅是思维方式的不统一，有一方最好尽快做出让步，好，那你来Coding你的思路（总有些理论派，对付理论派我一直用这招，你能写出来，OK，学习了新的思路，如果你不行，请让开，让我来）。如果是真的僵持不下，OK，也不要浪费过多时间，找更高级的开发来定方案。

　　两个人一起工作出现注意力不集中，聊起工作无关话题怎么办。

　　Solution：两个人一起效率反而因为扯淡效率大幅降低，那么说这两个人不适合在一起做结对编程，这也是我想强调的不需要硬性死板的执行结对编程。老板，你看着办。

　　有人单兵主义怎么办？

　　Solution：不需要硬性死板的执行结对编程， 不是项目中的每个人都需要去结对编程，结对编程的队友不需要Scrum Master去安排，根据自己需要去自行寻找结对。

　　程序媛怎么办？

　　Solution：Come on，程序媛不仅仅是结对编程，人家是结队编程。

3，更好的Code Review

　　结对能保证信息及时透明的得到反馈，这样就能很大程度的避免细节遗漏的风险，同时能减少了后期统一Code Review的工作量。

 

以上是对结对编程优缺点的一个总结。对于敏捷项目中，我感觉可能存在的问题：

　　1，敏捷开发中Story 需不需要在Task中体现出来结对编程人员的不同职责，比我是Driver，story分给我，另一个是Observer，在Story上添加Task表明我对这个Story的开发工作中做Support的工作。我的问题，希望得到Solution。

　　2，是不是敏捷就一定要整个开发周期都结对，结对是不是每个Pair就一成不变了。个人认为两个问题都是No，不需要全程的结对，只需要在前期设计，或者开发者感觉考虑会不周全的时候找相应的结对者做相应的Support。结对的对象可以随着做的Story功能的不同，选择相应的结对对象。

　　3，项目维护需要结对不，对于老带新，或者BUG处理的Solution讨论，以及重构的建议，都是可以结对来完成，而且效果可能会更好。

　　4，怎么权衡结对编程带来的两人干一个活而导致开发效率降低。不做全程硬性的结对编程要求，对有需求的Story或者Bug做结对编程，不会影响太多效率反而会规避考虑不周的风险。

　　5，Driver和Observer的角色是一成不变的么？不是，可以随时切换角色。

暂时能总结的这么多，希望能有人对这个感兴趣，或者项目中在使用结对编程，能给我更多这方面的指导反馈，包括经验，或者存在的问题等等，来着不拒！