尝试使用测试驱动(TDD)开发

现在在一个小企业里搞开发。现在的主要工作是架构设计（当然还称不上架构师啦^_^）。以前公司有个架构，原来的架构，一牛人做的，虽然不是很“先进”（相对与现在架构流行使用依赖注射，对象关系映射等技术而言），但总体上还算规范，结构还是很清晰，也提供了很多通用功能，可以减少很多重复劳动。公司开发的人不多，3，4个人，可在前段的开发过程中，由于管理不善，个人开发习惯不同，导致架构的结构遭到很多破坏。使得产品的部署，维护，移植越来越困难。

现在正为公司搭建新的架构，采用的是struts+spring+hibernate的搭配方式，使用acegisecurity1.0.0作为security管理的中间件。我的目标是，新架构不但在技术和结构上要跟上主流，在搭建过程中也要探索出一条适合小团队的开发管理方法。

以前的开发非常缺乏规范，缺乏文档，缺乏测试。造成用户抱怨连连，项目久拖不决。为了解决这些问题，想尝试引入测试驱动开发（TDD）。我们这样的小团队，没有受过十分严格的软件工程培训，个人开发习惯很不相同，以及项目进度要求，时间紧，要想完全按照瀑布模型，rup来走，几乎是不可能的。基本的开发模式是从需求中抽出几个具体的功能模块，然后每个人负责一个独立的功能模块开发完成。没有什么先设计，再编码实现的工程，调试基本上就是部署上去以后调试，没有什么测试用例。引入TDD并不想解决设计的问题，设计还是交给个人在开发过程中逐步细化，边开发边设计。引入TDD是为了强制提高各class的内聚性，强制开发人员首先考虑组件要完成一个什么功能，要达到什么样的要求，是为了保证各个组件得到的充分的测试。

刚学TDD，很多还不了解，还需要一段时间的摸索，有什么经验教训再写上来：）