优化代码里的 “ 坏味道 ”

“ 一颗老鼠屎，坏了一锅粥，代码也是如此。”

 

在我们的项目中，也许在刚开始开发的时候，大家都会遵从一些规范来实施，但是当业务进度催的紧，或者人员变动，随着时间的迁移，项目不断的迭代以后，这时的代码可能就会出现一些“坏味道”了。

 

“坏味道”代码的出现可能不会影响我们的业务逻辑，大家自然也就比较容易忽视掉了，但是这如同是给我们代码埋下的定时炸弹，当爆炸的那天，需要我们背锅处理的时候，就会后悔当初为何不去解决这些问题呢？下面我们来看一下有哪些“坏味道”代码可以提前处理的吧。

 

1、多此一举型代码。

if(a > b){
   return true;
}else{
   return false;
}

 

 也许一些经验不那么老道的开发会觉得这段代码没问题呀，可以跑得通，确实，在逻辑上是没问题的，但是有更简洁明了的写法为何不用？if() 里面的条件是boolean ，然后我们的返回值也是boolean，所以可以改写成

 

return a > b;

 

2、瞎命名型代码。

 

int a;
string wzbt; // 文章标题
string fastdi; //fast di 快递  。。中西结合...

以上只是不规范命名的实例的冰山一角，良好的命名除了见名知意以外，还可以在长时间以后回来阅读代码时，更快的回忆起业务逻辑，不至于在各种无解的命名中乱了手脚，为了一时的方便而随意命名是非常不值得的。

 

3、if完一定要加else型代码

 

if(condition){
   //dosm
}else{
   return ;
}

if(condition){
   //dosm
}else{
   throw new exception();
}

while(xx){
    if(condition){
            //dosm
    }else{
            continue;    
    }
}

很多情况下，我们通过一些语句的前置类减少不必要的else，让代码看起来更简练清晰。

if(!condition){
   return ;
}
//dosm

if(!condition){
   throw new exception();
}
//dosm

  

 4、复制粘贴型

 

  举个例子，项目中a模块引入b模块的优惠券业务，此时c模块也要引入b模块的优惠券业务，由于此时的优惠券业务可能是b模块中的几行代码，很多人就为了贪图方便，直接复制这几行代码直接放到c模块了。so easy，代码完美运行。

 

看起来似乎又没什么毛病，此时程序员的天敌产品经理过来了，他说在要在优惠券逻辑前面加点限制条件，ok，那么此时就要改动a模块跟b模块2份代码，而且要保持一致性，这个需求就完成了。过了一个版本，d模块也要引用优惠券业务，此时你又愉快的复制过去，然后可爱的产品经理又过来跟你说，这个版本我们要砍掉前面的限制条件...这时候你就要同步三段代码...跟产品经理的一场大战估计在所难免了。 

 

所以从上面的案例中，如果我们一开始不偷懒把公共逻辑抽取出来，在各个模块引用的话，不论怎么修改，我们只要维护一份逻辑就可以，不至于手忙脚乱。

 

5、又长又臭型代码

 

此类坏味道代码一般出现在“有历史“的代码中，经过不同开发人员的迭代，一个方法可能会出现几千行的情况，即使有注释，也会让人看得痛不欲生，这时候刚接手修改的人必然会说一句“wtf”了。

 

所以这就要求我们在平时写代码的过程中养成提炼的习惯，一般来说，当某块业务逻辑需要注释来说明的时候，一般都可以提炼成方法来调用，通过这种方式会使得阅读代码的时候逻辑更加清晰。

 

还有一种又长又臭情况是出现在方法的参数中，不断的迭代过程也会导致参数的增加或者修改，甚至有看过朋友公司的代码出现一个方法10多个参数的情况。一般来说，当参数超过5个的时候就要考虑封装到对象当中了。

 

6、无病呻吟型

 

//输出info日志
logger.info("xxx");
//定义num变量
int num  = 0;
...

上面举例的是一些无关痛痒的注释，当代码中充斥着这些玩意的时候会让人觉得很臃肿，当你做到上面五点的时候，代码已经不需要太多注释了，所以我们的注释要注释到痛点，具体可参考《阿里java开发规范手册》

 

细节决定成败，在我们工作的过程中，当然还有很多需要我们注意的细节，大家有什么心得可以留言交流一下~

 

最后推荐一下 <重构 改善代码的既有设计>这本书，比较详细的介绍有那些坏味道需要重构的地方。

文章首发于微信公众号《深夜里的程序猿》，每天分享最干的干货，转载务必注明出处，侵权必究。