昨天，我第一次在实际开发工作中体验到了结对开发的魔力（以前也就是两个人一起研究问题而已），那确实是一种令人神怡且有效的工作方式——至少it works extremely well for me!
在下午三四个小时的开发工作中，我和我的搭档一起解决了已经困扰了我很久的几个问题，并令人激动不已的在NUnit中点绿了单元测试中所有的测试项（就这几个问题我已经拖了半个月了还没能解决）——这意味着我可以放心的开始对代码进行重构（而不是重写）了（本来一直没有信心这样做，因为到处都有红灯，而每一个红灯都牵扯到很多的问题）……体会一：结对编程消除了最影响开发人员情绪的孤独感，进而重新迸发工作激情，大大提升工作效率和质量。
其他同事都下班以后，我们简直是进入了一种turbo的开发状态——我们先是一起总结了前面开发中最不爽的几个环节，并一致认为一定有好办法能够让开发变得更简单一些——于是我的灵感突然涌出，我告诉他“我将把让我们的开发变得繁琐的这些类都删掉，用一个custom proxy搞定所有的类”！“听上去不错，可是……有这么好的事吗？”“看我的——你就帮我瞧着那些绿灯吧！”当然，我在下手之前还是像唐僧一样把改造的思路说了几遍，当我确信搭档已经明白我的意图后，我开始动手了：三下五除二，我先把一个private成员提为internal（本来它只是被自己的一系列public gateway methods访问的，现在我要让它能被custom proxy使用），并马上写出了这个custom proxy，用它替代了以前那些繁琐的method gateway和那个接口实现类，最后，我到组件工厂中把实现接口的类换为由custom proxy构造的transparent proxy——NUnit.Run! Bingo! We got it! 体会二：两个人的智慧确实大于一个人，尤其当两个人从两个方向共同考虑同一个问题的时候——当然，彼此持续、默契的交流是必不可少的。
现在回头想想，这一下午的进展真的是匪夷所思，我又一次亲身体会到了结对编程的魔力和乐趣——当然，坐在我对面的项目经理估计也体验了他工作以来强度最大、持续时间最长的人造噪音。不过我想说的不是sorry，而是thanks！谢谢你给我们这样的机会，这是在其他团队中难以想象的事情。我相信你也将亲眼看到我曾向你描述的关于结对编程的种种好处。另外，thanks to my partner canyue！和你一起工作真的很开心，我在你谨慎的约束下变得更专注也更有效率，而你也能在看我开发的时候学到更多的东西。Cool!
如果你也有类似的敏捷开发经历，不妨写在评论中与我们分享——无论是成功的经历还是失败的经历，我想都会很有参考价值。其实关于敏捷方法论（尤其是其中最著名的极限编程技术），我也有很多实践经验和想法，希望以后有时间能够在这方面也写些心得体会吧——不过当务之急，还是先把腾苦不堪的颈椎疼痛消灭掉吧！现在开车都成问题了……
打印 | 张贴于 2004-02-07 16:44:00 | Tag:Agile/XP
留言反馈
如果 pair 相差很多的话, 实施起来应该不是如此的顺手吧
1、程序员之间，水平差异悬殊，强者往往考虑到个人工作业绩的问题。通常演变成一个发呆一人干活的状态。两个较差的在一起=没法完成任何工作。
2、最初大家反对，双人编程的培训并不成功。大部分成员实际上很难做到边设计边干活。硬编码的习惯是一个痼疾。
结论：
没有自发的追求，没有入门级别的编程能力（我理解的是现在所谓程序员中，这种“级别”不超过5%)，没有足够优裕的收入，结对编程不试也罢。
嘿嘿，结对编程治的就是你这样的——不过受益的最终还是团队以及团队中的每一个人。：）
不过实施xp开始大家可能感到比较累，因为两个人一起编程，就不能常常走神偷懒了。
没错，XP没有要求在所有的工作时间内都采用结对开发的方式（照我看，结对开发确实提升了开发效率和开发质量，往往只用半天的时间就能完成原来几天的事情了，剩下更多的时间还是可以比较自由的一个人工作）。但是在实际编写代码的过程中两个人一台机器共同开发确实有几个实在的好处：首先，两个人可以形成一个自然的相互约束，你不可能抽空去回个MSN、收个邮件、看看blog啥的，就连接个电话都不好意思——想想看，虽然不是每个人都会主动承认这一点，但这在所有独立编程的开发团队中都是实际存在的普遍事实；第二，应用极限编程的时候，开发活动是在几种状态中频繁切换的——确定开发任务、编写测试代码、以最快的方法编写使得测试代码通过的实际代码、代码重构……一个人工作的时候经常会发生短时大脑短路的情形（尤其是在切换状态的时候——这和CPU切换线程环境的机理差不多），这种情形反复发生，极容易产生思维疲劳，也容易产生烦躁情绪；当两个人一起工作的时候，就好比双CPU一样，多了一个思维的物理线程，确实感觉轻松很多；还有一点我觉得是结对开发最有利的一点，就是随时有人在做code review，如果你写了一行代码让你的搭档看不懂了，你就需要向他解释，如果解释不清，肯定是代码写的不好，这会提示你去用更好的方式（随着你给他解释代码）改写这些代码；如果你是一个老手带领一个新人，你的开发习惯、编码思路以及对代码的解释也会对他产生很好的培训效果，这对整个团队而言是很有意义的……
总之吧，无论用或不用结对开发的方式，里面的很多思想还是值得借鉴的（就像无论用不用Java都可以从中借鉴很多思想一样）。而且就算要采用结对开发，也应该先了解XP相关的其他实践（最关键的就是测试驱动开发了），同时要找到一个合适的搭档，虽然新手老手、专家菜鸟、俊男靓女都可能组成可以工作的搭档，但是每个人还是会有比较特定的搭档类型。最后，最关键的一点，我认为结对编程（尤其是配合上轮换结对的方法后）对于整个开发团队而言是非常有价值的——所以我还是很鼓励从来没有尝试过这种开发方式的朋友们，找个心情不错的时候，找个和自己比较默契的搭档，结对一把，天塌不下来的——没准还真掉下馅饼呢？：）
BTW：推荐一本通俗易懂的书——《结对编程技术》（2004），网上买才十多块钱，没准会对你的开发生涯产生巨大的影响呢！：）
测试驱动的开发同样可以达到理顺思路的目的，你不必须写真正的业务代码，只是将整个商业face测试进行测试
结对，en，不错。感觉好极了。感谢JGTM传受了我N多的知识，同时我也非常高兴能够帮到你：＞，这个下午过的非常愉快，随着我对项目的熟悉，相信会更好的。
不过这并不意味着XP就可以颠覆所有已存在的软件开发方法论，只是大家各有所长罢了。我感觉，XP对于小到中型软件项目开发是非常有效的（通常这个项目的团队包含2-10人左右，项目周期倒不重要——XP强调快速迭代、持续交付——每次跌代的周期大多在两到三周而已，而每次交付的间隔也在三到六个月）。这可能也是微软这样的软件巨头公司不采用XP方法而采用自己总结的MSF框架的一个原因吧。
所以说，Ken提供的信息也从另一个角度说明对于一般的软件开发公司或团队而言，因为团队的成员并不像MS的雇员那么qualified，所以结对编程反而会产生比较积极的效果。
而对于sam1111提出的情况，我倒建议你们能够找一些机会在小范围内采用结对编程的做法进行实践，比如说找一个悬而未决的问题让两个最有可能解决这一问题的程序员结对开发，或者找两个平时比沟通比较顺畅的程序员对某一个新的挑战结对开发。通过观察他们解决问题的过程和结果，你将体会结对编程是否适用于你们的团队——无论如何，在小范围内尝试一下对于任何一个健康的团队而言都不会造成什么大的伤害。也许你会发现，两个人一台电脑用同样的时间将可以获得比两个人用两台电脑还要多的进展；或者即便只达到了一个人的生产效率，你也应该能够明显感到代码质量的提升——而代码质量的提升从大的方面一样是提升了这个团队的效率。
而progame描述的情形确实是结对开发有效性的一方面原因。很早以前就有这样的培训方法，让程序员对这一只玩具狗熊讲他将要或者已经做的事情，从而理清思路、找到解决问题的突破口。所以，既然对这一只玩具熊这招都管用的话，那么对着一个大活人说话肯定会更有效（源自《结对编程技术》一书，2004）。另外，结对编程也并不鼓励一个人专门打字、而另一个人总是看着。它要求两人之间要保持频繁、持续性的交流，在编码的同时持续的review（所谓极限编程，就是将软件开发过程中的一些最佳实践发挥至极限——那么既然code review is good,那就将其做到极限——开发的时候就有review；同理，既然unit testing is good,那就在每次build完成都进行自动单元测试——源自《极限编程解析——拥抱变化》）。
还是那句话，不能孤立的看待结对编程的开发实践，它是整个XP方法论中的一个组成要素，同时它也需要其他XP要素的有效支持。
说实话，我对XP不推崇，但我觉得这依然是一个好方法。
什么东西都往业界领袖看起，并不一定会使你自己成为业界领袖的。
多保重身体，革命的本钱啊，嗯。
jgtm描述的情况有些类似，通过向同伴描述问题，同时使自己的思路更加清晰。还有，很多时候自己都下不来决心来重构某段代码，但在和同伴的交流中，同伴对自己的肯定会促使自己去实现想法而不仅仅是想做而不愿做。
要是真如XP中所言，一个人在写代码，另一个人要坐在旁边检查，我想我会发疯的。