只谈TDD（从“大师打个喷嚏，我们都要重感冒”中拆出）

你硬要说一个我没有说出的观点，就是我的本意。我也没有办法。

我已经不知道你究竟想表达什么了，呵呵。
我觉得你的思路又落入了以前 robbin 说的“抗拒多元化价值取向”的老路了，按照你的话就是认为这些问题肯定都是有定论的了（或者按照 CMM 的想法认为任何软件开发活动都存在一个“最佳实践”）。也许你对你正在谈论的问题的本质并不是很清楚？不过你确实并没有完全理解 XP 和 TDD（我也没有完全理解，所以才会讨论）。
现在我们确实是生活在一个百家争鸣的时代啊。我们争论这些问题本身就是一件很有益的事情。
做事有两种：做正确的事和正确地做事。我觉得相对于 CMM 而言，XP & TDD 更有助于我们做正确的事。不好意思我又非此即彼了。
还有一个问题是没有定论是否我们就无法工作了。只要你自己的心中有定论就可以了。克服一切困难把手头的工作努力向前赶才是最重要的事情。我觉得奇怪的一点是你为什么这么强烈地追求这些“定论”。莫非你对自己的见解也是非常地疑惑，所以需要在这里找到一些自信？

实际上，这里大家说的是两个方面，一个是谁可以使用TDD，一个是使用TDD能否成功。
对于第一个，应该没有什么可争论，问题出在第二个方面，成功与否和TDD没有什么必然联系，TDD只是一个方法，而项目的成功与否会受各方面的影响。TDD并不能保证小蚂蚁采用TDD就会成功，也不应因为没有这个保证，就断然拒绝TDD。

追求定论，是我一贯的思维方式和努力方向。

当年我在一个法学论坛，与人讨论法制、法律问题的时候，也有人这么问过我。当时我就写了一篇文章，但是却从来没有贴出来过，专门解释我的思考的基本模式的。叫做《一个人的巴别塔和思想上的太玄经》。如果你有兴趣，我可以把这篇文章贴出来。

至于这样的追求是不是抗拒多元化，我想这是一个太大的帽子，我实在承受不起这样的“罪名”。因此，我决定坚决否认自己有这样的企图。

还有就是你说我是不是需要找到自信的问题，这样的疑问，实在有点诛心之论的味道，不是辩论该用的手段呀。

如果只给我看，文章就不必贴了。我最近很忙，不要拿长篇大论来炮轰我。我也不喜欢读这类长文的。
抱歉啊，说话确实刻薄了。Take it easy.

设计模式始终只是为了达成更好的设计的手段，而不是设计的目的。不可能说是为使用设计模式而使用设计模式，所以说“OOD的目的更加明确，向设计模式靠拢”，真是不知从何说起。
应该说开始时OOD的目的提高程序的重用性，从而提升软件开发的效率。而渐渐地，OOD对程序的灵活性和可扩展性给予了同样的关注，如果不是比重用性更关注的话。不过这跑题了。

遵循TDD的原则开发出来的程序是否必然是“优雅”、“合理”、“健壮”的呢？是否必然有待证明（“必然”在逻辑上太强了），但至少是可以帮助我们向“优雅”、“合理”、“健壮”的目标前进的。要使自动化的单元测试能够实现，必须降低程序模块之间的依赖关系的复杂度，否则会使我们无法将要测试的代码从整个系统中隔离出来进行单元测试。TDD将迫使程序员从使用者的角度来考虑模块接口，迫使程序员把测试目标代码对其它模块的依赖减少到最小程度，把测试代码与其它模块的接口简化到最简单的程度，迫使程序员使用诸如Code to interface 等等Best Practice。这些都有助于程序员设计出高内聚、低耦合的程序，从而向“优雅”、“合理”、“健壮”的目标迈进。

不过我也认为目前至少在国内不是所有的程序员都能实施TDD，原因并不是因为“小蚂蚁”可能看不了太远，TDD并不要求在写程序时看太远。而是因为很多程序员确实还不具备实施TDD的两个必要的基础知识：
1. 能分辨什么是好的代码，什么是不好的代码，也就是能识别出代码的味道。
2. 知道写出可测试的代码的必要手段，知道如何降低、简化模块间的依赖关系。

关于TDD与设计的关系，我是这样理解的。
不可能通过TDD把一个大而复杂的系统从一张白纸，或直接从需求就直接建立起来。无论是XP的书， 还是TDD的书，都没有让我得出这样的结论。而且我也无法理解会有人得出这样的结论。TDD是实现某个具体的任务时的策略。而任务的分解就是设计的工作之一了。

XP中没有设计吗？或者Martin Fowler说“设计已死”就是说不要设计吗？呵呵，呵呵。

TDD 不能教会你这些知识的，这些知识可以从另外一本名著《重构》中得到。建议大家读了《测试驱动开发》后立即去读《重构》。在我看来 TDD 是为重构建造一个很好的安全网，如果没有 TDD 所写的一系列自动测试所构筑的这道安全网，我很难保证重构不会改变系统的行为，或者不会引入新的 bug。

“OOD的目的更加明确，向设计模式靠拢”，这话是一句反讽。怪我没有说清楚。

我的意思是在实施TDD之前应该有这两方面的基础知识.。

刚看了2004五月版的"is design dead?",居然发现几天前我在那儿抨击的一个全局重构的问题已经在这个版本中被打了一个补丁。
martin建议团队中找一到两个人关注整个代码集。hehe,这样的话，受项目规模的影响就更大了。