大师打个喷嚏，我们都要重感冒

大家一般都不由自主希望能够用简单的数学模型来解决问题，但如果是这样的话，就真的有庄所说的定论了。但在这一点上我比较同意Adaptive software development的看法。（我认为这本书是整个agile的理论解释）

一个软件团队以及内部发生的事情可以看作是一个Complex Adaptive System,self-organization,emergence,nondeterminisim,是一个living organisms.不是简单的数学模型所能描述的。

所谓的emergence看来是突然出现（很难用数学模型得以解释，例如达尔文的物种进化），实际上是这个living organisms为了自己的生存和目标不断自我修正，自我重组的结果。

至于相关的复杂自适应系统理论、混沌理论我是一翘不通，但James A. HighsmithIII 应该很好地解释了，我们做软件的应该能够看懂。

问题在于你要保持的不是自己那一部分代码的简洁有效，而是需要保持项目范围内设计的简洁有效。这个时候，讨论沟通的成本是非常高的（取决于项目团队的规模），或者有一个专门的代码复审机制，但那样就回到老路上去了。至于网上的搜索，对这个问题没有帮助。
  要消除重复代码，你必须知道另外一块类似代码在哪里。这是个关键。

至于为什么某个项目不能采用TDD，还不如说采用TDD能够给项目带来哪些好处。注意，。前面说过了，沟通和测试都不是TDD仅有的。
孤立的看TDD，意义我觉得只是和Test First Programming一样。
前面说过PP，其实还有一个现场客户也至关重要，不过这个话题太大，不好说。但是现场客户很重要，这个相当于TDD的一个前进方向的评估函数。
至于寻优，对于一定规模以上的问题，以传统方式寻找最优解其代价是不可接受的。一般而言都是在指定时间范围和计算能力下内寻找满意解。或者说，存在一个找到最优解的概率问题。不同的算法可能有不同的能力。

扯远了

这样论题不甚明确的讨论谈起来不是很有意义。
论题明确，跟目标明确，需求分析明确都是一个道理。

把TDD比喻成爬山法本来就是一个比喻，从局部最优解扯到动态规划，最后变成软件开发是不是一个可以动态规划的过程。绕了一圈又绕回来了，是扯得有点远。
如果都这样的话，我看用不着什么隐喻了。

我以前曾经有一段时间非常关心元胞自动机/人工生命，对自组织这类东西有点印象。这类系统大都在简单规则下emergence出一定的结构(行为方式也是结构的一种)，有非常棒的数学基础(元胞自动机的鼻祖就是那个大拿冯*诺伊曼)。但是这类系统也存在一个重要的问题，就是难以萌发出复杂的结构来。人工生命这个分支后来也逐渐淡了下来。
我觉得这里有两个制约因素，一个是规则的设定问题，另一个是时间问题。
如果以这个作为理论基础，感觉上反而不牢靠。

我有点跟不上了。说说我的这个爬山的比喻。

这个比喻要是说透彻的话，会更加有意思。

200～300~400，是很大的高度差？还是很小的高度差？

这取决于你的步伐。

对于步子大的巨人来说，200米的山头是第一步，300米的山头是下一步，400米的山头是第三步。没有问题。

对于蚂蚁来说，上200米就是巨大的挑战，下来也是，再上另一个山头，就算也是200米，也可能花掉他一生的时间。

而且，更加糟糕的是，对于巨人来说，他在这个200米的山头，可以很清楚的看见另外的几个山头，这点高差对他来说，根本不是什么障碍。而对于蚂蚁来说，要说服他相信另有一个300米的山头，几乎是不可能的。

OK，回到我们的软件开发。重构是一个很好的手段，利用重构，我们可以寻求最好的解决方案，而不是在一开始就设计出来。

但是，重构的步伐大小，是一个问题。在你熟悉的领域，步伐可以大也可以小，那是一个自如的境界。但是在你不熟悉的领域，你无法大步伐的重构。你根本无法设想，大步伐重构的可能性。

所谓局部最优解，更加确切的含义是：局部的尺度，与步伐的大小有关。这就是我说的，熟悉该领域的高手，能够很好的应用TDD的深层含义。

但是，我看TDD的书，看XP的书，里面没有任何一句话告诉我这个问题。那些大拿们，以自己每步100米的能力在看待世界。所以他们才说：“不要设计，不要做预设计”。因为对于他们来说，“不存在死角，不存在过不去的坎”。

potian，我不是要说TDD不是一个好方法，或者XP不是一个好方法。但是这种方法能不能用好，与这个使用者的能力有很大关系，虽然他们那些大拿的书里举的例子，都既浅显，又愚蠢。但是，他们都是那种没有盲区的人。而对于一个初拿大刀的人来说，砍着自己的可能性，同样存在。

这一点，是需要很大声的说出来的。但是，他们没有！

to 庄
只有你这个大拿才说过“不要设计，不要做预设计”。关于XP中的设计你可以去看看“设计以死？”
我不知道你们几位到底要说明什么?小步跑不能解决问题，只有预先的设计才可以。但是你们又说对200米来说蚂蚁认为太大了。那么蚂蚁到底应该怎么办呢？等在原地不动吗？
设计不是一个简单的工作，谁也不可能说他的设计就绝对不存在问题，谁也不可能一下子就建立一个完整的设计。都是要一步一步的来，都是要小步跑。只不过是一种是边设计，就边测试自己的设计。一种是只是单一的作设计。具体什么方法更好，你自己看着办。
大牛们告诉我们要小步跑，并不是因为他们认为自己是牛，而是因为他们知道自己的能力有限，所以他们才不得不去小步跑。预先的设计如果可以解决稳定的建造的问题，当然是最好。但是问题在于设计很难做到无错，所以必须进行验证。而我不知道你如何对设计进行验证，单独的依靠拍脑门？
还是那么什么线段的例子。是不是你们不小步跑，一下子就可以知道最好的答案？我看你们最后也是第二天才知道的，并没有因此就在开始才发现。为什么要小步跑这就使一个原因。因为很多更好的设计不可能在最开始就被人们发现，必须经过一个过程。你必须进行摸索，具体的实现你的想法，并在这个过程中通过反馈得到新的想法。
凭空想象是不能给你带来完美的设计的，努力的开始进行下去，不断地接受反馈，不断地修正你的做法，这是一个自然的过程，也是一个谁也跑不脱的过程。
强调设计从重构中浮现出来，并不是因为人们觉得设计不重要，而恰恰是因为人们觉得设计太过于重要，不是那么简单的在最初的几下子就可以做好的。当然我不否认你和charon是技术大牛，你的才能是我们这些人所不能拥有的，所以你们的步伐就必然比我们的大的多，设计自然也比我们高明的多，所以你们可以进行预先的设计，并且保证这个设计会没有什么大的问题。但是我想你们也有你们的限度，你们也有你们不能做的事情，你们一定也会在不能的时候被逼迫去小步跑。这个不是你们不愿意承认就不存在的，因为大家都是这样过来的，谁也不是一下子就成为一个软件天才的。

我觉得这里有几个问题需要理一下：
1 正如"设计已死"中所迷惑的，XP中的设计至少分为两个流派，或者简称为kent派和martin派。从kent的精神来看，一个B/S项目应当从基于脚本的cgi开始，或者从jsp开始，逐渐衍发出对后部代码端的需求，然后这个后端又引入分层结构，区分出MVC各个部分，以及独立的业务层和数据层。或者更有甚者最终会达到ejb架构。像一般日常做的那种一上来就是某种MVC架构 + BO + hibernate或者别的东西的做法，本身已经不符合这种内涵了。
相比之下，我还是比较接受martin的想法。
2 设计的变化或者优化的原因并不是设计的难度，而是因为需求的变化。设计本身只是一个技术问题，对于一支有一定技术经验的团队来说并不是难事。但是需求则属于业务领域，要比设计难得多。设计的验证也不是验证设计是不是可行（验证技术可行性有很多种方法），而是验证是不是符合业务需求？前面的那个爬山法隐喻，所爬的也是需求这座山，只不过TDD中其手段是演进的架构。
   如果需求是明确且不变的，我想这个问题基本上没有可争论的地方，传统的软件开发方式已经有了非常丰富且有效的手段来处理这类情况。
   问题只在于业务需求的调研和分析上。一种做法是强化需求分析的技术和启发式导向，比如需求工程，原型技术等，分析模式的某一侧面也属于这个范畴，尽可能的明确目标系统的需求(这里我觉得最困难的是向用户展示系统的能力，如果有原型系统或已经成功实施过的项目为demo，效果会非常好)。另一个是类似于XP的方法，只不过在敏捷方法中XP是最激进的一种。其基点是项目团队前期不可能在全局和整体的层面上把握需求，而采用滚进的方式。
   这样，问题的关键就变成项目团队能不能够在前期通过充分沟通来从整体上把握项目的走向。如果能够，我认为 总体设计 + test first programming的方式要比XP牢靠，或者说这种方式是限定范围的TDD。
   假设项目团队有充分的技术经验，如果同时也有领域和行业经验，那么对关键业务需求的定位和把握上我认为是较为可能的。这里的所谓关键需求，一则是决定项目成败的、甲方所必须获得的目标，另一个则是影响系统架构的。在我的印象里，大部分琐碎的需求属于平凡的那一类，对架构不构成有效影响。
3 从另一个角度来看，业务需求的变化有两个来源，一个是需求调研不够深入，沟通不够有效导致的；另一个是业务本身在项目进展过程中发生了变化，这里面也得区分这个变化对架构的影响。我觉得XP如果有优势，也在于后者。因为它没有为需求的定位和架构的设计付出专门的代价。
   如果架构需要转身，这个转身的代价不管是那种开发方式都是一样的(现在正经的做法都会有大量的各种层面的测试，那种没有安全网的半成品本身也不符合任何一种严肃的开发方式的要求)。只不过有前期化在调研分析上的代价和架构转身所需要的代价之间的平衡。我的观点和几位最大的不同在于
1 前期沟通和分析是有效果的，即便不能够完全消除转身的可能性，也能够消除大部分。
2 架构转身的代价是较大的。以至于有必要去尽量避免。
3 前期沟通也不是无限制的，关键在于识别出影响项目成败和架构的关键因素(或风险)。以书面的形式确定下来作为备忘。当这些因素发生变化时，甲乙双方就必须重新对项目的走向进行讨论和评估。

还有一点，从现在国内的政府机关或者国有企业的项目操作流程上来看，并不适合XP.
招标的时候必须对项目的规模，大概的平台选型、架构选型有一个基调。中标之后还有一个具体合同的商谈过程，合同签订之后即刻采购软硬件(也有可能实施标和平台标不是一个标，时间上会有先后，但不太大)。就是说在项目的相当前期阶段软硬件的平台和架构实际上就已经被确认了。而且现在软件在总成本的比例不低。以现在国家对国有企业和政府机关加大审计力度的做法来看，企业和机关为了规避风险，这个合同中价格条款的后期更改可能性比较小。