从以下仅为个人观点，如有疑问和异议，请在评论下留言。
从事Java开发已经有两年多，会开始考虑如何保障开发以及维护的稳定性，起因有二，一是公司项目总会有修不完的bug，每次的修复，总会引发新的问题出现，导致维护工作反反复复，新工作无法正常的开展；二是自己有创建网站的计划，希望能够避免类似公司项目这样的问题，导致效率低下。实际上，项目的开发，最本质的要求就是：
提高开发效率
减少维护成本
为了实现这两个要求，看了很多相关的资料，总结出来以下三点：
敏捷开发
测试驱动开发
重构
敏捷开发属于方法论，需要经验丰富的从业者驱动；重构属于技术活，要靠技术功底深厚的大牛；这两点不在今天的讨论范围之内，因为都需要经验的沉淀，但是测试驱动开发不同，他属于意识流，无论是刚入门的菜鸟，还是工作十年的老鸟，只有具备正确的思考方式，才能够完成项目的开发。
测试驱动开发，又名TDD，顾名思义，以测试用例驱动项目开发，与传统的发开模式不同。
-
传统的开发模式：
功能点需求分析
根据功能点编码
反复测试
修正BUG
回归
功能上线
-
测试驱动开发模式：
功能点需求分析
根据功能点编写测试用例
根据测试用例进行编码
反复测试
修正BUG
回归
功能上线
传统模式和测试驱动开发模式的区别仅在于第二，第三点，这小小的差别，却对结果有着翻天覆地的影响，可谓差之毫厘，失之千里。测试用例的存在为什么会导致如此大的差距？根据不同的开发阶段，可以对测试驱动开发模式进行分析：
-
设计阶段
基于需求编写的测试用例，可以快速提供产品原型，防止后期需求与描述不符导致返工
基于测试用例的类设计和接口设计，能更好地体现设计意图
-
开发阶段
通过多维度编写的测试用例，可以细致地定位需求的功能点，避免直接编码导致的考虑不周
根据测试用例的划分，逐一击破各个小的功能点，最后集成总功能，属于良性的开发循环，避免一次性将总功能实现所带来的巨大压力
-
代码重构阶段
测试用例可以保证重构代码不会影响到非重构部分，为开发者提供勇气和信心，否则，会因为代码的耦合性而难以重构
-
添加新功能阶段
添加新的测试用例，但新添加的功能不应该影响旧的测试用例，以保证系统的稳定性
说白了，TDD具备以下几点优势：
对需求负责（需求如何定义，测试用例就如何定义）
多个测试用例可精确描述所有的功能点
根据功能点，面向对象设计（对象设计，属性设计，接口设计）【设计的时候，会考虑到开发与到的问题】
编码的目的在于跑通一个个测试用例
测试用例相当于指南针，可以确保重构时和重构后，功能依旧能正确运行
新功能开发 ，继续添加新的测试用例，以保证新功能能在新的测试用例正常运行的同时，确保旧功能也能运行
测试代码要不断地更新，从最简单的测试代码到后来相对稳定的代码
测试代码是最好的接口文档，运行测试实例，可以从代码层面理解功能
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。