“ 一顆老鼠屎，壞了一鍋粥，程式碼也是如此。”
在我們的專案中，也許在剛開始開發的時候，大家都會遵從一些規範來實施，但是當業務進度催的緊，或者人員變動，隨著時間的遷移，專案不斷的迭代以後，這時的程式碼可能就會出現一些“壞味道”了。
“壞味道”程式碼的出現可能不會影響我們的業務邏輯，大家自然也就比較容易忽視掉了，但是這如同是給我們程式碼埋下的定時炸彈，當爆炸的那天，需要我們背鍋處理的時候，就會後悔當初為何不去解決這些問題呢？下面我們來看一下有哪些“壞味道”程式碼可以提前處理的吧。
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開發規範手冊》
細節決定成敗，在我們工作的過程中，當然還有很多需要我們注意的細節，大家有什麼心得可以留言交流一下~
最後推薦一下 <重構 改善程式碼的既有設計>這本書，比較詳細的介紹有那些壞味道需要重構的地方。
