练习了几天codekata，虽然每天只是练半个小时，也不是每天，中间还隔了个周末，今天还是收获了一点东西：

这几天练习的都是同一个例子，例子是 Kata09: Back to the Checkout

以前也看过一些重构方面的书，但是没有具体的实践，发现不知道什么时候去重构代码，

我就这样一个一个测试的写，一个一个的运行测试，然后到下一个测试的时候：

我就开始改实现这个测试的方法的实现代码，改完还要再测试之前所有的测试也得通过，这个时候改动是很大的：

改动量是很大的，而且这样并起不到GTD的效果了，我查了一下资料发现：

1.在TDD的基本流程（红，绿，重构）中，我其实只做了前两步（红，绿），而没有做重构这一步。

2.在实现代码的时候，我并没有做到---“写刚好能让测试通过的实现”，我是在实现代码的时候想着重构，而不是写完，测试通过后去思考这个问题

以上两种情况造成，我想的太多，这样就会造成思路不清晰，没有分离关注点，把各种需求缠绕在一起，理不清！

从我出现的这几个问题，我也看到了使用TDD的好处，优点。接下来我要严格按照GTD的基本流程和三条原则进行TDD的练习。

TDD 的基本流程是：红，绿，重构。

更详细的流程是：

写一个测试用例

运行测试

写刚好能让测试通过的实现

运行测试

识别坏味道，用手法修改代码

运行测试

TDD 的三条规则

1.除非是为了使一个失败的 unit test 通过，否则不允许编写任何产品代码

2.在一个单元测试中，只允许编写刚好能够导致失败的内容（编译错误也算失败）

3.只允许编写刚好能够使一个失败的 unit test 通过的产品代码

代码的抽象三原则

所谓"抽象化"，就是指从具体问题中，提取出具有共性的模式，再使用通用的解决方法加以处理。

一、DRY原则

DRY是 Don't repeat yourself 的缩写，意思是"不要重复自己"。
它的涵义是，系统的每一个功能都应该有唯一的实现。也就是说，如果多次遇到同样的问题，就应该抽象出一个共同的解决方法，不要重复开发同样的功能。

二、YAGNI原则

YAGNI是 You aren't gonna need it 的缩写，意思是"你不会需要它"。
指的是你自以为有用的功能，实际上都是用不到的。

它背后的指导思想，就是尽可能快、尽可能简单地让软件运行起来（do the simplest thing that could possibly work）。

但是，这里出现了一个问题。仔细推敲的话，你会发现DRY原则和YAGNI原则并非完全兼容。前者追求"抽象化"，要求找到通用的解决方法；后者追求"快和省"，意味着不要把精力放在抽象化上面，因为很可能"你不会需要它"。所以，就有了第三个原则。

三、Rule Of Three原则

Rule of three称为"三次原则"，指的是当某个功能第三次出现时，才进行"抽象化"。

它的涵义是，第一次用到某个功能时，你写一个特定的解决方法；第二次又用到的时候，你拷贝上一次的代码；第三次出现的时候，你才着手"抽象化"，写出通用的解决方法。

这样做有几个理由：

（1）省事。如果一种功能只有一到两个地方会用到，就不需要在"抽象化"上面耗费时间了。

（2）容易发现模式。"抽象化"需要找到问题的模式，问题出现的场合越多，就越容易看出模式，从而可以更准确地"抽象化"。