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

在“大师打个喷嚏，我们都要重感冒”这个帖子中，有的谈大师，有的谈XP，有的谈TDD，感觉主题不甚明确。我把TDD从中抽取出来，发表一个新帖子，大家就来集中讨论一下TDD这项技术。

TDD是Test－Driven Development的英文缩写，网上也有叫作Test－First Development，我想很可能两者是指同一概念（无从考证），至于这两者究竟有啥不同，我真的说不上来，自我感觉TDD相对于后者来说更主动一些而已。

TDD的概念看上去是非常之简单，只有两个步骤：

1、编写一个不能通过的测试，然后编写代码让测试通过；

2、消除重复代码，优化设计结构。

从上面两个步骤可以看出，TDD很注重的几个方面：

[list]1、一个时刻只关注一件事，步骤1就是在增加新功能，步骤2就是在重构，也就是Martin所说的“两顶帽子”，TDD让你在两个角色间频繁的交换。所谓的步骤跨度从这里就可以看出，你最好是保证每一刻只干一件事，跨度的大小取决于你对问题的理解、解决问题的能力和对TDD的熟悉程度等。但是，只要我能做到每一刻只干一件事，无论跨度多小，也不会有错。[/list:u]

[list]2、TDD与重构是结合起来使用的，没有第一步你就不能增加新的功能，没有第二步你就不能得到“整洁并且能工作”的代码，两者缺一不可。只有有了测试，你才能更大胆的进行重构，只有经常重构，你才能更好、更方便的增加新功能。[/list:u]

[list]3、测试是直接针对需求的（测试就是需求），为什么要编写这个测试呢？这就是因为有了对应的需求（新增的需求，变化的需求等），否则你只需要实施第二步即可，因此TDD让你的目标变得非常明确，不会让你做多余的任何工作。[/list:u]

[list]4、TDD是基于不断的反馈。反馈是XP的四个基本的价值观之一，但是反馈不是XP独有的，在开发过程中充足的反馈是必不可少。无论代码如何改动，只有所有的测试通过，才能证明系统工作正常。这样持续不断的充足的反馈会给开发人员、客户带来足够的自信。[/list:u]

TDD究竟能给我们带来多少好处呢？我觉得有些东西是很好衡量的，有一些就不那么容易衡量。只有你完全投入，才能发现它对你的帮助到底有多大。

[list]1、让你尽快开始工作，而不只停留在“思考”阶段；[/list:u]

[list]2、每次测试的反馈与你的构思之间的距离会越来越小，它能保证你的代码不会偏离你的终点；[/list:u]

[list]3、从最简单的地方开始，从而简化问题、降低风险；[/list:u]

[list]4、Martin所说的“测试感染”，我觉得很有道理，有的人会越来越喜欢TDD，而有的人正好相反；[/list:u]

[list]5、增强信心，每一步你都知道是在解决问题，而不是不知道自己在干些什么，对问题到底有多大帮助。[/list:u]

[list]6、......[/list:u]

从上面我们可以看出，脱离XP，TDD照样可以工作的很好，因此不要因为这只是XP中的一项技术，因为XP而排斥TDD。

不过话又说回来，TDD结合XP会产生更好的效果：

[list]1、XP倡导简单设计，而TDD就是从简单的地方入手，不谋而合；[/list:u]

[list]2、XP中是代码集体拥有，测试当然也是由大家共同维护的。任何人在往代码库中放程序（Check In）前，都应该运行一遍所有的测试；任何人如果发现了一个BUG，都应该立即为这个BUG增加一个测试，而不是等待写那个程序的人来完成；任何人接手其他人的任务，或者修改其他人的代码和设计，改动完以后如果能通过所有测试，就证明他的工作没有破坏原系统。[/list:u]

[list]3、成对编程对TDD的促进作用很明显，上面所说的“两顶帽子”，现在就可以戴在不同人的头上；而且充分的讨论让人思路更开阔，更深的思考，让TDD进行的更加迅速、准确。[/list:u]

而且，TDD不是为了天才而提出来的一项技术，是适合任何水平的开发人员，无非是水平高的、有经验的人迈的步伐大一点，少走一些弯路，走得快一点；水平不够的、经验比较少的人迈的步伐小一点，多走一些弯路，走得慢一点。但是，大家都坚定的相信自己是朝着既定目标在前进，这有点类似于“行进中开火”的道理。

你这样的帖子是介绍性的

不知道要讨论什么

论题，论点，论据？

（转过来）

说说我的这个爬山的比喻。

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

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

这取决于你的步伐。

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

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

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

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

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

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

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

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

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

（从测试版转过来）

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

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使得小蚂蚁误以为自己也能通过小步快跑，把大项目拿下，那就是有害的。

另外，ozzzzzz，我没有说自己是技术大牛。

庄表伟是吗?
我怎么就误以为是小蚂蚁通过你们的预设计可以拿下大项目来?那些小蚂蚁不知道什么是优秀,但是他们是不是应该去学习知道什么是优秀呢?是不是蚂蚁就永远要做蚂蚁呢?
根本问题是个人的素质会绝对的决定一个人的能力,而这个能力又决定一个人的工作成果.但是每一个人在面临其能力极限附近的工作的时候应该采取什么策略呢?是冒险在刀尖上行走,还是先试试深浅,然后小心翼翼的慢慢前进?

是我，而不是我们。

虽然和你的意见不一致，但是我和charon不是一伙的。

我说dlee和potian有点非此即彼的思维方式。现在我发现你也颇有点这个意思。世界上，并不是只有TDD和预设计两种选择。

我说了TDD的坏话，但是你看到我说了预设计的好话吗？

小蚂蚁应该如何成长？跟着高手做项目呀。

如果一个项目，需要这个小蚂蚁负责，而这个项目又是接近小蚂蚁的能力极限的，那么我们只能祈祷，客户允许这个小蚂蚁不断的犯错。这样，如果这个小蚂蚁够聪明，他能够成长得很快。如果客户不愿意付费让人拿自己的项目来试错，那么小蚂蚁就不该负责这个项目。

其实我要表达的观点主要有两个（在文章中已经说的比较清楚）：

1、任何人都可以采用TDD进行开发，无论你是大拿，还是小蚂蚁。

2、TDD脱离XP也能很好的工作。



工作该由谁做，做什么？不是个人能决定的，而且也不是我们讨论的话题。我们关心的是该如何做？正像我说的第一点，谁都可以采用TDD。道理我前面已经说了一大通了。

庄表伟
我们的分歧不是一点,对于TDD的不认同,我认为关键在于你们对于预先设计的渴求和对于小步跑策略的疑惑.
你并不认为预先设计是向charon那样可能简单的实现,但是你的思路却并不让你抛弃他的做法.你说的局部和整体的关系分明让我理解你认为需要一个预先的对局部做好规划的设计,然后才可能解决问题.这在我看来就是预设计,而不是XP的预规划--SYSTEM METAPHOR.
TDD之所以强调先写测试,其实是强调你必须现实的反映出你的设计的要求,这其实就是一个设计.
小蚂蚁可以成长,但是成长也有不同的道路,TDD就是一个好的成长道路,他使你设计的目标更明确,思路的表达更具体,找到漏洞的可能性更大.而且不管是高手也好,菜鸟也好都应该在其可控制的范围内进行工作,也就是都要把步子放小,都需要做有把握的事情.