重构 之代码的坏味道(Bad smell)

最常见的Bad smell有：
1、重复代码。
我觉得这是优质代码的头号公敌，通常是大量复制、粘贴的结果。
这厮带来的最大问题：相同的逻辑分散在多处，导致修改困难，容易遗漏

2、过大的类或者方法
一个方法如果很长(通常超过两屏），则要理解其逻辑将非常困难，
重构时通常要将处理步骤梳理出来，每步一个子方法，主函数变成一个很清晰函数调用序列。
如有必要，可以对子方法进一步重构，直到每个方法只解决一个问题。

3、不合理的类封装
一个设计最初一般是合理的，但随着后续的修改，会不断的向已有类上增加方法，导致本来健康的类变得臃肿，
因此，每隔一段时间，应该重新规划方法的分布，比如在类之间迁移，或者抽象出新的类来。

4、魔鬼数字
int i=0;
int j=1;
如果不加额外的注释，谁能明白0和1的意义？
魔鬼数字的说法早已有之，是影响代码可读性的一大毒瘤，处理方法为：用常量替换之

除了魔鬼数字，还有一种魔鬼逻辑，比如：
if ((status==RUNNING || status==STARING) && (freeSlot.size()>RESERVED)){ //Do Something! }
以上的if条件虽然没有出现魔鬼数字，但这个逻辑有些复杂，也是需要读代码的人费些心思去算计的，
通常条件判断式如果包含两项以上的表达式，这样的条件建议重构成一个方法： if (canAcceptMore()){ //Do Something! } private boolean canAcceptMore(){ return (status==RUNNING || status==STARING) && (freeSlot.size()>RESERVED); } 

5、不合理的命名
不合理的变量名也会大大影响代码的阅读，变量名、方法名、类名、包名都要认真考虑，一般遵循如下原则
意义准确，且不随便将一个变量转作它用
风格统一（Java官方的约定就挺好的）
用词统一（同样代表缓冲，不要一会儿Buf，一会儿Cache，要么都缩写，要么都全拼）

6、冗长的参数列
函数拥有超长的参数列，通常也是增量修改的结果，这时候要考虑
要么，将参数抽象成一个独立的对象进行传递
要么，考虑一下这个方法是否有更合适的归宿
要么，可以看一下这个方法是不是完成了太多的逻辑而需要进行拆分