测试驱动开发实用指南--摘记(2006-09-3)

当采用TDD进行开发的时候,你有两顶帽子:
编码: 在你带这顶帽子的时候,你向系统中添加新的功能但不进行重构.
重构: 在你带上这顶帽子的时候,你进行重构但不增加新的功能.
在你要上某个测试通过的时候,带上编码的帽子,一旦测试通过,你就换顶帽子执行重构来进行清理.
----《测试驱动开发实用指南》P12

Code Smells （Kinbor注：书本翻译是代码有味儿不太喜欢这个翻译还是用英文原文）
----《测试驱动开发实用指南》P132
1．注释 大多数注释存在的理由要么是采用的开发过程所要求的，要么是用来弥补编写拙劣的代码，如果你看到一条注释或者觉得有必要编写一条注释的话，那么请首先要考虑重构或重写代码。
2．数据类 数据类本质上是一种演进的record或struct。它只包含数据而没有丝毫行为。不要被那些其存在的只是为了存取类所包含的数据成员的存取方法（accessor或method）所迷惑。存在公共（public）的实例变量（域或属性）是最让人头疼的了。
3．重复代码
4．交往不当 这种情况是指一个类对另一个类的内部细节知道的太多。想要处理这种情况，我们就需要对方法进行迁移，让那些彼此了解的代码处于同一个位置。对于继承来说也出现会同样的问题，即子类过多的了解的。要处理这种情况，我们可以通过继承换成委派（delegation 莫非是说委托？？）或将祖先类的具体细节置为私有的而使这种关系松散化，即去耦（decouple）
5．类的尺寸过大 如果我们发现系统存在比其他大多数类大得不得成比例的类时，就要仔细检查一下了。它为什么会这么大？是不是想要完成的工作太多了呢？是了解的东西太多了吗？大多数行为都是条件判断（conditional）吗？那么我也许可以提取子类并且采用多态（polymorphism）来看看大麻是否能够恰当执行。如果存在清晰明确的子功能结合，那么或许能够把它们提取出来而形成自己的类（用代码行loc度量工具或生成可视化UML）
6．懒惰类 （Lazy Class） 这是与大尺寸类正好相反的情况，懒惰类并不能够充分体现其价值，所以应当与别的适当的类加以合并。
7．方法太长（Long Method） 就像尺寸过大的类一样，过长的方法同样成问题。通过将功能内聚的代码块拆分到各自独立的方法中，我们可以削减方法的尺寸并使代码更容易理解。那么多长才算长呢？如果看行数的话，任何超过10行左右的代码都算长。另一点需要考虑的就是认知长度（cognitive length）----即方法企图完成的工作数目。对于这种情况，任何超出一件工作的方法都算长。
8．霰弹式的外科手术（Shotgun Sergery） 这并不算是原自code smells，更是出于我们与代码打交道的方式。当我们要改动一处功能，却发现需要改动多个地方的代码，我们往往通过采用“用多态来代替条件判断”的重构方法来做到这一点。