我已经会了ABC，为什么还要学XYZ？

不学TDD我也可以解决所有的问题，你看Linux就不是用TDD设计实现出来的，那我为什么还要学TDD呢？

在做公司内部的面向对象训练营（OOBootCamp，一个讲OO和TDD的内部培训），每次讲到TDD的时候，都会被问到类似的问题。这种问题在我们的身边其实还有很多，例如我已经会了面向对象编程，为什么还要学函数式编程？我已经会了java，为什么还要学其他语言？……我把这种问题统一称为：我已经会了ABC，为什么还要学XYZ类问题。

而对于这类问题，我的解答也很简单，只要一根筷子就够了：）

我的筷子定理

还拿开头的TDD为例，一般我们大多数人习惯的方式是遇到问题后（例如实现一个计算前n位斐波那契数的函数），采用的是自上而下的设计实现方式，就是先想一个解决方案(例如递归啊什么的)，然后写代码实现，这很自然是吧，相信大多数人也是这么做得。而TDD所使用的方式是自下而上的设计实现方式，就是先快速解决n是1的情况，再快速解决n是2的情况，以此类推，通过不断地“红-绿-重构”来驱动实现的一步步演进同时驱动出好的设计。

乍一看TDD所使用的方式有点古怪，而且这个思路的转换对于大多数人都很难，难到让人本能的就想抗拒。所以才会有了这个问题：既然自上而下的方式已经可以解决问题了，为什么还要去自讨苦吃地去学习TDD自下而上的方式呢？

看来……是时候掏出我的筷子了…… (▭-▭)✧

如果说解决一个具体问题的过程，可以类比成寻找一根筷子平衡点的过程。

传统的自上而下的设计实现方式就像从左向右寻找筷子的平衡点。

而TDD中所描述的自下而上的设计实现方式则像是从右向左寻找筷子的平衡点。

两种方式虽然方向不同，但目标是相同的，自然也没有好坏之分。

既然都可以做到,为什么我还需要学两种不同的方式呢？

答案很简单：因为你会的越多，选择才会越多，也才有可能融会贯通，突破极限，达到一个更高的境界。例如，在找筷子平衡点这个问题上，就可以通过结合这两种不同的方式让整个过程变得更快，且更加容易（我闺女都能轻易做到）。而面对复杂的软件问题时，知识越多，视角越多，同样也可以帮我们从不同方向快速的逼近真正的目标。