“ 一颗老鼠屎，坏了一锅粥，代码也是如此。”
在我们的项目中，也许在刚开始开发的时候，大家都会遵从一些规范来实施，但是当业务进度催的紧，或者人员变动，随着时间的迁移，项目不断的迭代以后，这时的代码可能就会出现一些“坏味道”了。
“坏味道”代码的出现可能不会影响我们的业务逻辑，大家自然也就比较容易忽视掉了，但是这如同是给我们代码埋下的定时炸弹，当爆炸的那天，需要我们背锅处理的时候，就会后悔当初为何不去解决这些问题呢？下面我们来看一下有哪些“坏味道”代码可以提前处理的吧。
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开发规范手册》
细节决定成败，在我们工作的过程中，当然还有很多需要我们注意的细节，大家有什么心得可以留言交流一下~
最后推荐一下 <重构 改善代码的既有设计>这本书，比较详细的介绍有那些坏味道需要重构的地方。
文章首发于微信公众号《深夜里的程序猿》，每天分享最干的干货，转载务必注明出处，侵权必究。