• 2010-05-16

    争论TDD

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/63646898.html

    咨询的过程中,经常会与人讨论TDD。初时,我会很耐心的跟人解释TDD的种种好处,试图让他们能够皈依TDD,结果总不尽如人意,争论者总是可以抛出一些新的观点,逼迫着我重新认识TDD,甚至最低落时,我会怀疑TDD是不是真的有效。

    通过反思,我发现,所有和我们直接在一起写代码的人,都没有质疑过TDD,而且一旦真正进入节奏,便乐此不疲。而与我们争论的人中,为数不少的对于TDD,或是浅尝辄止,或是压根没有碰过。换句话说,他们的问题都是“想”出来的。真正做起来是什么样子,他们自己也不知道。

    网上的某些讨论也有着这种倾向,想出一个问题吓唬自己,还试图让别人认同自己,比如这个。对于这些人,着实没有必要浪费口舌。连电都没有,我怎么给你解释灯的都好处都是白搭的。况且,欲加之罪,何患无辞!

    争论的人里面,有些人是实践过的,但是,结果很糟糕。我们的沟通常常是这样:
    我:你怎么理解TDD?
    对方:不就是先写测试后写代码吗?

    原来TDD也可以没有重构啊!打开他们的测试,几屏都翻不完的测试,让人目眩神晕。
    我:这么长的测试你怎么保证它的正确性呢?
    对方:哦?没有想过。

    测试错了,但无法证明究竟是测试写错了,还是代码写错了,我合作过的不少团队都出现过这样的情况。

    问题到底出在哪?我想了很久。

    通过与不同的团队的合作,我逐渐意识到,这些团队欠缺的根本不是TDD,他们压根不知道如何写好代码。对于这些人而言,即便他们知道TDD有着“红——绿——重构”的节奏,也不知道代码应该重构成什么样子。在他们眼里,重构和不重构,没有任何差别。

    在他们原有的认识中,写代码就是完成功能。在这样的背景下,很多人每天都忙碌于在原有的代码上堆叠更多的代码。在合作团队里,有不少人工作才一两年,更有甚者,是工作后才开始写代码,他们对于写代码的认知仅仅停留在照猫画虎的阶段,甚至连最基本的编程技巧都还不了解。更可怕的是,他们的代码风格还在不断被后来者模仿。对于这些人来说,如果不改变他们对代码的认知,指望“所谓的TDD”改变一切无异于痴人说梦。

    想TDD吗?先学学怎么写好代码吧!

     

    分享到:

    历史上的今天:

    引用地址:

    评论

  • 在下新手, 不过个人感觉TDD的好处在于
    1.下手之前更清楚自己要干什么
    2.在重构的过程中有了一层保险, 不至于改了代码, 引发了其他地方的bug
  • 他们压根不知道如何写好代码
    -------------
    深有同感!一个团队里有工作一两年的新手是正常的,比较恐怖的是,他们不知道正确的方向在哪。当他们在工作年限上成为老手,而编程功力却停留在一两年的新手水平时,团队在他们在支配下,很可能被带入万劫不复的境地。
  • gigix的这句话看着特解气:

    别人告诉你怎么做可行,你不信
    别人说你去试试看,你不试
    那你想怎样?
    想找个人帮你把项目带了算了?帮不帮你领工资?