TDD实践感悟
每个开发者都想开发出高质量的代码，更少的Bug、更容易维护不仅让人心情愉悦，也让我们有更多时间去学习和生活。
少加一些班，多陪家人，：）
当开发任务非常简单时，比如基本的增删改查，可能使用怎样的方式开发都是可行的，条条大路通罗马。
但是当面临一个很复杂的、艰巨棘手的任务时，要保证很高的代码质量就会变得十分有挑战性。
在这里为大家简单介绍一种来自敏捷编程实践中的方法论-测试驱动开发，即TDD。
TDD并不是什么高深的理论，其涉及的方法和技巧其实很简单，大家都耳有所闻：面向对象设计、单元测试、重构。
TDD有三个核心原则：
1）没有测试之前不要写任何功能代码
2）只编写恰好能够体现一个失败情况的测试代码
3）只编写恰好能通过测试的功能代码
在实际开发过程中，可能并不需要严格遵守这三个原则。即便只是大体上应用TDD到复杂功能开发，就能发挥很大的作用。
具体来说，首先在开发前期，按照TDD的原则不断在添加测试用例和开发功能代码之间切换。
在这个循环迭代过程中，不断地通过重构和面向对象思想，完善代码设计。
并且可以引入业界公认的设计模式使自己的代码更加专业、优美。
这样做的优点：
一是帮助思考。对于很复杂的功能需要迭代开发，不可能一下子就把逻辑实现全想明白。于是可以先实现最简单功能，再逐步完善；
二是快速调试。有了单元测试，可以通过失败的用例直接找到对应出问题的代码，几乎不需要太多调试了；
三是通过TDD不断迭代出的代码，设计比较合理，后期更加容易维护。
当然凡事都是有利有弊的，TDD也有它的缺点和局限：
一是前期进开发稍慢一些，因为需要编写单元测试（但是TDD往往在开发中后期会让你的开发进度越来越快，
TDD节省下来的时间将远远超过编写和维护测试用例的时间。这就好比玩即时战略游戏，前期的精心布局将在中后期看到效果）；
二是对于简单功能并不适用，要注意应用场景。
任何方法都有其适用的范围和人群，在这里只是抛砖引玉为大家介绍一种开发方法。
当你习惯某种方式时，可能它就不只是一种方法论了，而变成了一个程序员的自我修养，成为你编码血液中的一部分。
希望大家都能找到自己喜欢的方式，让编码变得更加快乐！
少加一些班，多陪家人，：）
当开发任务非常简单时，比如基本的增删改查，可能使用怎样的方式开发都是可行的，条条大路通罗马。
但是当面临一个很复杂的、艰巨棘手的任务时，要保证很高的代码质量就会变得十分有挑战性。
在这里为大家简单介绍一种来自敏捷编程实践中的方法论-测试驱动开发，即TDD。
TDD并不是什么高深的理论，其涉及的方法和技巧其实很简单，大家都耳有所闻：面向对象设计、单元测试、重构。
TDD有三个核心原则：
1）没有测试之前不要写任何功能代码
2）只编写恰好能够体现一个失败情况的测试代码
3）只编写恰好能通过测试的功能代码
在实际开发过程中，可能并不需要严格遵守这三个原则。即便只是大体上应用TDD到复杂功能开发，就能发挥很大的作用。
具体来说，首先在开发前期，按照TDD的原则不断在添加测试用例和开发功能代码之间切换。
在这个循环迭代过程中，不断地通过重构和面向对象思想，完善代码设计。
并且可以引入业界公认的设计模式使自己的代码更加专业、优美。
这样做的优点：
一是帮助思考。对于很复杂的功能需要迭代开发，不可能一下子就把逻辑实现全想明白。于是可以先实现最简单功能，再逐步完善；
二是快速调试。有了单元测试，可以通过失败的用例直接找到对应出问题的代码，几乎不需要太多调试了；
三是通过TDD不断迭代出的代码，设计比较合理，后期更加容易维护。
当然凡事都是有利有弊的，TDD也有它的缺点和局限：
一是前期进开发稍慢一些，因为需要编写单元测试（但是TDD往往在开发中后期会让你的开发进度越来越快，
TDD节省下来的时间将远远超过编写和维护测试用例的时间。这就好比玩即时战略游戏，前期的精心布局将在中后期看到效果）；
二是对于简单功能并不适用，要注意应用场景。
任何方法都有其适用的范围和人群，在这里只是抛砖引玉为大家介绍一种开发方法。
当你习惯某种方式时，可能它就不只是一种方法论了，而变成了一个程序员的自我修养，成为你编码血液中的一部分。
希望大家都能找到自己喜欢的方式，让编码变得更加快乐！
