優化代碼裏的 「 壞味道 」

「 一顆老鼠屎，壞了一鍋粥，代碼也是如此。」

 

在咱們的項目中，也許在剛開始開發的時候，你們都會聽從一些規範來實施，可是當業務進度催的緊，或者人員變更，隨着時間的遷移，項目不斷的迭代之後，這時的代碼可能就會出現一些「壞味道」了。

 

「壞味道」代碼的出現可能不會影響咱們的業務邏輯，你們天然也就比較容易忽視掉了，可是這如同是給咱們代碼埋下的定時炸彈，當爆炸的那天，須要咱們背鍋處理的時候，就會後悔當初爲什麼不去解決這些問題呢？下面咱們來看一下有哪些「壞味道」代碼能夠提早處理的吧。

 

一、畫蛇添足型代碼。

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開發規範手冊》

 

細節決定成敗，在咱們工做的過程當中，固然還有不少須要咱們注意的細節，你們有什麼心得能夠留言交流一下~

 

最後推薦一下 <重構 改善代碼的既有設計>這本書，比較詳細的介紹有那些壞味道須要重構的地方。

文章首發於微信公衆號《深夜裏的程序猿》，天天分享最乾的乾貨，轉載務必註明出處，侵權必究。