优化代码里的 “ 坏味道 ”

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

 

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

 

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

 

一、画蛇添足型代码。

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

 

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

 

return a > b;

 

二、瞎命名型代码。

 

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

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

 

三、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

  

 四、复制粘贴型

 

  举个例子，项目中A模块引入B模块的优惠券业务，此时C模块也要引入B模块的优惠券业务，因为此时的优惠券业务多是B模块中的几行代码，不少人就为了贪图方便，直接复制这几行代码直接放到C模块了。so easy，代码完美运行。

 

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

 

因此从上面的案例中，若是咱们一开始不偷懒把公共逻辑抽取出来，在各个模块引用的话，不论怎么修改，咱们只要维护一份逻辑就能够，不至于手忙脚乱。

 

五、又长又臭型代码

 

此类坏味道代码通常出如今“有历史“的代码中，通过不一样开发人员的迭代，一个方法可能会出现几千行的状况，即便有注释，也会让人看得痛不欲生，这时候刚接手修改的人必然会说一句“WTF”了。

 

因此这就要求咱们在平时写代码的过程当中养成提炼的习惯，通常来讲，当某块业务逻辑须要注释来讲明的时候，通常均可以提炼成方法来调用，经过这种方式会使得阅读代码的时候逻辑更加清晰。

 

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

 

六、无病呻吟型

 

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

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

 

细节决定成败，在咱们工做的过程当中，固然还有不少须要咱们注意的细节，你们有什么心得能够留言交流一下~

 

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

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