Java团队开发

Java 下的 team 开发，一般采用 cvs(版本控制) + ant(项目管理) + junit(集成测试) 的模式： 每天早上上班，每个开发人员从 cvs server 获取一个整个项目的工作拷贝。 拿到自己的任务，先用 junit 写今天的任务的测试代码。 然后写今天任务的代码，运行测试，直到测试通过，任务完成 在下班前一两个小时，各个开发人员把任务提交到 cvs server 然后由主管对整个项目运行自动测试，哪个测试出错，就找相关人员修改，直到所有测试通过。下班。。。

先写测试，再写代码的好处：

从技术上强制你先考虑一个类的功能，也就是这个类提供给外部的接口，而不至于太早 陷入它的细节。这是面向对象提倡的一种设计原则。

好的测试其实就是一个好的文档，这个类使用者往往可以通过查看这个类的测试代码了 解它的功能。特别的，如果你拿到别人的一个程序，对他写测试是最好的了解这个程序 的功能的方法。 xp的原则是 make it simple，不是很推荐另外写文档，因为项目在开 发过程中往往处于变动中，如果在早期写文档，以后代码变动后还得同步文档，多了一 个工作，而且由于项目时间紧往往文档写的不全或与代码不一致，与其这样，不如不写。 而如果在项目结束后再写文档，开发人员往往已经忘记当时写代码时的种种考虑，况且 有下一个项目的压力，管理人员也不愿意再为旧的项目写文档。导致以后维护的问题。

没有人能保证需求不变动，以往项目往往对需求的变动大为头疼，害怕这个改动会带来 其他地方的错误。为此，除了设计好的结构以分割项目外（松耦合），但如果有了测试， 并已经建立了一个好的测试框架，对于需求的变动，修改完代码后，只要重新运行测试 代码，如果测试通过，也就保证了修改的成功，如果测试中出现错误，也会马上发现错 在哪里。修改相应的部分，再运行测试，直至测试完全通过。