【IT168 专稿】

    坊间流传着这样一则故事：

    从前，有一个A型血的人和一个B型血的人去登山。显然A和B有着不同的登山方法。

    A到了山脚下，总是先停下来，仔细打量山势。接着，围着山脚转转，看看哪些是小山包，哪个是主峰。然后，设计几条不同的登山线路，并选择出最好的登山线路作为首选计划。同时，他还考虑到如果首选计划出现问题，则可以启用第二计划或第三计划......

    而此时的B几经爬上了第一个小山包。B登上小山包的时候，发现这个小山包不是去主峰的路。B并没有气馁，稍微打量一下环境，立即从小山包上下来，往更高的一个山峰进发......就这样，B无时无刻不在后退中前进，在下坡中上山，已经将A远远的甩在后面。

    最后，B成功地登上主峰，而A还在半山腰艰难地攀登。当A终于登上主峰之后，B说了一句很有很有意思的话：你现在知道极限编程的威力了吧！A默然不语......

    一位想学登山的新手来向A和B请教登山的方法。A把他的线路图和计划全部给了新手，没有说一句话。新手看都没看，就跑去问B。B意味深长地说：努力，努力，再努力，当你到达山顶的时候，就知道了登山的方法！新手由衷敬佩。

    多年以后，A成功地登上了珠穆朗玛峰。据说B倒下的地方离一号营地只有一百米远......

    当那位新手终于找到A求教的时候，A还是将所有的登山线路和计划交给了他，依然没有说一句话。

    但新手明白：这就是设计！

    这则故事非常形象地解释了什么是XP（极限编程），什么是设计？每次读都让人有新的认识。从故事中我们看到，不断的积累最终会形成良好的设计模式才能更好地去完成项目，一味地相信极限编程则会在项目庞大时失去方向；而一味的相信传统设计，又会在需求多变、需要灵活应对的项目中花费过多的时间精力而丧失先机。

    同时，传统设计具有极限设计所不具备的传承性，可以积累大量经验；而极限编程对经验传承则要差得多。即使一个项目获得了相当的成功，可面对新项目时，无法继承或很难继承，从而造成后继者需要重新去做，而传统模式只需要将经验教给后继者即可。

    到底是用传统的设计开发模式还是极限编程方法，成为设计、开发人员面对的难题。

    客观地看，这两种不同的工作模式确实各有利弊，各有适合的场合。如果是对于需求非常明确的项目，比如公司自己开发的软件，或者以一个相对较大的受众为潜在顾客的项目，那么无疑传统开发模式是最好的选择。

    但是对于需求不是非常明确的项目，比如为其他公司开发的软件，或者以一个特定受众为目标的软件项目，大量的前期设计工作，往往是很危险的。总体来说，对于一个依靠传承经验延续下去的公司，采用规范的设计模式优势更加明显；而对于工作室或小型外包公司则正好相反。

    那么，如果故事中的A与B展开合作会是怎样？在极限设计和传统设计之间能否找到一个中间的路线呢？试将故事改写之。

    从前，有一个A型血的人和一个B型血的人去登山。A和B有着不同的登山方法。这次两人决定合作登上。

    A到了山脚下，先停下来，仔细打量山势。接着，围着山脚转转，看看哪些是小山包，哪个是主峰。而此时的B已经开始爬上第一个小山包。

    通过通迅设备，A和B随时交换着信息，A会告诉B，经过观察，某小山包不是去主峰的路，避免走那里；B会告诉A，在攀登路上的具体情况，提供信息给A不断修正其设计线路。

    B在不断探索和A的指示下，从一个小山包向着更高的山峰进发，很快就到达半山腰。A的设计也基本完成，他开始沿着A已经趟出的设计路线前进，并仍不断与A交换设计路线并修正之。

    最终，两人几乎同时成功登上了主峰。

    一位想学登山的新手来向A和B请教登山的方法。A把他的线路图和计划全部给了新手；而B则意味深长地说：沟通、信任、努力，当你到达山顶的时候，就知道了登山的方法！