初次接触极限编程的朋友都会发现里面的一些原则、概念不好理解，甚至和我们一直以来被灌输的原则或概念冲突。比如：简单性要求、测试先行、拥抱变化、隐喻等等。换个角度看看也许我们会少点困惑。

我想大部分的程序员都不会反对把编程看作是一种探索过程。我们孜孜不倦地（或者被迫的？）不断探索一个问题的解决方法。实际上这是所有科研人员，尤其是基础理论研究的科学家们每天都在干得事情。我们客户的需求就像科学家们需要解释的自然现象。科学家们需要从大量的观测、试验结果中总结出一些能解释这些观测或试验结果的定律。而我们则需要将客户的需求分解成一个个测试用例，并编写出能够通过这些测试用例的程序。我们的程序就相当于那些定律。我们总希望我们的“定律”可以解释一切（程序永不出错）。但是，目前尚未找到一个可以解释一切的理论体系（也许永远都找不到）。所以我们在这点上需要保持谦虚。

科学家总是对前人的理论持批判态度，而我们总是对我们自己的代码存在着恐惧，我们总是害怕它在什么时候会可耻地崩溃。科学家们总是用各种试验、观测去检验他们的理论。所以我们必须用各种测试用例来检验我们代码的正确性。在科学探索的道路上，现象总是先于定律出现（没有凭空出现的定律），有需要解释的现象才有定律的出现，因此测试要先于实现。

实际上我们不必恐惧代码的失败，因为科学家们总是欢迎理论无法解释的现象。那通常标志着理论将有大的突破。上世纪初无法解释的黑体辐射和麦克尔逊-莫雷试验让我们迎来了量子力学和相对论的辉煌。当我们的程序在某个测试上失败、或者干脆的在运行中崩溃。不要沮丧，那表示有新的知识等待我们去掌握。虽然这通常对于项目管理人员不是一个欢欣鼓舞的消息，不过管理人员应该学会在坏消息中生存，该来的还是要来的，早来好过晚来。在这点上科学家处境比程序员要好，因为他们通常没有什么进度要求。

当理论和实际不符的时候，伟大的科学家都会毫不犹豫地抛弃旧理论。同样的程序员需要有随时修改、抛弃旧代码的勇气，如果这些代码不能通过测试的话。这貌似废话，不过许多人（包括爱因斯坦）都在这里栽过跟头。当你试图通过修修补补去满足测试的时候，是否想过重构一下海阔天空。

理论一般在极端情况下失效，比如，牛顿体系在接近光速的时候。因此测试需要考虑边界。然而我们需要掌握合理的边界。当我们不计算接近光速的运动时，用牛顿体系就完全足够了。既然在人类登月的时候都没用到相对论，我们还需要让我们的代码适应那些实际不会发生的情况吗？能够解释现象的理论可能有很多种，而科学家们总倾向于其中最简单的那个，所以当我们有多种编程思路的时候，选择最简单的。有时候数组比链表更好就是这个道理，虽然看起来“没什么技术含量”。

实际上，保持简单性是一件很困难的事情。

事实上，我这篇文章在解释极限编程的时候就用了里面的一个概念——隐喻。