开发模式之精英开发

 

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

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