在我的TDD感悟(二)中,说到了一个TDD的周期不宜太长。不管是红,绿还是重构。每个步骤的步伐小一些会更可控,出现问题定位也更快。那么在“绿”的阶段我们需要注意些什么呢?
速度要快
在这一步里,初学者最容易出现的问题是长时间呆在这个“绿”的环节中,直到一口气完成所需的编码。然后有些人看到是绿的状态,就觉得事情做完了,开始做下一个用例了。如果是红的状态,那就不停的测试,直到绿的状态出现为止。
这种方式的缺点在于:
- 没有后续的重构步骤,代码容易越写越大,不容易定位Bug
- 不考虑代码的可维护性和可扩展性
- 如果在过了一段比较长的时间后,实现了用例,然后再转到重构环节,可能这个时候需要重构的代码量变的比较大了,这个时候重构的工作就变得不是那么的容易了。很多人就会选择跳过重构这一步
因此,“绿”这一步的要点在于:
- 步伐要小,甚至一开始为了验证测试代码是否ok,可以直接类似
return 1;
这种简单的方式,先让状态变为“绿”。 - 如果状态由“绿” -> “红”,那么这种情况必将容易出现在这次的改动里。一次的改动如果是在2~3分钟,代码量不会很多。这个时候通读下代码, 也是会比较容易发现问题,减少了断点调试的次数
实现算法
“绿”的环节中,重要是快速,小步快跑实现功能代码。这个时候代码质量不是首要考虑的事情。所以这个阶段往往会出现一些临时代码,或者写死常量等。这些问题都会在重构的环节中消灭掉。目的只有一个就是:快。
重构和实现算法是在不同的步骤里
把“绿”和“重构”分开, 更有利于大脑串行工作。也让自己更主动的重构,改进代码质量
- 如果不需要重构,那就跳到下一个循环,继续 “红” -> “绿” -> “重构”之旅
- 如果需要重构,那么在现有的代码上,考虑消除重复,提高可读性,提高可扩展性。这个在每个小步骤里来做,让重构的代码量不至于那么大。提高重构的效率,提高代码修改引入bug的修改速度。
最后,对TDD非常熟练后, 可以适当延长“绿”这个过程的时间。比如3~5分钟,但也不要太长,否则还是容易出现上述的一些问题。
坚持小步快跑,我们能得到更多
网友评论