fizzbuzz牛津英语树 fizzbuzz( 三 )


TDD
在编码实现方面,我们前面在做方案域设计的时候,已经把程序设计的可测试性很高,所以很自然我们在落地实现的时候,就可以通过打印的方式肉眼调试,随着我们代码越来越多,每写完一段新的代码块,应该就考虑把所有的都打印出来看看有没有变化,这就叫回归 。而用肉眼看的方式做人肉回归实在是效率太低,频率也不会高 。我们需要把肉眼看转换为自动化的方式,这就是自动化测试 。既然我们可以通过自动化测试的方式来进行回归,校验的输入输出在开始之前也已经分析清楚了,那不妨在开始写代码之前就先把测试写出来,于是就得到了TDD 。
很多人抱怨TDD学不会,其实据我观察,大部分学生之所以不能使用TDD的方式写代码,核心原因还是不会把程序从输入输出角度进行拆解 。一旦拆解开了,后面的就简单了 。
我也发现在编程的时候,很多问题不是智力问题,fizzbuzz读音,而是心理问题 。
我看见很多同学很喜欢一口气写一大堆代码,然后慢慢调试 。如果他们真的有过人的才能,可以一次性写对,我觉得也没什么 。然而事实是python并不能,反而浪费很多时间 。
究其原因还是游戏不会改程序,所以想着一次性写好,为什么这么说呢?你会发现他们基本上不考虑输入输出的具体格式,脑子里有一个模模糊糊的感觉,就开始写实现了,到实现完为止,程序都执行不起来,执行起来之后,因为函数已经很长了,中间出了错误,准备数据也不好准备,于是要改半天,于是更害怕执行了,于是更想一次性写好,函数就更长了 。
由于不会思考输入输出,也就不会拆子函数,因为大的都没好好想,小的子函数就更别说了,函数的输入输出没有分析清楚,拆了子函数因为作用域的问题没想清楚,所以想一个函数写完 。或者乱拆了子函数,然后就开始各种加全局变量 。总之就是因为不敢改,所以把犯错的范围越积越大,故障点越垒越多 。越是这样就越不敢执行 。因为一执行就更肯定是报错的,一旦查错呢,因为代码太长又害怕查错查的把写代码的思路忘了,于是又强化了一次性写完的行为 。
整个这套我们称之为基于本能的行为模式并不是一个理性的结果,反而是一个感性的结果 。所以我们教的这些实践并不是单纯的解决智力问题,相当多的部分也是在解决心理问题 。
与这套基于本能的行为模式相反,我们教的这套以TDD思想为核心的行为模式,有意识把代码拆成小块,自然可以小步试错,可以小块验证,也就可以保证实现的过程中即便出了问题也可以快速的定位 。哪怕不写测试,你打印也比别人调试快,单步调试也知道每一块干什么,fizzbuzz,另一块跟这个不相关,就可以快速跳过,到了你关心的部分,分析过输入输出,也就能更快速的知道哪里错了 。所以讲解不能从输入输出角度进行思考是人们没有办法写出高质量程序的一个原因 。
而每一块的编码实现我们还是会再分任务,以本问题单个数的转换为例,接口是非常清楚的——输入是个整数,输出是个字符串 。
但是你实现的过程要分几步 。
我要先实现可以被3整除的,再实现可以被5整除的,最后实现可以被3和5整除的,这算是一个驱动的意思 。从简单的入手,然后再往复杂的去写 。很多人可能会java觉得比较无聊 。但如果你测试的人足够多,你会发现很多人哪怕是在这样一个无聊的题上,也会把自己坑进去 。举个例子我们第3步:可以被3和5整除 。当我们实现的时候,我们if里那个表达式模3模5在上还是在下 。每次我都会故意写在下面问有没有问题,fizzbuzz牛津英语树,如下图所示:

相关经验推荐