测试驱动开发系列之四--代码中的坏味道以及如何改进他们

代码中的坏味道以及如何改进他们

让我们改变传统的对待建造程序的态度。不是把我们主要的任务想象成是去指示计算机要做什么，而是关注于向人们解释我们希望计算机做什么。
下面列举了一些常见的需要重构的点。
重复代码
坏名字
坏意大利面:
 那是一种一团糟的代码，它让你无法知道它到底在做什么。这种代码的特征是有很高的圈复杂度。
长函数
 让一个函数超过一屏的范围绝对会使代码难于装入到脑子里。
抽象注意力分散
 每个函数都应当有一个一致的抽象层次。如果你没有使用对象来表达问题中存在的概念，这使得代码变的难以理解，解决问题的难度大大增加。好的习惯是扩充语言所能提供原始类型，用小对象来表示范围、金额、转化率、邮政编码等等。
眼花缭乱的布尔运算
 那些AND OR还有括号会让你的思想麻木。应该吧复杂的判断封装在一个子函数中以便于代码理解。
不光彩的switch/case
 有switch/case的函数应当遵守单一职责原则。
重复的switch/case
 当switch/case的逻辑重复出现，但是有不同的动作时，就是时候考虑替换他们了
邪恶的嵌套
 有着深嵌套的代码是很难理解的。
条件编译
 条件编译难以避免，但应该吧它当做处理多平台情况的最后选择。集中关注的条件编译方式不见得很差，但通常条件编译的做法都是把对平台的依赖分布到代码的各处。我倾向于使用链接器或者函数指针来独立开对平台的依赖。我们把平台相关的代码分组，依改变的平台而绑定。我们让平台相关和平台无关的代码分离开，其中平台无关的代码就是你的长期投资。
注释掉的代码
 充满注释掉代码的源文件看起来很丑。对这种代码坏味道的解决方法很简单，删除注释掉的代码。
注释
 有时注释是必要的，但更多的情况下它只是个弱点。重构的目的是得到有良好结构能表明自己做了什么的代码。当没有其他方式来做到这一点时再用注释。结构良好的代码不需要很多注释。在你的模块有单一的职责，有良好的命名，并且有揭示其目的的函数时，代码就可以自己解释自己了。
依恋情节
 如果一个对象去拿别人的数据对它操作，然后把它放回到其他对象中或者从中产生一些输出，那么说明它依恋于其他对象。
 在C语言中，这基本上就是把一个结构体传来传去或者全局都可以访问时会发生的事情。
 依恋情节常常会导致很多重复。当没有地方可以找到那些操作特定数据结构的代码时，每个想要用到这个结构体的函数很可能不得不重复地和其他地方同样的方式来使用这个结构体。
参数太多
 当多个函数申明中都有一个共同的参数时，这很可能就表明需要一个新的数据结构了。要改进这种情况，我们需要一个新的模块。重复的参数将是新模块的核心。从前的某个使用长参数表的调用函数将成为模块的初始化函数。其他函数则用指向新定义结构体的指针来替代长参数表。
不管三七二十一的初始化
 这个问题的根源是代码没有包含明确的初始化函数，数据结构倾向于被不管三七二十一地初始化。代码没有明确表明初始化和运行之间的区别。对这种坏味道的改进起码要把初始化的代码收集起来，放到一处，并使初始化过程很明显。如果你开始为遗留代码开发测试，你会发现，这些函数会应测试用例中的需要而产生。