[探讨]通过实例再讨论TDD

最后说说你的这个测试失败的例子，我不像后山那样认为这样的做法是错误的。

这是典型的用空间换时间的方法，很多查表法，都是这样做的。

关键问题是，通过常规的重构方式，我们也许可以从递归实现，重构成循环实现，但是我们很难将查表实现重构成循环实现。也很难将查表实现重构成前面的那种数学公式实现。

这就是TDD+重构的不足之处。这两个加起来，也不足以保证你走出“阴暗的山谷”。所以还要加上“设计模式”。作为设计改进时的探索指南。

但是仅仅有设计模式，也还是不够的，这个问题，我接下来再详细说吧。

握手！

to Trustno1:

我不是否定你的这种算法，而是从tdd的角度来说的。

其实存放在表中预先算好的数值，这些数值也是通过fib算法算出来的，计算机是不可能自动预设这些值的。我们现在要做得是通过某种fib算法来得到计算结果，是如何得到这些值（接口是fib）。所以我说按照你的tdd步骤，显然过程并没有结束。

我想大家应该明白性能优化和重构是有区别的，而TDD基本不会和性能优化直接挂钩。作为算法不仅仅只是要考虑到数学解决，还需要考虑计算机的特殊计算方式。而正是由于cpu计算的特殊性，使很多算法的优化变得不可能采取一种大跨步的形式，因为这样作太昂贵了。一般的做法是先找到数学的解决方法，然后把这个数学解决使用计算机的语言进行翻译。而后进行性能测试找出瓶颈进行针对性的优化。而这个瓶颈你很难在不经过测试的情况下找到，而且如果对所有的部分都进行优化，往往未必会带来真正的性能提升。很多时候现代编译器已经把你的程序优化的够好了。同时优化和重构一样都是一种置后的设计，其意图显然不是大跨步的。

agree!FFT算法从数学上来说肯定要比FT快，但是具体把FFT实现出来，就会有很多考究的地方。从FT到FFT，可以说是跨大步式的。但这不过是数学上的问题，而不是具体的实现问题。

TDD与算法有什么直接关系?

TDD是先确认问题的边界，确认需要解决的问题，明确问题如何算被解决，然后再进行设计具体解决问题。
似乎很多时候明确问题边界是和解决具体问题难以具体划清的，所以有了重构这一过程让整个过程重复迭代下去。首先确定一些基本问题，明确问题如何算被解决，具体设计解决，再深入提出问题...。
这里确实有一个系统思考的要求，先解决哪些问题，再解决哪些问题，前后问题之间具有关联性，相互影响，这可以被认为是一种总体设计。

算法是解决一些通用问题的方法。当TDD遇到算法的时候，就有一个这样的问题，如何去定义问题。不同的人对同一的问题有不同的看法，会有不同的问题拆分，TDD整个迭代过程也会截然不同，产生的结果也会不同。

总的来说，TDD是解决问题的一种方式，算法是解决一些通用问题的具体方法。

To 庄表伟:

  很敬佩你的抛TDD引出算法的手法.
  从以下各位大牛的回复已经得以验证,并学到很多,各位不应该学习IT,我想说的是有更好的职业等着你们.
  但是,我的看法是TDD只是一种实施的手段,非常接近真理的一种解释方式,很好,非常的好.如果涉及太多的话题,似乎跑题了,毕竟TDD真的很单纯,大家不要太刻意地去将它和什么XP,更甚至算法扯到一块.
  是XP也好,CMM也罢,实施的过程有差异,但谁说TDD,持续集成等概念就一定隶属于XP,呵呵,真的是没有任何直接的联系,只能说以上的概念在与XP结合的时候是最佳的,或者说组合的最好,我喜欢ozzzzzz的解释,因为听起来似乎更接近对真理的解释.:)

"这一步推出来之后，我真的很佩服自己的！"
庄兄，我也佩服你，你不去搞数学太可惜了。这个附件是费波那契数列的母函数推算法，供你参考。
PS:费波那契数列经常应用于优选法，与0.618优选法不同之处在于：它事先已确定试验次数并且参数为整数的时候。学习一些特殊数列的特性，对测试用例设计是很有帮助的。