经验啦

  1. 首页 > 生活百科 > >

fizzbuzz牛津英语树 fizzbuzz( 四 )

生活百科


fizzbuzz牛津英语树 fizzbuzz

文章插图
每次都会有人意识不到 。这么简单的题目都会被绕晕，到底要多有自信，fizzbuzz问题，才会觉得复杂的需求不会出错呢？所以还是老老实实的给自己加测试防护网吧 。测试一个很重要的原则，是防止低级错误，而不是恶意欺骗 。
先确认需求，再实现，需求以测试的形式写出来，然后再去实现，这就是TDD了 。如果实现的时候只java需要关注其中一种可能性，这样思维负担比较轻 。如果你脑力强劲，觉得步子大一点没事，你就步子大一点，我是没有讲解此等自信 。有些人问我，TDD的时候测试有没有阶段性，测试是否有要分批写？我大概会分三批：
第一批测试只有一个测试，意义是：定义输入输出，确定函数在哪 。第二批测试的意义是：建立主干框架，把程序的主干走通 。然后再写第三批测试，把各种分支和异常都考虑到 。这样写出来的程序就是一个比较健壮的程序 。反过来看，当你时间不够的时候 。你要减的测试是哪个？肯定是第三批测试，不是整组干掉，而是在这组当中减少量 。有很多人会说自己没有时间写测试，或者说测试很浪费时间 。但是如果你打开代码的时候，发现前两组测试都不存在，就很说不过去了，因为前两组几乎不花什么时间 。而且如果做得好还会提高效率，减少时间花费 。一个最简单的道理，当我有一天出了bug，我能以多快的速度建立一个可运行的程序现场，fizzbuzz java，以多短的周期反复重现这个bug，并且对新解决方案进行尝试，决定了修bug的速度 。前两组测试完全可以为这个场景服务，而这个场景不完全发生在测试测出来bug，在我们日常写代码的时候，我们不能保证我们写的代码是一次就能写对的，那么在没有写对之前就等于代码中存在了bug，也是要反复调试的，那这个对实验的周期时间的要求是一样的 。有那个调试的功夫，直接看测试不是一样吗？
过度设计
到此为止，我们写出来带的代码如下所示：
fizzbuzz牛津英语树 fizzbuzz

文章插图
实现并不复杂，仔细看看这代码还可以，够用，不难懂，那就行了，我们就先不请英语重构登场了 。天下设计都讲究一个不要过度设计，软件设计也不例外，做到这里是很好懂的，那我们也不要画蛇添足 。
很多人一看到可能的扩展点，就想了一大堆可能的需求，再有个9呢？或者是所有的素数，比如11啊，13啊……
这方面我们要有耐心一点，比起可能降临的扩展给我们带来的困扰，我们自己乱添加的扩展机制更可能会坑死自己 。
有个段子是这么讲的，有个人请来了一个新手，一个老手，一个高手，给他们布置了一个任务，穿过一片农田到对面的房子去，这片农田就隐喻我们的代码，问要多长时间 。
新手看了一眼距离说估计15分钟就能过去 。老手看了一眼，说要半天 。高手也看了一眼，说15分钟 。新手进到农田，不停的掉到坑里，踩爆了几个雷，最后被埋在田里了 。老手小心翼翼，过程中填了几个坑，排了几个雷，花了半天的时间，终于到达了房子 。发现高手早就已经在那儿等了他很久了 。老手不解，问为什么你可以这么快？你怎么干掉那些雷的？高手说，因为从一开始我就没有埋雷 。
这个段子告诉我们，程序员自己给自己埋的雷往往会成为未来的负担，好的程序员会尽量少的给自己埋雷 。这所谓的雷，可能一开始就是一个精心设计的机制 。
不要以为这只是一个段子，在曾经工作的一个项目上，我接了一个特别简单的任务，以为一会儿就能做完，打开代码之后，我发现之前的代码竟然是用反射机制设计的一个极其复杂的扩展机制 。为了搞懂这个机制，我竟然花了一个礼拜 。最后我觉得这个机制实在不利于扩展，我现在对它知根知底，为了防止后人再进这个坑，我就把它删掉了 。删之前我就很好奇，这么复杂的机制，有没有起到易于扩展的作用啊，于是我就打开版本控制的历史记录，我发现他是两年前添加的，在过去的两年之中，从来没有进行过一次扩展，直到今天被我删掉 。想想也对，这么复杂的代码，别人读都读不懂，为什么会选择在这儿扩展呢？所以不要盲目追求易于扩展的设计，绝大多数时候刚刚好的设计才是最好的设计 。

相关经验推荐


上一篇：好孩子要诚实简谱左右手 好孩子要诚实简谱

下一篇：过期咖啡豆的妙用 过期咖啡