XP？我真应该采用吗？

我阅读的第一本关于软件工程的书是讲述极限编程（XP）的。当时我还在读大一，似乎啥都不懂，但却对XP很感兴趣——毕竟它提倡简略一些我不想学习的东西：文档、设计……当然，它自身的理论也很吸引人，看上去就像12个实践的完美结合体。

后来，我又陆续看了很多其他的书，浅略地了解了传统的瀑布式开发、敏捷（Agile）方法等。然而我只是粗浅地了解，尽管如此，却仍不免怀疑以前的看法。

没错，XP看上去是很美：它简单，每个人都能看懂，也符合我这种激进的年轻人的心态，我似乎没有理由拒绝它。可是，它真的安全吗？或者说，它比采用其他的方法失败的危险性更低吗？

在《解析极限编程：拥抱变化》中那张描述XP的12个实践紧密相连的图里，你看到了什么呢？XP真的像描述地那么简单吗？不，至少我不这样看，因为我被这张图乱七八糟的连线给弄糊涂了。我能想到的只有3个字：紧耦合。没错，每个实践都是如此密切地和其他实践相关联，很难想像偏离了一个实践后，整个XP不会土崩瓦解。

我想，我们确实需要如XP中所说的勇气，可是光有勇气是无法编程的。即便有足够的勇气去面对XP的脆弱，随着时间的慢慢推移，失望的次数慢慢增多，我们似乎也没那么多信赖给予这个激进的方法。我们也许可以鼓起勇气接受XP，但不一定能在实践的过程中，坚定地坚持这12个实践——而放弃任何一个，也许就意味着项目注定失败。

XP不是神话，否则怎会没有成功用XP实现的大型项目呢？即便是神话，那也是神才能做到的，谁有足够的信念坚定不移地实践XP呢？人们经历过很多失败，自然会对风险大的事物保持怀疑态度——如果现实也趋向如此，则更加。

为什么XP让人感觉风险大呢？我认为是它放弃了太多有用的实践，而过分依赖其他的实践来弥补。例如采用紧急分析和简单设计，花上10分钟来进行分析设计，就开工了；然后为了扩展功能，又得花上不知道多久的时间来重构——1小时，1天，1月，或者直到项目以失败结束。也许谨慎地花上几个月来分析和设计，或者至少几天、几小时的时间，重构的时间就可以节省1小时、1天、1月，甚至挽救整个项目。重构并没有错，但过分依赖重构来弥补设计错误，就如同摩天大楼盖到一半时，把楼拆了改建地下停车场一样愚蠢。虽然XP强调拥抱变化，客户可以在楼盖到一半的时候想到应该可以在楼下建个停车场，于是XPer欣然地把楼“重构”了。但如果开始设计时就保留了建立停车场的空间，即使后来客户没要求建立停车场，又会有多少损失呢？需求确实是变化的，但通过分析，确定大粒度的不变性；再依赖设计，提供可更改的扩充性，不是更好吗？

没错，XP的很多实践看上去都不错：结对编程、单元测试、重构、持续集成……但这些还不足以决定项目的成功，而过分依赖这些实践，是否太过极限了？更重要的是，有些实践是很难做到的，例如现场客户。另外，对于1个房间容纳不下的团队，也是无法采用XP的。

也许，我们可以让XP不那么极限，拆开各个实践之间的紧密联系，对它进行“重构”，形成一个“高内聚、低耦合”的方法。Agile包含了很多方法，除去XP，也许有那么几种会更适合软件开发——只是它们的知名度没XP高罢了。

只是我仍没主意，到底应该怎么重构XP。项目已经开始了，拉了个同学来实践结对编程，花了几天找了个QQ上能联系的客户，花了几个小时学习CppUnit的使用（比JUnit麻烦多了；居然在VC2005上很多构建不了，还得回到VC6），可是离其他实践还远得很。我也不喜欢写文档，那花去我太多时间，我宁愿用来写日记——可我还是得写，那让我编程时思路清晰。我喜欢分析和设计，想到一个好的设计会让我很有成就感——似乎比实现它更多，所以我会在这方面多花些时间。

管它呢，反正年轻不怕失败。没有什么应不应该采用，我该做的就是按自己认为正确的想法去做，失败了就换个方法再试一次——史泰龙不也在当上男主角前被拒绝了1850次吗？也许一向运气很好的我，可以直接尝试第1851次～～。