我的TDD感悟（三）--TDD的“绿”

在我的TDD感悟（二）中，说到了一个TDD的周期不宜太长。不管是红，绿还是重构。每个步骤的步伐小一些会更可控，出现问题定位也更快。那么在“绿”的阶段我们需要注意些什么呢？

速度要快

在这一步里，初学者最容易出现的问题是长时间呆在这个“绿”的环节中，直到一口气完成所需的编码。然后有些人看到是绿的状态，就觉得事情做完了，开始做下一个用例了。如果是红的状态，那就不停的测试，直到绿的状态出现为止。

这种方式的缺点在于：

• 没有后续的重构步骤，代码容易越写越大，不容易定位Bug
• 不考虑代码的可维护性和可扩展性
• 如果在过了一段比较长的时间后，实现了用例，然后再转到重构环节，可能这个时候需要重构的代码量变的比较大了，这个时候重构的工作就变得不是那么的容易了。很多人就会选择跳过重构这一步

因此，“绿”这一步的要点在于：

• 步伐要小，甚至一开始为了验证测试代码是否ok，可以直接类似return 1; 这种简单的方式，先让状态变为“绿”。
• 如果状态由“绿” -> “红”,那么这种情况必将容易出现在这次的改动里。一次的改动如果是在2~3分钟，代码量不会很多。这个时候通读下代码， 也是会比较容易发现问题，减少了断点调试的次数

实现算法

“绿”的环节中，重要是快速，小步快跑实现功能代码。这个时候代码质量不是首要考虑的事情。所以这个阶段往往会出现一些临时代码，或者写死常量等。这些问题都会在重构的环节中消灭掉。目的只有一个就是：快。

重构和实现算法是在不同的步骤里

把“绿”和“重构”分开， 更有利于大脑串行工作。也让自己更主动的重构，改进代码质量

• 如果不需要重构，那就跳到下一个循环，继续 “红” -> “绿” -> “重构”之旅
• 如果需要重构，那么在现有的代码上，考虑消除重复，提高可读性，提高可扩展性。这个在每个小步骤里来做，让重构的代码量不至于那么大。提高重构的效率，提高代码修改引入bug的修改速度。

最后，对TDD非常熟练后， 可以适当延长“绿”这个过程的时间。比如3~5分钟，但也不要太长，否则还是容易出现上述的一些问题。

坚持小步快跑，我们能得到更多