eXile 的专栏

# re: 测试驱动开发（ＴＤＤ）的顿悟 2008-01-23 21:38 neoragex2002

用TDD做设计的人是爽了，写测试一句话，多简单。可想想你的团队呢？他们的创造热情和成就感在哪里？他们的士气在哪里？就几个空而无物的测试用例？任何方法学正面地作用在主动积极的人才会起作用。  回复  更多评论   

# re: 测试驱动开发（ＴＤＤ）的顿悟 2008-01-23 21:49 eXile

@neoragex2002
这个老兄还是对ＴＤＤ有一个起码的了解以后，再来讨论这个问题吧。
  回复  更多评论   

# re: 测试驱动开发（ＴＤＤ）的顿悟 2008-01-23 21:50 eXile

FROM JAVAEYE:
对于大多数的中国的软件开发团队来说，难以实现敏捷的最重要问题是人的素质问题。一个敏捷团队要求每个成员都有较好的OOP和OOD的能力。.......实现敏捷是一个渐进的过程。构造一个在技术上有敏捷能力的团队有两种方法，一是用足够的钱去招聘有足够能力的程序员(大部分企业没有那么多钱)。二是将现有不符合敏捷技术要求的程序员培养为合格的敏捷工作者。而在培养的路上，单元测试正是一个很好的驱动方式和实践平台。  回复  更多评论   

# re: 测试驱动开发（ＴＤＤ）的顿悟 2008-01-23 21:52 eXile

FROM JAVAEYE
就是因为“文档/注释”在代码的频繁修改中太容易过时，而且也太容易为人所忘记，所以在我的实践中不写文档，我的文档就是我的“代码+单元测试”，想知道我的想法，看“代码+单元测试”就行了，没有任何形式的文档比“代码+单元测试”更能体现我的设计
- 我们的文档是十分简短和松散的，一般放在wiki上，起到story guide的作用，但如上所说，随着开发很快就过时了，从中你能找到设计的逐步迭代，但它和最终的产品是有差别的
- 对于我们开发工程师来讲，“代码+单元测试”就是我们的文档，对于客户来讲，有专门的产品文档供他们使用，但是那是由文档工程师写的   回复  更多评论   

# re: 测试驱动开发（ＴＤＤ）的顿悟 2008-01-23 21:53 eXile

FROM JAVAEYE:
阅读有些test case只能让你云里雾里，而阅读有些则让你马上就知道这段代码的用途。其实找并不是这些test case写的有水平差别，而往往是有针对问题角度的差别。而进一步，你会发现阅读这些test case如果按照一定顺序，就会从最初的动机到最终的实现细节都有一个清晰的理解，而如果我们能够在写这些test case的时候就标注出这个理解顺序，将是十分核算的。而实际上很多时候我们书写的顺序就是最终我们适于阅读理解的顺序。
  回复  更多评论   

# re: 测试驱动开发（ＴＤＤ）的顿悟 2008-01-23 21:58 eXile

JAVAEYE上真是有不少明言警句啊, 看来都是高手。。。  回复  更多评论   

# re: 测试驱动开发（ＴＤＤ）的顿悟 2008-01-23 22:01 eXile

FROM JAVAEYE:
就说注释好了，比较一下：
1。可运行的代码
2。测试代码的单元测试和其他测试
3。注释

这个重要性应该是向下递减的。没有1，其他都没有意义了。没有2，就没有一种可执行、可重复的方法来验证1的正确性。

至于注释，对于程序的功能、正确性和可靠性，对于客户来说是没有任何意义的，所以除非有特殊的理由，我们才去写注释。

一般来说，坚持写注释的人最重要的观点是便于自己或后来者理解代码，减小程序维护和变更的成本。这个我们当然喜欢，但是要注意几点：
1。注释到底是不是最好的工具来加快和精确理解
2。达到这样的目的需要多少成本

第一点，首先绝大多数注释是细节程度上的，基本上和代码本身处于同一层次，因此我们需要看一看代码本身是否比注释更有权利。
注释的目的基本上是为了说明
1：代码实现中的权衡
2。代码本身的目的
3：别的代码使用该代码的方法

以Java举例，注释包括包注释、类注释和方法注释。在99%的情况下，我认为只有包注释和类注释才有意义，因为一个包和
类只有自己的名字来解释自己的含义，如果是一个简单的类，譬如说是Rectangle，当然这个名字已经说明了一切。但很多时候，
一个类里面包含很多方法，很难简单地用一个类名字来描述整个类的意图和作用这个时候，这个时候代码本身是不足的，需要类注释的。

对于方法层次上的注释，除非你这个方法用了非常复杂的算法，那么我们最先关注的是它的目的，这个目的用方法的名字就足够了，
如果你认为它有三个目的，或者有几个阶段，那你必须重构，直到达到这个目标。这里代码比注释的好处是能够优化代码本身的结构，
易于重用和新变化，没有同步的成本，更重要的是它是可执行的。

有的时候，例如内部实现是错误的，我们需要修改代码，这个时候我们也需要理解这个代码地实现方式，但我认为一旦达到了上面的要求，对一个程序员来讲，代码更精确、更简单地能够被理解，而不是注释，除非注释逐行解释代码地实现。

至于别的代码如何来使用你自己的代码，我不由得回忆起当初学习delphi地经历，在我使用一段delphi以后，我很多时候都是凭自己对delphi函数命名的习惯的猜测去调用一个个函数，而不是依靠delphi地API文档和delphi源代码里面的注释（实际上非常少），真的无法理解就去看源代码。而对于一些我完全是初学的类或者函数，我的做法首先是去寻找范例代码理解函数调用的顺序，至于这种理解是否正确
最终取决于我自己的不断测试。对于一些复杂的方法，我会在基本已经理解，并且能够使用的情况下再去看是否还有别的什么"诀窍",后门等等。因此，在这方面单元测试无疑比注释更有用，但是如果一个方法确实比较复杂，并且不同地类和函数之间有一定的依赖关系，我们需要专门的API文档，注释根本做不到这一点。

第二点，注释的成本。注释无法验证，注释不能执行。因此，注释必须完全通过手工来进行维护，当一个类被重构为一个类层次，
当一个方法被抽取成两个方法，当一个类的某些方法被移到另一个类，一个类地实现被改变（接口不变）的时候我们都必须手工去维护
这些东西，并且无法知道我们的注释到底是不是正确揭示了这个类、方法的意图和实现思路。这个成本是非常高的，特别是当我们
知道注释既不能为客户提高更多的价值，也不会对其他程序员理解代码有多大的帮助。当然，如果我们有足够的人力、物力愿意干这样的活，有些时候也会稍微有点帮助。
  回复  更多评论   

# re: 测试驱动开发（ＴＤＤ）的顿悟 2008-01-23 22:02 eXile

FROM JAVAEYE:
实际上过多的注释妨碍了重构的进行，如果你想让代码僵化那么就写大量的注释好了，越多越好，甚至注释:代码=10:1。重构的结果往往是删除掉大量的注释，因为它们或者已经不适合代码当前的结构，或者已经不再需要，因为代码的结构已经非常清晰了。而且我并不知道是否还有可能进行下一次重构，那么我写太多的注释是不是很有可能是在做无用功？我其实只要写很少量的注释就足够了。
  回复  更多评论   

# re: 测试驱动开发（ＴＤＤ）的顿悟 2008-01-23 22:02 eXile

FROM JAVAEYE:
很多大公司的代码都没有任何注释，很多大师写代码也没有注释（看看junit就知道了，大家可能不知道这个东西是两个大师在飞机上试验结对编程的副产品）。原因在于他们根本就不能容忍任何注释造成的味道。
  回复  更多评论   

# re: 测试驱动开发（ＴＤＤ）的顿悟 2008-01-23 22:35 eXile

FROM JAVAEYE:
注释与文档的本质，是为了便于软件的开发和维护，而不是在一道一道的工序之间作为“交接班”的说明
  回复  更多评论   

# re: 测试驱动开发（ＴＤＤ）的顿悟 2008-01-24 08:08 Enoch

测试驱动开发(TEST DRIVER DEVELOP, TDD)是以测试为驱动力，进行开发，是一种开发方法。实际上也是极限编程(Extreme Programming, EP)的一个重要特点，TDD不断的测试推动代码的开发，既简化了代码，又保证了软件质量。
使用测试驱动开发(TDD)就是通过编写代码的测试用例，对其功能的分解、使用过程、接口都进行了设计，以满足软件需求，这样使得代码的设计更符合后期开发的需求。
测试驱动开发(TDD)开发通常需要明确要完成的功能，快速实现功能的测试用例，完成对代码进行重构，测试完成所有功能的开发。这里要求测试的完全隔离，不同代码的测试不应该存在耦合。 测试驱动开发(TDD)从某种意义上说是单元测试(Unit Test, UT)置于软件过程的中心地位。
  回复  更多评论