结对编程简介

抱歉抱歉。猫咪在建立圈子后一直特别忙，来不及写东西。今天终于空闲了一些，可以写点东西上来啦。结对编程是敏捷开发的重要实践之一。但是一般情况下都是在敏捷开发书里略微提了一下，就没了。纯粹写如何结对编程的书猫咪就知道一本《结对编程技术》。虽然很薄，但是写得很不错，大家可以看看。

结对编程，指的是这样一种程序设计实践：两名程序员并肩工作在同一台计算机前，共同探讨设计方案、共同设计算法、共同编写程序代码、共同完成各种测试。在这两个人中，被称为“驾驶员”的那个人负责打字或写出设计方案，被称为“领航员”的另一个负责其他工作，包括随时观察驾驶员的工作情况，发现并纠正其操作性和策略性失误。操作性失误包括各种语法错误、打字错误、用错了函数，等等。策略性失误包括驾驶员偏离了正确方向--即他正在编写的代码不能让这两位搭档到达预定目标--的各种情况。领航员扮演着战略思想家的角色。我们都曾有过走错路的经历，但如果能够有一位领航员问我们一个简单的问题--“你能解释一下你为什么这么做吗？”，我们大都能够及时回到正确的路线上来。领航员对问题有着更为客观的视角和对事态发展方向有更全面的思考。另一件大好事是驾驶员和领航员能够随时交流彼此的看法。优秀结对程序员之间的交流是非常活跃的，驾驶员和领航员至少每隔45-60秒就会交流一次--有时只是一句简单的“啊？”定期交换驾驶员和领航员的角色也是非常重要的。

以上摘自《结对编程技术》第一章。

猫咪希望大家能在此把自己对结对编程的看法、尝试结对编程的经历和对结对编程的疑惑都写出来，大家讨论。看能否在国内推广，以提高大家的编程快乐，而不是每天看着乱七八糟的代码发愁。

我想俩个人在一起做事是会比较快乐的吧，但对公司来说要看哪种方法多快好省，而要做出这样的判断似乎不容易

我会专门就此写文章的。不过还只是抄书。希望已经有过实际经历的人在这里说一下自己的情况，看是否提高了效率。

在现在国内的公司有几个可能这样？两个人一起，肯定能提高软件的质量，但是效率？而现在的企业，绝大多数是为了赶项目，呵呵，估计是没几个公司弄的起这个

结对编程对制造垃圾和半成品的公司确实没用。不过对追求高质量的公司来说是节约时间的。两个人结对编程，虽然比一个人快，但是确实比两个人单独写代码慢。但是出来的代码的质量（运行速度和BUG数量）要比单独写好很多，而且更加容易读（毕竟边上的得读懂）。测试可以更容易通过，所以很多调试、排错的工序可以省掉。也减少了日后找BUG的成本。从这方面来看，结对其实是节约了时间的。但是对于那些只制造垃圾的公司来说，这些省掉的东西他们本来就不做，所以是浪费了时间。

我想关键在于，如果你是领航员，你有足够的时间和精力去思考问题，驾驶员可以更专注的开发，如果合二为一，结果就是两个线程在一个人的脑子里来回切换，不过多数情况是代码质量线程的优先级别低于开发
也就导致了，质量低劣的代码出现在你的程序里。

我在学校时，接到项目开发都和同学采用结对编程的方式开发，当时也是因为看了敏捷开发和结对编程的书，尝试的，感觉很不错，的确提高了编程的效率，出错率也大大的减低了。但是参加工作后，就很少采用了！

LZ似乎对pair programming太乐观了。我一直在用pair programming（4年了）。

发现人的因素大于你用什么，而且我个人的观点pair programming 90%的情况下不能提高效率，反而会使效率降低。而代码质量则很难说，如果两个pair都很认真那还好，如果整天都是混日子，则不如code review来的好。

这里有一个围城效应没有pair的人想pair, pair的人想出来。折中的方法就是如果我没有confident去独立完成一个task则我会邀请另一个quanglified的developer来给我一起做（菜鸟没用，only越帮越忙）。

可以用质量换效率么？快速的生产垃圾代码 能称之为高校么？

一个人做事的时候，你能一直保持注意力集中 而不去看nba、看javaeye海阔天空、msn、qq泡妞、看股票、看小说………………………………………………
如果旁边一直坐着一个人 或者你坐在别人旁边手里没键盘，显然这些事都可以避免

如果大家在各忙各的，有个不懂的技术问题，你能毫无顾虑的找个人一起讨论么？
这还算好的，最要命的是，如果没人在旁边提示，你都不知道哪些事别人知道而你不知道

人不是机器，
编程需要激情，
软件需要创造力，
pair programming太理想了，让我联想到鬼子和台湾人的血汗工厂。
看看google，看看微软吧