前段时间，项目三个开发者主要忙于确定一些具体技术，工作效率很低，两个同事一个负责服务器进程间通信模块的制作，一个负责数据库的线程池访问。这些知识他们都有，只是不够熟练，这些地方都是很容易耽误时间的，一位同事调整一个线程池，三天一下就投进去了，有时就是漫无目的的查资料，我当时看着干着急。

那天晚上回家，突然想起来，唉，干脆试试结对开发怎么样，连夜总结了一下问题和要点，于是连续几天的XP就开始了，起得了一些好的效果。回顾一下自己一直以来认同XP却异或结对开发，主要有几个阶段：

好奇阶段：早在一年前的事情了，一样和大家好奇的查阅资料，抽时间的认真尝试了几回，自己就先疑惑起来，同时通过查阅资料我也找到了很多负面报道，比如国外已经跳出人来说结对开发有问题，又比如中科院有家研究所，花了半年测试XP，得出结对开发不行的结论，七八条专家理由，自已也怀疑了。

排斥阶段：觉得结对开发有打压开发者的效果，首先是一个人写一个人看，写的那个人再高明难免犯错看的人抓住口实后和你争论，你一边写代码一边想问题，自然言语落下风，轻者散失声誉，重者没了自信。“平等、妥协”难以单方面强求，所以当时认为开发者应该适当保持距离的同时做一定的重复劳动满足自我价值实现。觉得挨得那么近结对开发，似乎对个人成就感是种磨灭，因为剥夺了代码的个人所有权，大家觉得价值得不到体现了，所以当时 的心态比较极端。

重新认识：

第一点：前提

首先得双方都能做到平等和妥协，所以最好双方之前都有合作经验，彼此了解对方的水平，当然在水平差距不太大的情况下，进行XP。当你也犯了错，我也犯了错，大家就公平了，注意力容易集中在问题上面，不会有太多的抬杠行为，上午你写，下午我写，无意识的保持着每分钟交流一次。

第二点：效果

后来发现“提高效率，避免出错”的同时，双方能在初期对项目关键部分形成共识，关键部分都经历了开发了就必然知道以后相关部的开发该注意什么，两个人决定设计，规避了未来可能出现的较大意见分歧，提高了开发效率和质量的附带效果是开发者水平都得到了提高。

独立开发时，碰到问题容易苦思冥想，代码写半小时删半小时，这是思维死循环了；或者就漫无目的的查找资料，找不到就容易变成上网聊天，这是思维出现异常了。结对开发的监督效果的确能很好的规避这些现象，经常两三个小时不理IM和邮件－－独立开发效率小于结对开发效率同时碰到问题的时候可以迅速解决，通过极兴讨论能在短时间把方案订下来了。胜过三五个人的中型会议，因为两个人都达成共识的方案已经很不错了－－“两人订设计” vs“设计讨论”

第三点：应用

不建议将结对开发贯穿项目始终，好刀要用在关键的地方。我自己以为关系到某些公共模块，接口等最好采取结对的方式。也就是说项目的关键部位，前后有承接的地方，需要再别人工作基础上二次开发或者开发后别人会再自己基础上二次开发的模块，来点XP，是一件很快乐的事情：

1. 规避关键接口的潜在错误，在关键接口上就形成共识，免得以后设计意见不合。
2. 大家都经历了开发过程，必然懂得在使用这些模块和接口的时候需要注意什么，有什么限制。
3. 关于代码风格，没必要强求，我想学公司一位老同事，和谁配合就按谁的风格写代码。

比如本来我写封包解包，你写加密算法，那么我们就应该结对。本来我写引擎层，你写应用层，那么我们之间的接口编写，最好结对，否则以后分歧大了不说错误也多。比如我写绘图，你写GUI，那么我们应该结对开发。但是如果我写绘图，你写HTTP下载，咱俩最好就分开干了。因为我可能对HTTP不感兴趣。

按钮和滚动条是亲戚，但是按钮和精灵就属于远亲了，所以说结对开发的两位程序员，对于开发的内容，应该和其他的工作多少沾亲带故。上面是前星期XP的一些心得，鉴于二期项目规模都普遍增大了，推荐各个项目组可以使用一下，值得再次尝试一回，当然，附带要解决的就是开发时候的划分问题了。

PS: 说太多效果和分析了，实际用的时候，更多的时候是自己觉得某模块开发很关键，然后找个同学搬把椅子往别人边上一坐，大家一边 “Enjoy Losing Face” 一边顺其自然的就开始了。