[敏捷开发][结对编程(Pair Programming) ]

结对编程能够增进团队成员的友谊，这是真的。
有些程序员不适应，往往和性格有关。

结对的方式，可以多种多样，这要看面对的任务类型。

和女程序员pair，确实不错，因为大量无意义的争论要少得多。男人是泥阿，男人加男人就是和稀泥，赫赫。

和美女PAIR?我想到后来的结果大概是你自己在PROGRAMMING,美女在旁边剪指甲了。

再说了，你也知道，我们这行的，美女多吗？还是醒醒吧^_^小心回到侏罗纪时代

回到正题。
对PAIR PROGRAMMING很是感兴趣。
按照我自己的现状，一天8个小时（加班的时候达到10多小时）里面最多有4个小时是出活的时间，效率最高。如果PAIR了，可能我一整天都在和我的同伴进行激烈的讨论。也就是说，我们两个有8小时的出活时间。这么简单的量化，说明效率上没了问题。
再想想，PAIR的时候，我可能一些BUG被我的同伴预见了，那么你应该知道，我可能省去了一天的找BUG、改BUG的时间，或者更多...
再再想想，可能我和我同伴的PAIR的过程中，讨论的结果是很有建设性的，而不会象自己思考的比较片面。

这么来说，PAIR非常棒！

好处真不少，缺点说说：

领导看来，那两个家伙怎么一整天都在那边聊天啊。工作不饱和。 这时候，我们需要一个不错的领导,他还要懂得XP(注意：不是WINDOWS XP)。可是，领导是你决定的吗？不是，所以...

还有，假设我的同伴是个不想干活、又喜欢无端争吵的人（你应该会碰到这种人）。那么我可能整天干活都没心情,看到他就不爽，最后，我再也不想PAIR了，最后，我辞职了...

当然，再有，找自己的原因。我是个不爱沟通的人，我很固执，我技术也不行，这样的后果是，别人看我很不爽。最后,他辞职了...

问题：领导是否支持沟通，是否认为沟通在软件开发中处于核心地位？
如果领导认为软件开发中，沟通不重要，那么......
如果领导认为沟通很重要，而且很鼓励团队去进行频繁沟通，那么问题就解决一半了。


假设一个团队10个人，这样的同伴估计最多只会有2－3个吧，每天SWITCH Pairer，这样一周也就和他们结队一次，站在团队的角度，忍一下吧，兄弟。不过，我不喜欢忍，我会去沟通，在合适的时候让他意识到自己的问题，提醒他，告诉他这样做是不对的。

还是上面的答案，这样的我在团队中不会有太多，否则大家早就完蛋了。这样的我是需要学习和教育的。因为我辞职的家伙，是在逃避问题。每一家公司，多少都有很多让你不爽的地方，你不能逃一辈子。

钱。
烂代码是要花时间来修的，bug是要花时间来抓的，code review是要花时间来做的，一个人独自干了一个月的活别人要花很长的时间才能弄明白，更何况说不定哪天这人就走了，花的时间就更多。时间都是要钱的。
这就是pair的理由。如果你的领导连钱都不care……

问题在于领导通常不会有这样精明的想法，由于领导从来没有实践过pair，也就没有了比较。
实际上，我认为pair要推广开来，还需要花大把的努力，不光是钱的问题。

领导认同pair是为了钱，不认同也是为了钱。 只不过到底怎么做才能省钱却不是每个领导都知道的。

他辞职也好减少了老板炒你概率
技术不行。。。。固执。。。。不爱沟通。。。。听着怎么那么像老板的小舅子？

大钱与小钱，看的见的钱与看不见的钱，认为最大的问题存在于眼光与现阶段的主要需求是什么。。。。

大家都知道星际移民是正路。。。。
但是谁会为星际移民出钱呢

这同IT业普遍的长期加班比较类似，大家都骂头头傻，难道不知道长期加班工作效率低？
但实际上，他们就是这么干的！“秀才遇见兵”，你咋跟他说道理？

结队编程是XP极限编成的一个关键实践，如果把结队编程放到整个XP里面会更容易体现出它的价值，所以我觉得分析结队编程的一个整体思路是：

1、适用场景：
XP的适用性在哪里，什么样的项目中适合采用XP，在这样的项目中XP可以起到什么作用。如果离开了适用场景，XP的适用性都要重新考虑，所以就更不用谈结队编程了；

2、实施条件：
从理论上我们面对的项目可以从XP那里得到很大的价值，但实际中我们的团队具不具备实施XP的条件，即并不是什么样的团队都可以采用XP，特别是结队编程；

3、结队编程的位置和价值：
结队编程在整个XP中的地位，它和其他哪些关键实践有着相辅相成的关系，它可以应对项目实施的哪些问题；

4、结队编程遇到的问题：
结队编程在实施的过程中，会遇到这样那样的阻碍和问题，这些阻碍和问题，可能是因为不恰当的使用引起，可能是因为对XP关键实践的局部采用引起，或其他。

1、适合场景：
适合采用XP的项目特征为：规模小，时间紧，需求变化多，质量要求高
而且我觉得这些特征不是“或”的关系，而是“并”的关系。
如果只是规模小、时间紧，但是需求变化不大，那么敏捷所强调的“拥抱变化”就谈不上了；
如果只是需求变化多，但是时间比较充足，那么可以侧重原形驱动方法；
如果规模比较大，需要几十个/上百个人、半年甚至一两年的项目，那么采用稍微重量级的RUP，还是要稳妥些。

所以如果我们怀疑XP以及结队编程的价值或者实施性的时候，可以考虑考虑我们面对的项目，是不是适合采用XP来开发，在这里我觉得应该强调的特征是需求变化多。

2、实施条件：
在实施条件上，我觉得团队需要具有XP的文化是很重要的，团队成员需要达成一个共识，就是认同XP开发会给项目以及自己带来价值，这种共识需要若干个因素，如团队意思/共享意识等等。
此外XP对团队成员的技术水平要求也较高

如果团队不具有XP的思想意识，以及必要的技术水平的话，那么就更谈不到结队编程的效果了（当然部分水平相当的人还是可以在适当的情况下，采用局部结队编程）

3、结队编程的位置和价值
在XP中，一个关键的假设就是“只注重眼前需求的简单设计而通过重构来适应需求变化”的代价和成本小于“对系统进行充分详细的设计，但是随着需求的变化设计失效”的代价和成本。
所以结队编程的价值在于，我们无法在项目的初期进行一个详细的设计，即使完成一个设计，随着需求的变化，设计也是需要频繁的改动，因此与其我们花费大量的时间和精力来维护不稳定的设计文档的一致性，不如我们简化、延迟设计，用简单的实现来满足当前的需求，而依赖重构来适应需求的变化。
所以结队编程的价值在于：
1、使代码实现的无错误、且最简单；
2、更好的、更有效地使代码易于重构；
3、进行及时、有效的重构，避免单人开发的惰性而不愿重构。

如果我们觉得我们有很成熟的设计，很稳定的架构，可以说我们的系统不需要重构就可以满足所有需求，那么我觉得结队编程的价值就大幅度下降了；
如果我们觉得我们的需求会不断变化，我们的设计需要不断的进行调整重构，那么结队编程是这种重构最好的保障和实施。

4、结队编程遇到的问题：
结队编程会带来效率的降低
在一个具有实施XP能力的团队，出现这样的问题往往是
i、由于人员的变动，来了新成员
在这种情况下，前期确实会对其搭档产生一定的影响，但是磨刀不误砍柴工，通过结队编程，可以最快的使新成员进入状态，通过后期的高效完全可以弥补前期的消极影响；

ii、后面坐着的人跟不上写代码的人的思路，写代码的人要不断对其讲解
结队编程不仅仅只是一起写代码，在写代码之前也需要一起对需求进行探讨，一起讨论设计方案，达成共识之后才再一起写测试用例，一起编码，一起测试。
如果出现跟不上的情况，那么赶紧停下来，需要讨论的时候到了。

iii、由于每个人有不同的习惯风格，坐在后面的人不习惯写代码人的代码风格
这正是XP另一个关键实践的必要性：代码规范。在采用ＸＰ方法后，要求所有成员编写的代码都想出自于一个人之手写的，这样才能使代码本身就是设计，方便所有成员沟通维护。
通过代码规范之后，也才使ＸＰ强调的另一个关键实践“代码共同拥有”成为有效。

iv、结队搭档步调不一样，如一个人有事或打电话，或去洗手间，另一个同伴岂不空闲
如果一个人有事那么另一个人可以对设计与实现重新进行思考，思考仍然是软件开发中最重要的事情之一。
此外自己也休息一下，也不是一件很坏的事，呵呵。

结队编程很累
结队编程确实是强度非常大的一件事情，在结队的时候我们就不可能边写代码边带着耳机听音乐了，呵呵。
但是结队可以使两个人精神更加集中，可以扩展思路以创造更简单，更严谨，更便于修改重构的代码，所以这正应对了项目时间紧的要求。
因为ＸＰ是一件强度很大的过程，所以ＸＰ强调４０小时／周的另一实践

现状是：
很多CODER在CODE的时候都没有考虑以后的BUG,REVIEW,维护的时间...
那么你又怎能奢望领导来了解这些呢。
领导一般要明确的是:哥们，你那东东什么时候能提交?
他想的钱应该是:赶快把这个项目上去,就能回款了。该死的维护,再说吧。没准到时候还能收点钱。