TDD能带我们去哪里？

http://www.blogcn.com/user27/zbw25/blog/6965056.html

书上说得更多的是通过重构来获得相对更优的设计吧，恐怕不能这样孤立地看TDD

我去看了看那篇BLOG，我觉得他的问题不是能不能通过TDD获得好的设计，只是他非要将一个操作强加给一个对象，他感觉到出问题了，因为TDD过程有点不顺畅，甚至觉得没有测试的必要了都，但是他在其它方面找原因，并最终认为合理解决了问题。
我想，谁都不应该认为TDD可以代替开发者的思考和设计过程，如果有人一开始就认为整个系统只需要一个类，即使这个类已经包含了上千行的代码，那么我想谁也帮不了他，别说是一个TDD（这个比喻也许不是很贴切：=）。

本来就打算再写一篇《重构能带我们去哪里？》

基本的结论也是，“重构并不能给你带来好的设计”。

哪怎么才能有好的设计？

不是已经说了吗？

因此，要提高自己的设计能力，最需要花功夫提高的，是理解现实世界，理解需求的能力，只有真正理解了需求，只有真正理解了现实世界的运行，才有可能提高设计的水平。至于其他的，都是辅助的力量，并非根本。

to :庄表伟

      看了你朋友的blog，也许语言沟通有问题，他的有些内容没听懂。他的主要问题是解决“第一个US：用户注册”。
     既然是“用户注册”，那就从最外面开始进来，直接的结论就是mySystem.register(UserData)，然后先对mySystem.register(UserData)进行unit test设计。他最后也发现了这个问题了。这没啥说的.

     TDD最重要的目的是“保障开发无后顾之忧”。==>这句话应该是“足够的单元测试可以保证开发无后顾之忧”。因为即使我不按照TDD进行开发，在开发过程中的某一迭代后，补充单元测试，也可以给我带来前进的信心。

    你所强调的属于“终极目标”，大家都知道掌握需求，将自己的设计更加贴近用户的需求。但是在“如何将自己的设计满足需求”的过程中，TDD提出了一种新的尝试。在TDD的过程中，同样需要设计者对其面对的需求足够的了解，也就是说，你批错了TDD。 坦白说，你朋友并不明白“事情该如何进行”，然后又尝试着使用TDD，最后出现了一些其“很显然”的弯角。

    虽然我不是很喜欢TDD，但是我觉得从你朋友的实践到你的结论，这些都不是TDD的错误。 你的最后结论的正确，不表示你前面的推理过程的正确。

    还有关于“重构”，那只是给你通往美丽天堂的一条路，使用工具方法错误的人显然不会走向天堂，相反可能是天堂的反面。当然“重构”不一定肯定能走向天堂，这其中好多要求的。呵呵～

呵呵
那就是说设计也是一门隐形知识
只可意会，不可言传

要注意修炼内功了

我所说的夸大意思仅仅是为了对firebody的说法表示同意
因为他的朋友的理解已经超出了TDD的本意
TDD是规约设计目标的方法，而不是规约设计结构的方法
所以使用TDD不一定就会使设计变好
我也抠一下

设计是不是能变好，是否使用TDD并不能起决定作用，关键还是看个人的能力，没有TDD之前难道就没有好的设计吗？TDD只是让人更容易得到好的设计。我这么想的。

首先表示同意，但个人认为这些辅助力量正发挥着至关重要的作用，如果没有这些力量的辅助，要提高设计水平是非常困难的事，只有一些特别聪明的人才能很快的提高。而有了辅助力量，使象我这样的普通程序员也可以以较传统思路轻松得多的方式去考虑设计问题。
比如：单元测试、重构，自然还有测试驱动。