1. 原始的测试驱动开发模式只是起点

一直遵循原始的测试驱动开发模式是不现实的。这有两个原因。

一是开发者自身的愿望。

原始的模式在头两个项目时还有趣，但要是一直这样做，就没意思了。拿小孩走路举个例子。他不喜欢规规矩矩走，一旦起跑、加速、刹车、转弯成为本能，他就会跑起来，追逐视野里可见的任何东西。同样地，开发者反复练习怎么提炼小“积木”，怎么加上合适的接口，再组合它们成大“积木”。一旦这些技能变得娴熟，他就再也不满足“一步一停一校验”的步子了。理所当然地，就想要眼睛看得尽量远，步子跨得尽量远。

二是项目实践的需要。

不管怎么样，项目计划还是要做，目标完成时间还是要给，不能说“做到哪天算哪天”，因为这样说的唯一结果就是加班拼命干。如果结果是这样的弹性，那还不如走老路。所以快速估计一个合理时间，对开发者来说，仍然是刚需。

从原始模式，过渡升级到纸上细节设计，是一个必然、也是必须的结果。

2. 纸上的细节设计是怎样的

原始的模式是“边设计边实现”，而纸上细节设计是一个单独的设计阶段，预置在“边设计边实现”阶段之前。这时仅提炼“积木”，考虑按什么顺序对它们单元测试，而不去实际实现、测试它。开发者要在纸上、在脑子里驱动“积木”，尝试组合它，检验接口是否好用，是否简洁。如果答案是否，就要快速做出变更。这样从小到大迭代下去，直到整个房子的设计图显现出来。

在这个过程中，识别出的“积木”被串起，可能的复杂点被分解，可能的难点、风险都被重点标注。

哪个耗时间，要多分配资源，哪个可能过不去，要先做，都摆在桌上了。需要多少时间，按什么顺序去做，也都放在肚子里，踏实了。

3. 纸上设计需要洞察力

测试驱动开发就是一个搭“积木”的过程。“积木”有很多种，每种“积木”还有不同的用法。用术语说就是，模式有很多种，每种模式还有不同的使用方式。不同方式意味着，模式有“形”还有“神”，“神”一个，“形”可以是好多个。用它的“形”，更理解它的“神”。不能光是生搬硬套，要能变通。

能不能做好纸上设计，取决于开发者的洞察力，就是能不能识别出合适的“积木”，能不能找到合适的方式组合“积木”。

4. 持续练习使用模式

要锻炼这种洞察力，必不可少要做的是持续练习。

要真正学会一个模式，不能只是编一个虚构的例子演示它，或者写一篇文章总结它，而是要在当前正在做的、真正的项目中，用它一次。“百闻不如一用”！对模式每一次使用，都是将它更深地融入自己的脑子。在相应的需要激发时，它会从潜意识里跳出来。

还有，为了在练习的路上不跑偏，要遵循两个法则：
一，要永远尊重系统本身的逻辑，寻找符合系统实际、而非个人愿望的模式；
二，一而再、再而三地使用一个模式，除非它无效。如果是这样，再回去第一条。

相关链接

测试驱动开发与设计模式 - 从入门到精通
测试驱动开发与设计模式 - C++书籍及网站
测试驱动开发与设计模式 - 开发实例（一）DVR-POS库
测试驱动开发与设计模式 - 开发实例（二）JSON过滤库
测试驱动开发与设计模式 - 适应并改进软件设计过程
测试驱动开发与设计模式 - 让“理想结构”与“快速变更”并行
测试驱动开发与设计模式 - 提速 — 在纸上做细节设计