对于结对编程我有疑问

两个人坐在一起只是个形式而已。经常互换作Code Review同样可以保证代码的质量，不一定非要坐在一起。我更喜欢短会＋头脑风暴的方式。把主要代码的结构和流程，类之间的关系大家讨论一下就ＯＫ了。再说也不一定所有人都喜欢边写旁边还有个人边看边说的。：）

1. 概述：Pair Programming是一个编程模式(Programming pattern)。两个程序员并排坐在一台电脑前，面对同一个显示器，使用同一个键盘，同一个鼠标一起工作。他们一起分析，一起设计，一起写测试例子，一起编码，一起单元测试，一起整合测试(Integration Test)，一起写文档等。基本上所有的开发环节都一齐肩并肩地，平等地，互补地进行开发工作。
2. 角色：
 Driver：写程序的人，简单的说就是打字的人，哈哈。
 Navigator：看程序的人，简单的说就是背后的人。
3. 目的：
Pair Programming的目的有如下几种：
 进行有效的Design Review
 进行有效的Code Review
 保证代码质量
 保证流程的执行
4. 分组：
目前，我们也要实施Pair Programming，具体分组如下：
分组 Navigator Driver
A1 杨某 张某
A2 宋某 秦某
A3 贾某 庞某
A4 郑某 陈某
B1 陈某 李某1
B2 李某2 付某
B3 李某3 段某
B4 刘某 崔某

5. 我们Pair Programming的方式：
 Navigator和Driver分别使用各自的计算机。
 Navigator和Driver通过CVS交流代码和文档。
 Navigator在审核后，要填写Pair Programming日志表，并上传到CVS相关目录（在CVS上建立一个结对编程的项目，按照组合分为A1—A4，B1---B4）。
 Driver – 写设计文档(Class diagram等)，进行编码(Unit Test and Business Object)等XP开发流程。
 Navigator – 审阅Driver的文档、Driver对编码等开发流程的执行；考虑Unit Test的覆盖程度；是否需要和如何Refactoring；帮助Driver解决具体的技术问题。。
 主动参与 – 虽然每个Engineering Task都有owner，但不能一旁观者的心态来做。任何一个Task都首先是两个人的责任，也是所有人的责任。没有“我的Code”、”你的Code”或“她的Code”，只有“我们的Code”。
6. 考核方式
第一期结对编程以1个月为期限，从宣布之日起，所有的组合应该完成以下任务：
 每天至少一次的Code Review；
 每周至少一次的design Review；
 一个月Code Review的文件应该在80个以上。
 每个月末，由评保部来检查Pair Programming日志表，不按时填写的，每缺少一次将扣除积分5分。
7. 编程比赛：
 月末，举办一次编程比赛，由A组和B组进行比赛。具体规则，另行通知。

      其实，这不是一个纯正的结对编程，只是为了解决我们目前有部分程序员水平和经验都不足，而采取的一对一带人的方式。
     额外说明的一点，我们的结对编程中的一个重点就是在设计期间，二人一起参与，共同参加。

结对一定程度上可以防止惰性，可以相互监督的，所以结对的工作强度比非结对来得大、来得紧凑，无形中减少了加班的可能

加不加班和工作强度其实没有关系……

对于结对编程我有疑问：
实际编写代码的人总是对代码的结构和功能、细节更清楚一些，而观看的人总是很难同编写者一致，第一天差别也许并不明显，但是第二天、第三天....一个月之后呢，对于简单的项目也许没有什么，但是对于复杂的算法和复杂的对象调用关系、对象的状态等问题，这种差别就非常明显了。
请在实际项目中使用结对编程的同仁谈谈自己的感受，尤其希望有处理复杂逻辑经验的同仁不吝赐教。

敬上。

在XP的核心实践中，结对编程是我执怀疑态度的一个，当然，我的怀疑不是说XP的创造者们是拍脑袋出来的，而是怀疑它在中国，在中国软件企业可以实施的现实程度。
很难。。。。
    结对编程的初衷是什么？两个人一起写代码，一起理解代码，防止代码出现味道？通过多交叉的结对编程，实现代码的共通（不只是共同拥有，而是共同理解），同时也可以起到对规范的遵守？抑或，还有其他？
好像是review 的一种提前
    但是我对那样的一种工作环境始终保持疑问的，我就列出几种环境，看看是否有网友可以帮忙理清：
1. 假设项目不是新做的，或者说中途有人离开团队，或者说结对编程的其中一个成员是后加入的，这样的情况在软件企业是非常非常常见的，这样在结对编程的两个成员中水平、理解力、熟悉程度在出现较大差异的时候，如何保证结对编程的质量。
（如果公司有新人是不是要带呢？如果现在不带什么时候带？反正我当初就如同结对一样天天去问边上的大哥，他很头痛的说。。。。）

2.如何保证结对编程的两个人中坐着的那个人能保持高度的专注力和责任度?每一个程序员都有过这样的经验，一起坐在一台电脑前解决一个问题，但这是偶尔的，如果连自己的电脑都没有，每天大部分时间就和另外一个程序交换着电脑，能一直保持高注意力。再说，中间有个什么事情（比如会议、打扰甚至上洗手间）离开一个人，回来后，不是还要回头去理解别人写的代码么？

（大约是只有完成任务时才要专注，想像一下review时你是怎么看代码的。。。大约是一目十多行吧。。。只是发现bug机会少一点吧）3.在稍微一个大的软件公司，对于配置管理都是相当看重的，基本上不允许哪个程序员可以看到和拥有所有的代码（就中国这点知识产权的保护意识，和国外是非常的差别），并且对于员工的绩效考核也都是基于负责模块的表现（比如说代码量，bug数，以及复杂度等等），结对编程在实施上就存在一点权责和利益的的问题了。

（。。。。XP的代码是共有的。。。。还有有很多难点啊。。。）
4.另外，结对编程，在每一时刻都是一个程序员在编程，说效率如何高，也只是1+1>1，但是否大于2呢？中国软件企业的项目，多半的规模是在10人以下（程序员部分），而完成的代码量都是相当大的，所以加班现象很多，在如此情况下，实施这个实践，难不成要double的人力资源？

（如果架构好了再次开发相似模块时可以重构以减少代码量
如果只是搬砖头的活。。。XP还是不要用的好效率会高一点）

5.最后，就是和XP的另外一个实践的冲突（个人理解），也就是代码重于设计，我不太清楚基于XP的工作模式，是怎么做设计工作的？是通过某些CASE工具，如rose/together来进行设计和编码的相互切换（也就是边设计边编码），还是直接就在IDE上进行编码？我们知道，有些模块和重要内容，不是简单一两个类或者一两个模式组合就可以解决的，中间要用到很多的设计的思想和步骤，并且每一个程序员都有过这样的经验，设计是跳跃的，不是循序渐进的。连自己也不知道下一步会想到什么（这就是为什么程序员是需要创造性，工资高的原因之一），更何况坐在边上的人？难不成在这样的情况下，编码的人还要停下来，去解释自己暂时也不是太清楚的过程的想法？

（
直接在IDE上编码的话还是退回去用C好一点“过程语言”更方便
面向对象的都是先设计再编码的
XP是由背后的人来设计一般是纸片上的
写代码的人去实现 。。。。不太管设计
由背后人告诉代码人要什么样的功能
而用什么方式由代码人来把握
）
    也许偏颇，但以我个人的经验，我认为结对编程只能在有限情况下进行实施，并不如XP中所描述一样前景异常美好。