记一种TDD方式：红绿憋，红绿再憋

前段时间看到微博上看到一则冷笑话，讲的是如何画马：



我看到前半截的时候，我还真的在纸上用笔一点点的画，但是当我看到最后一步的时候，WHAT THE FUCK！！！

这种方式的“画马”不仅仅存在在画画上，也存在在我们平常的工作中，比如如何使用TDD上。

和其他人pair的过程中，我发现很多人对于TDD的理解就是简单的“先写测试”。

他们知道TDD，于是他们先写一个测试，然后眼睛对着电脑，开始憋，憋，憋。

憋了十多二十分钟，磕磕盼盼的敲了实现代码。

绿了，通过了，谢天谢地！

再然后，写下一个测试，然后又开始憋，憋，憋。

憋了十多二十分钟，想了下，把已有的实现删了，再重新整一个。

好一会儿，又弄出来了。

第三个测试，开始，憋，憋，憋。

弄不出来了，WHAT THE FUCK！！！

所以，传统的TDD Lifecycle从“红绿重构、红绿再重构”变成了“红绿憋、红绿再憋”

如果你发现你用这样的方式进行TDD，那你可以检查两件事情你有没有做好：

第一，有没有Tasking?

第二，有没有选择最简单的Task先做？

为什么要Tasking？

Tasking就是将一个原本的较大的需求，分解成一个个很小的需求。实现一个大的需求，往往需要比较长的时间。但是如果实现一个很小的需求，小的不能再小的需求时，往往是非常容易的。通过这样的方式，可以缩短我们红绿重构的周期，得到快速的反馈。如果Tasking后的需求粒度不够小，我们就会进入“红绿憋”的循环。

这里需要注意的是Tasking不是实现过程的拆分，而是需求的拆分。

为什么要选择最简单的Task先做？

有人说，对啊，我Tasking了啊！我也TDD了啊！我还是在憋啊！

这时候，问题往往出在你选择什么样的Task作为当前的Task。一般来说，简单的Task对应简单的实现，复杂的Task对应复杂的实现。并且复杂的Task往往涵盖了简单的Task。所以，选择简单的Task，后实现复杂的Task，已有的简单Task的实现将有助于让复杂的Task实现变得更容易。反之，如果首先实现了复杂的Task，那么你的代码可能将会陷入某种不必要的抽象，再实现其他的Task时，可能就需要重写。

于是，问题变成了，什么是“简单”的Task呢？什么又是“最简单“的Task呢？

一言蔽之，就是你能用最短时间实现的Task。

更多关于如何选择最简单的Task，以及更多思考，呕血推荐阅读企业级软件开发大师Uncle Bob提出的TPP（Transform Priority Premise）。