关于拒绝测试驱动开发(NoTDD)

今天在reddit看到微软某大牛的博客(https://blogs.msdn.microsoft.com/ericgu/2017/06/22/notdd/),说到拒绝TDD(测试驱动开发,下文统一使用TDD)的事情。我很有感触。感兴趣的可以看看原文,我大概总结一下原文的意思(TL;DR):1、大多数TTD做的好的,都是设计和重构牛逼的;2、如果TDD的第三步(重构)去掉,剩下的只有一堆耦合很高的测试,写测试耗时很长,测试很难写。所以新手在学习编程时,学会设计和重构才是最重要的,而设计和重构是通过经验获得的,没有很死的规则。

下面有个很有意思的评论,说现在只要有人反对TDD的思想,别人就会鄙视他/她。那些TDD的推崇者,说TDD做不好的,是“没有按照正确的方式”来做。于是团队里某个TDD拥护者想给其他人展示“正确的方式”:写了一个小程序,包含300个测试;程序到了QA,几天内发现90个bug;都是典型的UI bug;修复前两个bug花了三天,因为很多测试要重写……

上面的例子有些夸张,不知道是否属实。我对TDD有大概的认识,不过向来不感冒。大概是因为我对于编程的理解,和TDD有本质的不同。TDD要求测试优先,我不知道有没有人在实践中,会先把测试写出来,再去写代码。这个是我不能理解的。如果要写测试,必然是要测试的东西都设计好了,接口成形了。实际上,我们往往在实现的过程中,才可以逐渐把接口抽象出来。也就是说,写程序的过程,是一个重构的过程,重要的是写出一些代码来,才有的重构,才有的测试。

程序的设计是需要重构的,一开始没有人能把所有细节想清楚,往往一开始是不管设计的,只要写出来一个能够用的程序,可能设计很糟糕,但是至少有个重构的对象,剩下的就是在不改变功能的情况下,来对程序进行各种变换修改了。作家写作也是一样的,先不管他,把能想到的都写出来,然后再调整、修改、润色,这和写程序一模一样。

不知道大家看到大触绘画没有,或者雕刻家雕刻,这些都有个共同的特点,就是一开始只是画个大概和轮廓,然后再一遍一遍地雕琢细节。我认为写程序本质上和画画、雕刻、写作等艺术创作的过程是一样,你有个灵感,写一些东西,重构一下,再重构一下,直到你认为成形了。唯一不一样的,是程序的有些部分需要实际运行才能确认是否正确,我想这才是测试的价值:你对于某一部分没有信心,所以写个测试来确保这块能够正常运行,通常这部分都是和外部系统交互的。

把测试提到最重要的部分,用测试来保证程序的正确性,是本末倒置的表现,也是一种教条主义。就像所谓各种敏捷的方法论一样,虽然有一定的价值,然而按照全部规则来做的,无疑会出现各种问题。团队都是不一样的,敏捷也要理解精髓,自定义实践,而不是拿别人总结的规则来生搬硬套。

posted @ 2017-07-03 10:58 Leading 阅读(...) 评论(...) 编辑 收藏