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