正文
为改变做好准备，并且主动地，时时刻刻地进行改变。这就是TDD的选择，可靠地对代码进行改变。并在这种改变中不断改善。
对于不熟悉的人而言，初看起来，TDD最大的特点是在实现代码之前写测试这个反直觉的实践。却往往忽略了藏在后面重构的那一步。事实上，前两步的红灯、绿灯，都是在为第三步的重构做准备。
第一步，写出失败的测试。是在为即将发生的重构建起保护网。
第二步，尽快的绿灯通过。是
刻意
写出需要重构的代码。
既然认为改变是有潜在破坏性的，那就尽早地、尽可能频繁地去改变代码。
测试与重构，像是硬币的两面一样，密不可分。
所以，如果你仍然认为重构像是吃完饭要洗碗一样的必要但是附属性的工作。如果你还没有感受到 TDD 带给你的保护与自由，让你放开对改变的恐惧，心安理得的写下将来必然会被改掉的代码。
那么就算你按照三步循环去写代码，恐怕也难以从中获得益处。很快就退回尽量预先思索，想小步却慢不下来的老路上。
4.
何谓持续
事实上，任何一个老练的程序员必然都有自己的一套方法来反复验证和调整正在开发的代码。这些方法可能包括，可控环境下的调试，添加一个临时的main方法作为实验入口，把代码片段复制到外部环境进行验证等等。
TDD 中的增量开发、小步快跑，用这些方法也可以做到。
我想这大概就是为什么有人会提出其实人人都在做 TDD 吧。尽管我不是特别认同这种说法。
如果没有那个点的话，也许做不做 TDD 确实无所谓。
这个点有时候叫做交付，也可能叫集成、发布；甚至有时候并没有一个清晰的事件点，不过是写完放下，过了几个星期而已。
但是这个点是实实在在存在的，它就是「鲜活」代码和遗留代码的分界点。越过了这一点，你手中的代码就会摇身一变，从那个开朗敏捷的少年，变做阴郁固执喜怒无常的怪兽。
TDD 的独特之处，是让测试伴随代码从生到死的整个生命周期，始终为代码变化提供保护网，让代码的「保鲜期」尽可能的长，抹平这个转变的节点。
现在持续集成、持续交付的概念已经是主流了。但是什么是持续呢？个人浅见，不是说设置了一个服务器，定时跑几个任务就是持续了。而是不再有那个代码保鲜期的拐点，可以一直平滑的发展下去。
TDD无疑是它的重要保证环节。
5.
开发者体验
TDD 的好处有哪些？关于这个问题，我原来总是尝试从客观的角度来回答。比如质量，比如可维护性，比如鼓励好的设计等等。总之，就是剔除了人的因素。
然而，当我认真探索自己这一路走来的历程。是怎么在 TDD 上略有心得后情不自禁的在社区分享。
重新开始写博客，几乎每篇都是关于 TDD 的。自发的公司里组织编程道场（Dojo）推广 TDD。背后的动力其实很简单，这样开发让我很爽。
这个答案听起来实在太不正式，好像也没啥说服力。但是确实是我的真实想法。
有人可能会说：工作嘛哪能那么理想化，老板给你工资就行了，谁管你开心不开心。
且不说更开心的程序员应该效率更高，而且开心本身就是公司状况良好的体现之类的客观化的理由。
从开发者个人而言，就算仅仅为了心情愉快、延年益寿，也是值得去做些努力去改进代码的。因为改善代码质量和开发流程，本身就是改善工作环境。
最近恰好读了一篇研究程序员各种不爽的论文。其中统计了上千个程序员的答卷。对工作中的不爽进行了分类。
可以看到尽管工作中有不少不受我们控制的部分，比如人的原因（416个）和公司流程（544个）， 但是最大的一部分还是来源于代码相关问题（788个）
再来看看常见的让程序员不爽的原因。前三位中的两个是：
而这些都是可以通过开发者自己努力来改善的。我的切身感受，TDD 带给了我如下变化：
