结合前一篇 [ 转 ] TDD，测试代码可以代替文档吗？ 。
在实际开发中变化总是时刻存在的，不存在一成不变的需求和设计，那我们在开发时候是不是总是在了解需求、设计、写代码、反馈验证、修改呢？不说小一点的项目，一般就大一点、人多一点的项目就经常会出现写了几十行代码要编译30分钟甚至60分钟的情况，再回过头测试下、验证下一天就这么过去…… 要做完一个项目要到什么时候啊，如果需求还时不时的变化这么几下……
传统的开发模式在中大型点的项目中已经不再实用了，那使用螺旋迭代的开发模式效果又如何呢？我们把变化的需求考虑进来，先快速的出一个原型版本，然后验证、调整设计、重新编码、编译，进入下一轮迭代开发，因为每次迭代都很短就可以有效的跟上变化的需求，也能解决因为项目过大自己改一点东西就会影响其他人、也被其他人影响的情况，如果开发人员又能够使用好的设计模式、好的设计理念、能熟练的建立SVN的feature branch和tag之类的应该就没问题了。可实际情况是能同时掌握这么多技术、又有这么多经验的优秀C++程序不怎么容易啊…… 然后在产品开发出来之后，要交给其他人维护了，这时候大家发现因为是迭代的快速开发模型，需求一直在变，为了验证功能和调整功能文档的修改没有跟上，设计文档没有跟上、开发的设计文档也没有跟上、UML图没有及时更新，最后大家就只有边看代码边想办法维护了。所以这种模式在我们开发中大型网络游戏的时候并不能说是一个最好的方法，那我们使用敏捷的开发方法呢。
我们使用敏捷的开发方式先用TDD做测试代码，先确定需求，然后把测试流程和接口做了，开始写代码。当我们用这个方法一步一步做下去会发现每一个功能都要花好多时间来做测试代码，都做好了才能开始写代码…… 如果很不幸在一个功能的测试代码写好、功能代码写好、测试都通过了，一切顺利这个功能该结了吧…… 突然需求有一点的小的改变，会让最初的测试流程重写、功能代码重写、所有测试重新做一遍…… 茶几就是这么形成的……
这种事情我是遇到过N次了，公司的童鞋们也遇到过M次了。所以我考虑既然设计要变，我们写功能代码也是要根据需求做设计、做测试用例（一般都不做）、写代码，每次需求变了还是重头来一次…… MVC的开发模型也提出来很久了，各种UML建模工具也是不断完善，更甚至有基于UML和MVC模型的开发工具可以就画画图就产生出产品了，不写一句代码。 其实这种开发模式也许是未来的一个趋势吧，毕竟人都懒的，都在想办法怎么提高开发效率，减小不必要的消耗。
想了这么多，先留个坑在这里…… 后面我也要想想怎么提高开发效率，提高策划、程序、测试还有参与项目每一个人的效率。