很多人在学习TDD的时候，最被经常教导的就是红，绿，重构。所以很多程序员接到需求后，看完需求，直接就开始红绿之旅了。
一般而言，设计文档是概要性描述，好的设计文档条理性会好一点， 方便程序做需求分析和梳理。但是也有质量一般的文档，通篇的文字，不进行分析和梳理，很容易会导致开发过程中遗漏需求，或者边界没考虑到位的情况。
如果在TDD之前我们在看完需求文档后，进行梳理，整理出一份验收表格，例如：
这份表格不用一开始就写的很完善，可以先写一部分，然后开发过程中，想到了新的用例，可以立刻补充。
这份表格可以和代码放在一起，进行版本管理。方便梳理自己思路的同时，也方面后续如果需要他人来接手这些代码的人进行后续的维护工作。
当有了这一份表格之后，我们进入TDD，进入具体的代码的编写就会更容易，也更明确目标。同时把需求分析和写代码分开，更有利于大脑的工作。如果大脑既要考虑分析需求，同时也并行的考虑算法，性能，代码的可维护性和可扩展性等等问题，那么每个环节都会考虑不周。造成工作质量不要。
因此，让大脑串行的工作，采用如下环节进行，效果会更佳：
1. 需求分析：分析需求，梳理主业务流程，分析边界，异常流，输出测试用例
2. 红：把测试用例转换成测试代码
3. 绿：通过算法实现需求
4. 重构：消除重复，提高代码的可扩展性，遵循一些好的设计原则（诸如面向对象设计原则）
网友评论