《测试驱动开发》，弱弱的看了几十面，实在看不下去了。反正觉得总体一句话：首先确定测试（需要的功能），再快速的做出来，再在此基础上进行修改。

TDD（Test-driven development）测试驱动开发，是极限编程（XP）最常用的一种方式。即使你不是采用的极限编程这种软件开发方法，也应该采用。因为这种方式可以让你的代码整洁好用。 我们将建立一个计划清单，当开始某项工作时，就用粗体表示，而如果完成了，就在上面画一条线。 首先确定需要的功能（即让什么样的测试通过），然后编写接口，再让程序逐步实现，满足测试的需求。最后，消除重复，完善程序。 消除副作用，先快速的伪实现，再具体的进行实现。（谨慎而为之...对这条没什么信心...如果能够一次性实现，那么就一次性是实现吧...然后再逐步完善...） 三角法，当测试的例子多余两于时，就实现一般化。 我们并非绝对的追求完美，而是应该尽可能的减少缺陷。 一定要消除重复的设计，消除重复的代码，在重复代码消除前绝不回家。（文章中说，首先毫无顾忌的通过拷贝让程序运行起来，然后再消除重复的代码。个人认为，一定要重复的代码没有形成规模时，就要进行去重的工作。经验表明，当写代码时想着先重复着，再重构，往往当代码积累到一定规模时，重构工作牵一发而动全身。非常不好处理。最好是在编写代码的过程中，就注意不要让代码重复。） 在看第5章时，我首先想到的是接口。实际上，接口并不能为Dollar和Franc节省任何代码。因为接口中只能有方法的定义，方法的实现还是要放在实现类中，代码依然重复。实际上，最应该使用的方法应该是继承。因为父类中放所有子类的公有属性和方法，子类中只需有各自的特色方法即可。没有第一时间想到最优的方法，证明我的基本功还是不扎实的。 逐步将子类中的方法归纳如父类中。（这样不失为定义父类的一个好方法。） 可以把父类作为abstract类，在其中定义abstract方法，由子类实现。