TDD和OO Design矛盾吗？

刚刚大概翻了一遍TDD by example一书，感觉其鼓吹的思路是从Test case开始通过一次次的迭代使设计自己“浮现”出来，这和传统的OOAD矛盾吗？

何止是不矛盾。OO是TDD的前提条件，TDD为OO提供保障。试想，如果没有好的模块划分，如果没有清晰的接口设计，如果不“对接口编程”，如果没有组件化的体系结构，你测个什么劲？

TDD 是鼓励你写可测试的代码。为了写可测试的代码你就必须多考虑改善代码的设计。从这个角度看，TDD 是增强了 OOAD 而不是和 OOAD 矛盾。
有些人总是认为世界是非黑即白的，每天不搞上三五个 xxx vs. xxx 连饭都吃不香了。实际上在高手的眼里，这些所谓的矛盾体其实都有其用处的。必要的时候随手拿来用就是了。

TDD 确实没有教会我们如何去做设计，《测试驱动开发》这本书也完全不是讨论应该如何做软件设计的。如何做好软件设计我们有一大堆经典图书，《设计模式》、《Anti Patterns》、《软件复用》、《Java Modeling in Color with UML》、《分析模式》等等。

因为我知道没有银弹，所以我并不指望某种单一的手段能够大幅度提高开发效率，我常常组合多种手段来达到我认为理想的开发效率。TDD 对于我来说只是工具箱中的一件工具，但是我认为 TDD 是一个非常有效的放大器（amplifier），可以将我在其它各方面的技能放大到最大限度，因此我很欢迎 TDD。但是并不是意味着学会了 TDD 我就不需要再学习其它知识了，我仍然需要继续学习才有可能在这个行业中继续生存。你肯定不会认为 Kent Beck 只会 TDD 吧？呵呵。

如果你在追求一劳永逸的解决方案，那么扔掉 TDD 吧，它并不是你所期待的银弹。如果你并非在追求一劳永逸的解决方案，那么 TDD 对于你就是一件极为有用的工具。

怪我问题表述错误。我的意思是，在传统的OOAD流程里，Coding之前我们会得到Class的specification，也就是有哪些fields和methods。尽管在以后的迭代过程中还会不断变动，但至少我们有一个较完整的起点。而在TDD中，在写TestCase Code之前Class根本不存在，Class specification是在一次次red bar、green bar、refactoring的循环中逐渐成型的。我感到困惑的地方就是这里，即在Class实现这个层面上，TDD怎么Fit into到传统的方法中间去，是替代，还是结合？尚无TDD的具体应用经验，所以才想请教各位在实践中是怎么处理这个问题的。

对于“TDD是鼓励写可测试的代码”这句话，我持不同意见。从JUnit这样的测试框架出现开始，大家就已经意识到“写可测试的代码”的重要性。TDD的重心不在Test，而在Driven，也就是通过test和refactor的循环来形成Class的这种思路。

BTW，在这口水仗流行的年代，大家对“矛盾”、VS之类的词都很敏感啊。 我当然没有怀疑OOAD价值的意思，也不会把TDD当成Silver Bullet。在我看来和诸多行业相比IT业还太过年轻，还有很长的路要走。

这个仍然是你对 TDD 的误解。Class 是不存在，但是并不意味着 Class 的设计也不存在。如果连 Class 的设计都不存在，你知道要测试什么，如何测试吗？在你写测试代码的时候至少接口的设计（系统与外界通信的协议，那些公共的方法）都应该定下来。
《测试驱动开发》这本书没有一句话否定你应该先设计好类然后才开始做开发（就算 Kent 这家伙这样说了，你只要觉得以前的开发方式好就继续用好了，难道他还能拿着戒尺跑来打你吗？），所以你仍然可以采用原先的开发方式的。但是 XP 不同意 planned design（计划式设计）而提倡用另外一种 evolutionary design（演进式设计），有空了看看 Martin Fowler 的《设计已死》。你所假设的设计在编码开始后就应该完全固定下来，不允许发生变化是错误的，也是很难做到的。
其实 Kent Beck、Martin Fowler 这些人都是 OOAD 的大师，他们不会完全否定自己的经验。所以在我看来用 XP 这个新瓶装些旧酒也是很正常的事情，以前 o6z 兄说 Kent Beck 就是此道的高手。

这个争论很有趣，我也来说两句，首先从什么是设计说起。

1、什么是设计
设计就是选择，我们做一个软件，不只是要完成必须完成的功能，我们还有其他的目的。正是这些其他的目的，影响了我们的选择。在同样能够完成功能的各种方案中，我们如何选择，我们依什么标准而进行取舍，这样的思考的过程，就是设计。

2、OOD是什么样的设计
OOD的目标其实很散乱，最早期的OO非常明确，就是要让这个设计更加接近真实世界的对象。但是到了后来，面向对象并不是简单的模拟真实那么简单，很多OO的原则被提出来了。OOD的目标就成了遵照OO原则。再后来，设计模式出来了，OOD的目标更加明确，向设计模式靠拢。

3、TDD是什么样的设计
TDD的设计目标很单一，就是使程序不但能完成功能，而且能够便于“独立的、自动的”测试。能测试的，或者便于测试的程序，并不必然是好的程序，也不必然是OO的程序，这样的目的，并不必然的导向“优雅”、“合理”、“健壮”。“便于测试的”，是一个好的目标，但是他们不应该成为程序设计的主要目标。但是因为推广TDD的都是些大师，所以事情就变得复杂起来。

4、TDD与OOD究竟是什么关系
他们事实上没有任何关系，但是因为发明TDD的人，大多数都有深厚的OO功底、以及娴熟的重构的能力。因此，当他们觉得程序的“味道”不对的时候，他们会将程序重构得更加“OO”。这样的动力，其实以为着遵循TDD的人，同时遵循了一个明确的目标（便于测试），和一个隐含的目标（符合OO原则）。

5、这样有什么问题
这样对于kent那样的大师，当然没有什么问题，对于OO的直觉已经深入他的骨髓，那个隐含的目标已经无需用来提醒自己了。但是对于很多没有深入理解OO原则的初学者来说，TDD所谓的通过代码的演化、使得优秀的设计自动浮现出来，只会助长他们的“盲目自信”，对于没有足够基础知识和足够经验的新手来说，遵循TDD，对程序进行1000次重构，也不见得就能得到一个优秀的设计。因为他根本就不知道，什么设计是优秀的。

6、TDD+OO？这样就够了？
我们知道，设计是一种选择，但是TDD+OO，这样的选择还不够多，而且两种手段的目标“互不相干”，有可能导致设计时的无所适从。主线、次线的划分，也并不完全公平合理。我们需要一个更好的目标。一个完整的、统一的目标。

我会在《定论》里，逐步推出我的结论。

什么是TDD的目标，这个问题非常简单。我们只要亲自去看一看KENT的书，就可以看到他的标准答案。这个答案他说的非常好，我的一切阐述都是罗索的废话，所以请大家伙去看书，前言第一句就开始讲的是这个问题—— clean code and works。
我们应该注意的是TDD虽然是以T打头，但是并不是说的TEST,也不能认为说的是DESIGN，他主要还是一种软件开发的原则指导下的开发方式，同时包括了测试和设计以及其他的一些方面的（例如管理，计划，发布，维护）内容。

感觉中国的很多软件人读书非常成问题。不仅仅是不实践，而且连读书根本都成问题，不求甚解、断章取义。读相同的书，我得不出任何与他相同的结论（比如同样读《人月神话》，我得不出任何与张x 相同的结论）。而其他绝大多数人根本就没有能力读书，于是把这些读过书的人写的文章认为就是大师原本的思想，类似于朱大师《论语集注》一类的书（这类书我从来不读的，《论语》真的很难读懂吗？汉语的伟大就在于我在两千余年之后居然可以比较容易地读懂《论语》）。这些竖儒以讹传讹的危害实在是够大的（到不是会对我产生危害，主要是对初学者产生危害，而初学者上了他们的道时间长了就会变成一个废人），而他们往往顶着“专家”、“顾问”的头衔。我最害怕的就是这一类的“专家”，到不是学校里面专门研究软件工程的老师，学校里的老师们都是些很可敬的人，有机会的话我非常想向他们求教的。o6z 兄发明了“杂技派”这个词来形象地概括这类人我认为非常恰当。
读书也是非常重要的，因为我的知识不可能全部来自我自己的实践。昨天买了一堆书，包括张x 的老师 Rational 三友写的两本：
《面向对象分析与设计》，Grady Booch 著。OOAD，这个是正宗了吧？
《软件复用》，Ivar Jacobson、Martin Griss、Patrik Jonsson 著。

今年花时间读完，然后和张x 飚文玩玩。玩理论是吗？陪你玩。