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

hehe,算法又不是凭空出现的，只是在理解问题域基础上给出的一个解决方法。我这里所谓的算法密集型，指的也只是那些非直观的算法。在不少应用中，基本上算法都是直观平庸的，此时，TDD不会有太大的坏处。但是，对于那些需要透彻分析问题域才能够得出精致算法的情况，不同的解决方法之间跨度很大，个人认为此时tdd无能为力。并且，那些因应之前算法所给出的测试用例，多半也将被废弃。因为随着对问题域了解的深入，会发现原先组织测试用例的方法都是不恰当的。
这个，前面那个哥们的例子就非常典型。

中国人的确实缺少独立思考的能力，更不要说深入思考的能力，我现在看来其实思考的能力都缺乏，根本就跟不上大师们的思维。
就TDD来说，核心在于你提前必须对你要做的事情作出具体的测试标准，然后就针对你制定的这个标准进行针对性的解决。就nihongye提出的问题来看，根本就和TDD没有关系。TDD不能告诉你这样一个算法的解决，别的任何的一个方法也不可能告诉你怎么解决，这不是软件工程研究的范围，也不是工程学研究的范围。但是是不是TDD对这个情况就没有任何益处了呢？答案当然是否定的。你的算法不管如何高级，如何独特，都是要完成你的固定目标的，这个目标就是你TDD中的那个T。
所谓的算法密集型，不管怎么密集，你一样要对算法算出的结果进行验证。提前进行对这个验证进行系统化的建造，我不知道是不是对某些人来说是一种困难。你至少应该去验证你的算法是不是成功的，是不是合适的。这就是不凭空想象。
任何一种东西都是有生命周期的，必然会最终被抛弃。测试也是如此，会随着你的设计的前进不断的被修改，被再次认识，或者再次被抛弃。这没有任何的问题，因为迭代增量开发就是这样的一种方式。而那些认为可以开始就把一切都做好，然后就不再去修改，不再去完善，也不能被抛弃的做法，完全就是一种典型的瀑布思维方式。
TDD是一种人类作事情的传统思维方式，只不过KENT在软件开发中把他具体化了。否认TDD的原理，其实就是否认人类的思维方式的合理性。人类做事总是先去制定一个目标，TDD就是在软件开发中让你必须把这个目标具体化。人类作事情也总是循序渐进，由简单到复杂再到简单，TDD就是让你再软件开发中尊重人类的这个习惯。

hehe,不至于上纲上线吧。
如果不和重构一起来看，单论TDD是没有意义的。而结合起来以后，实际上体现的是一种小步前进的哲学。
前面已经说过了，这种小步前进的做法类似于寻优方法中的爬山法，很难从一个局部最优点演化到另一个稍好一点的局部最优点，因为那个时候任何一小步都导致梯度下降。
至于说TDD最重要的在于构造测试，那是看轻了它。关键在于测试驱动的设计。用测试来驱动设计！！而不仅仅是构造测试。在前面那个哥们的例子中，最好的办法是把问题域理解清楚，而不是马上开始用测试来构造测试。
另外，TDD和"人类的思维方式"一点关系没有。真的，这只是一种解决问题的办法，没必要搞一点神圣的外衣。

这里看过TDD这本书的请举手。如果没有看过请买一本看看，很便宜。它的前言有很多的地方谈到了你们的所谓争论，我就不多说了。我现在就主要谈谈人类思维的基础问题。人的意识基础是类型化，也就是对那些认为有联系的事物进行类型划分，并安装一至的方法进行对待。这样的类型划分主要是从个别的部分的类似性开始的，并且由其对于差别化的容忍，可以使类型的严格程度得到不同的解答。而当人们面对一个新的事物的时候首先想到的就是利用原来经验进行新的实际，并且在这个过程中不断的反馈修改，从新形成新的经验。而由于人类思维的受其自身的能力限制，不可能处理过分多的信息（注意这也可以认为是人脑的一种功能）。人类的思维于是多数情况下是在一种逐步而渐进的情况下进行，并且越是困难的问题，人类就会越是小心的把前进的步骤放到更小。而实际上，由于人类思维的联系性，因此造成那些与更多的意识联系更多的观念发生变化的时候，思维的总体会随着发生剧烈的变化。但是这些剧烈的变化无不是以这些细小而琐碎的变化为基础进行的。然而对于人类认识习惯的知识很不被重视，并且很多人认为存在一种不依靠这些细小的变化而产生的剧烈变革，这样的思维方式就是我们说的凭空想象的思维方式。
落实的软件开发中，这些凭空想象的开发最主要的体现就是瀑布方式的思维。这些观点认为，一个好的方法可以给你一个了理想化的一次性的解决方案，并且只有这些方法才是唯一正确的方法。于是人们认为设计不应该被修改，更不能经常性的被修改。并且任何东西都不应该被抛弃，抛弃一点就是莫大的浪费。这是一种不切实际的幻想的方法，而不是理想的方法。
我们在这讨论的并不是关于TDD的任何事情，而是关于小步跑或者说增量化开发的是否必要的问题。也就是一个局部化的优势是否能造成一个整体化的优势。这更想一个哲学的问题，但是这确实是一个重要的哲学问题。我的信仰是，任何进步都是有一点一点的细小的进步所积累起来的。任何一个优秀的设计，都是通过不断的修改和优化所带来的。算法也好，结构也好，都是一步一步的进行的。早期的认识必然会有缺陷，但是如果不通过这些早期的认识，你就不可能得到最终的结论。凭空想象的思维方法，让人们认为你可以一下子就前进很远，并且只要你凭空想象就可以作到。
然而人的思维是受其大脑处理信息的能力所约束的，即使个体的人之间会有差异，但是智商和方法的影响造成的差异并不能就造成可以在个别人个别时候突破这个局限的理由。只要软件工程还是一种工程学，就必须遵守工程学的最基本原则－－以人为本。

读一本书未必就要认同那本书的观点。多读一些自己不认同不喜欢的观点的书是一件非常有意义的事情。
hehe,所以以某本书里面的东西作为依据，对于不认同这本书的人来说，意义本来就不大。而且我向来不能够认识太过高深的“人类思维方式”的问题。如果有人真愿意讨论这个问题，我还是原来的那个比方，小步前进的方式如何避免寻优中的爬山法面临的局部解困境。现代的很多寻优算法，所希望解决的也只不过是加快收敛速度和避免堕入局部解的平衡。从另一个方面来说，也是眼前利益和长远利益的平衡问题，这个至少现在还没有一个好的解法。但是任何一种可以接受的解法里面，包括人类的思维方式，总是提供了一种可以跳脱局部解或者思维定式的方法，不管这种方法强度如何。
但是在TDD+重构的小步跑的开发策略中，我找不到这样一种跳脱性。或者说，当开发到一定程度发现自己的路径是错误的，仍然继续小步前进的原则，还是彻底摒弃。此时，小步跑的代价是很大的，因为必须做一些稍后肯定或被废弃的东西。
另外一点，瀑布方式并不是凭空想象的开发方式，它也有着一系列的手段和方法来保障其不是凭空想象。其缺陷只在于需求太早定型。而小步跑和增量开发或者迭代开发也不是一回事情。增量未必是小的，迭代更有可能带来大的变化。
以人为本更加与是不是TDD毫不相干。正因为以人为本，所以更加需要强调开发人员的差异性，区别对待他们的经验。TDD并不能补足在洞察力和经验上的缺陷，但是交流和深入思考却能够。
跟着感觉走，未必抓得住梦的手。

感觉上无论是瀑布式还是TDD碰到这样的问题都不会有很好的解决方式，只是当路径的改变在一定的范围内时，TDD更能显示出一些优势。

同意，以人为本和什么方法没有任何关系，但决定采用什么方法时，是否以人为本却能看的出来。

to charon：
我觉得你最初寄希望于 TDD 来解决这类问题根本就是错误的，最后发现解决不了归罪于 TDD 仍然是一个错误。
TDD 只是我们工具箱中的一件工具，你觉得不顺手不用就是了。Kent 也说不应该强迫所有开发人员采用 TDD 的。Kent 的说法和我两年多前最初接触 TDD 时的一些预感有着惊人的相似。我参加的那个 XP 团队失败了，遗憾的是他们没有做任何的总结（长官意志、面子问题，老大还是老大，他犯了错误别人能说吗？）。结果他们现在只知道 XP 不好，而完全不知道自己犯了什么错误。究竟为什么不好？是原本就不好还是因为自己犯了错误？没有人知道。这种神秘主义是非常有害的一种东西，打消了任何把工作做好的信心。

比较认同dlee的说法，TDD只是一种工具。TDD提到测试步伐大小这个问题，kent beck的意思是自己认为合适的方式(记忆力很差，或者错了，摆脱狂扁我)；从一个步伐到另一个步伐，工具是重构,方法是程序设计的n条原则。我提到的问题，是因为想模仿书上斐波契数列的例子呵呵，或者在某些算法密集型的例子里，一个测试步伐，可能异常大（长期的思考积累和洞察问题的能力,因为重构里的方法，跟算法关系很少），接着假如我们想到一个方法，那么建立一个测试用例来验证我们想到的方法吧。

hehe,我并没有对TDD抱多大的期望，我所喜欢的是总体设计(Big Picture) + Test First/Driven Programming + 重构的做法，而不是Test Driven Development/Design。
前面诸位谈到的(或者说我在很多地方看到的)TDD的优点实际上并没有脱离TFP的范围, 比如构建安全网，小步前进。但是，TFP很重要的一点是开发者对方向是有自己的把握的。
但TDD并非如此。它并不需要开发者对问题域做深入的思考或规划，或者说避免这么做。瀑布或迭代方式对此却有显式的要求。我的想法就是既然TDD摈弃了这种做法，那么肯定需要有一个解决方案。但是我没有看到。
前面的那个例子，实际上深入的思考是可以解决问题的。但这是我所谓的算法密集型的场合。再举一个更加简单的例子，比如有一个X(n) = aX(n-1) + bX(n-2) + cX(n-3), 并且已知X(0),X(1),X(2)的数列，对于三个开发者，A学过数列，B,C没学过，对于A来说，这是一个平庸直观的问题，直接求出X(n)关于n的表达式，立马搞定。假设对于一个没有学过数列的哥们而言，得出数列规律的算法需要1天时间，那么，B遵循TDD，那么不应化时间去研究这个问题，所以只能直接使用递推逐个计算，而C花了这一天时间来得出公式。当然，如果n不是太大，B的做法无所谓，如果n允许非常大，那么B的算法就死定了，比如每个n都需要BIGINT来表示，这样的递推加法当n足够大的时候是很恐怖的。最终B还是避免不了去深入思考这个问题。
我相信当时C3碰到的问题除了所谓的现场客户以外，这是一个最重要的原因。开发者完成的系统当发薪人数超过某个数目时耗用时间急剧上升，这实际上已经是一个体系架构的问题了，而大师们XP出来的东西到达了那么一个局部最优点以后，已经不能够小步跑向另一个峰顶了。一个为了解决2000年问题的项目，最终在2000年被cancel掉了。
或者那么说，TDD做出来的设计是短视的设计，即便保留了一定的灵活性，但是这个灵活性并不能够抵消潜在的通过前瞻设计可能消除的隐患。所以，TDD只能适用于那些平凡直观的项目，以及单峰型(只存在唯一解决方案)项目。我相信这里的大多数人只要有若干年的经验，都会碰到过体系架构的设计决策情况，在此时多花几天或者几个星期来研究和论证决策，要比推迟或者回避决策好很多，特别是这类架构型的决策。

还有，TDD不仅仅是一个工具，更重要的是一种项目开发的方法论。关键在于用测试来驱动开发过程，或者简化的说，是针对"设计已死"而给出的一个替代前瞻性设计的方法。
对于XP，最近发现一个类似于宗教战争的书评区，去amazon看看那本"Extreme Programming Refactored"的书评吧，它的星数不是0-1就是4-5(有个哥们说给5星是因为没有更高的级别，相信那些给0星的哥们也仅仅因为没有负星级)，没有中间值。而且给高分低分的都有大拿级人物。这本书对XP彻底质疑，不是Questioning Extreme Programming的改进派。