困惑的结对编程？

        在软件工程方法学中的XP方法中，最让人感到困惑是在实际XP实践中实施得最少的那一条原则，即是结对编程。

        很多人都有一种这么理解想法：XP的十二条原则中，其它的我都赞同，但是为什么要让两个人在同一台机器上编码？一个键盘两个人抢着打？空着别的机器干吗？

        结对编程技术是一个非常简单和直观的概念：两位程序员肩并肩地坐在同一台电脑前合作完成同一个设计。同一个算法、同一段代码或同一组测试、与两位程序员各自独立工作相比．结对编程往往只需花费大约一半的时间就能编写出质量更高的代码， 但是，人与人之间的合作不是一件简单的事情——尤其当人们都早己习惯了独自工作的时候、实施结对编程技术将给软件项目的开发工作带来好处．只是这些好处必须经过缜密的思考和计划才能真正体现出来。而另一方面，两个有经验的人可能会发现配对编程里没有什么技能的转移，但是让他们在不同的抽象层次解决同一个问题会让他们更快地找到解决方案，而且错误更少。

       结对编程还有其他多种好处：

       1、直接的、连续的代码回顾。

       2、与别人工作会增加责任和纪律性。

       3、同时理解一个问题。

       4、在有人盯着的时候去偷懒要困难得多！

        两个程序员具有相同的缺点和盲点的可能性很小，所以我们当我们采用结对编程的时候会获得一个强大的解决方案。而这个解决方案恰恰是其它软件工程方法学中所没有的。 
        在我们平时的编程当中，如果遇到一个非常难解决的问题(困难到对该项目产生厌烦的态度)，那么你势必会希望录求帮助，无论是从信息量庞大的Internet网络里，还是从身边的技术大师里，你都会拼了老命去解决(前提是你有对计算机知识的势爱)。这个时候不妨采用结对编程试一下，其它的不说，可能感觉就不同。

       代续......

PP说的是collaboration，而不是非要两个人一起搞。其他所谓的好处，我觉得不是主要的，或者说只是副作用而已。其实它把QA的peer review给带了进来，即时的peer review。可惜，这种方式在生产率上有瓶颈，因为浪费了人力。所以PP只是历史的产物。

pp不应该也不可能是一条xp的“原则”，而只是一条最佳“实践”。

分享knowhow

to:basicbest
   考虑一个典型的代码开发工作，如果有一个需要一个人8小时开发的模块，将由8个人花一小时去写代码，也就是等于总共要花费16个工作人日。然而，编码者不能保障有必需的时间去熟悉其他7个人的代码，而且他们的孰悉程度也会因为各自的技术水平不同而表现出不同的孰悉速度，而且也会相当的肤浅。单个人的开发确实能够非常孰悉自己的那份代码，但可能就是因为太熟悉以至于不会与别的同事进行沟通与讨论，从而发现不了一些潜在的错误与漏洞。
    对比结对编程的实践方法，如果这个模块需要两个人合作8小时来开发，总共需16工作人日来完成。然而，这种情况下，两个伙伴将会非常熟知这个模块的代码，而且在开发过程中所隐含的一些错误也将被子另一个伙伴所发现。
    因此，结对编程其实并没有浪费人力（至少可以说是吃平），反而在其它方面会带来很好的收获。

如果项目是数据驱动为主，结对编程能有效的提高效率吗？

thoughtworks的朋友出来说说感想可以么？

假设一个bug在设计阶段被发现并修复所需的成本为1，到编码阶段发现并修复的成本就为10，到测试阶段为100，到发布维护阶段为1000。这是软件工程教科书上写的。
结对编程的一个好处是尽早找到并修复bug：由于频繁的peer review，设计、编码阶段的大量bug不会流转到测试、维护阶段。由于bug流转的成本以数量级上升，仅仅这一项好处就已经足以补回结对编程所有可能的成本消耗。

当对于一般的Bug来说，每个Bug的解决时间是编码时间的4倍，且两个开发人员的开发效率都是50%，假设在一个编码人员和两个编码人员编写同一个模块上，且他们需要的时间是相同的前提。当我们考虑到一般的程序员在单独编程时，可能需要上网查找一些资料、思考、打盹这些非编码时间可能会占用30%的时间。而结对编程时，假设这部分非编程时间仅仅只减少一半的话，那么实际编码的时间是100%-(30%/2)=85%，那么我们重新评估一下，两个一般的程序员结对后，将产品质量提升到75%时的时间应该是2*85%=170%，而单独编程时间要将代码质量提高到75%需要的编码时间是100%+(75-50)*4%=200%。

一堆假设的数据有什么意义？
问题还是：如果项目是数据驱动为主，或者在一个久经考验的成熟框架下，那么结对编程对项目最大的帮助是什么？是否能够有效的提高生产效率？