一個快速迭代的專案，時間久了之後，程式碼中可能會充斥著大量的if/else，巢狀6、7層，一個函式幾百行，簡！直！看！死！人！
其實這種還算好的，更嚴重的巢狀我也見過，接手到這種專案的人，內心應該是絕望的。
出現這種情況的原因很多
- 設計不夠完善
- 需求考慮不完全
- 開發人員變動
但最為致命的是“懶”，沒有夢想是件很可怕的事情！
前期迭代懶得優化，來一個需求，加一個if，久而久之，就串成了一座金字塔。
當程式碼已經複雜到難以維護的程度之後，只能狠下心重構優化。那，有什麼方案可以優雅的優化掉這些多餘的if/else?
01 提前return
這是判斷條件取反的做法，程式碼在邏輯表達上會更清晰，看下面程式碼：
其實，每次看到上面這種程式碼，我都心裡抓癢，完全可以先判斷!condition，幹掉else。
02 策略模式
有這麼一種場景，根據不同的引數走不同的邏輯，其實這種場景很常見。
最一般的實現：
看上面程式碼，有4種策略，有兩種優化方案。
2.1 多型
具體策略物件存放在一個Map中，優化後的實現
上面這種優化方案有一個弊端，為了能夠快速拿到對應的策略實現，需要map物件來儲存策略，當新增一個新策略的時候，還需要手動新增到map中，容易被忽略。
2.2 列舉
發現很多同學不知道在列舉中可以定義方法，這裡定義一個表示狀態的列舉，另外可以實現一個run方法。
重新定義策略列舉
通過列舉優化之後的程式碼如下
03 學會使用 Optional
Optional主要用於非空判斷，由於是jdk8新特性，所以使用的不是特別多，但是用起來真的爽。
使用之前：
如果登入使用者為空，執行action1，否則執行action 2，使用Optional優化之後，讓非空校驗更加優雅，間接的減少if操作
04 陣列小技巧
來自google解釋，這是一種程式設計模式，叫做表驅動法，本質是從表裡查詢資訊來代替邏輯語句，比如有這麼一個場景，通過月份來獲取當月的天數，僅作為案例演示，資料並不嚴謹。
一般的實現：
優化後的程式碼
05 結語
if else作為每種程式語言都不可或缺的條件語句，在程式設計時會大量的用到。一般建議巢狀不要超過三層，如果一段程式碼存在過多的if else巢狀，程式碼的可讀性就會急速下降，後期維護難度也大大提高。
如果你還有其它小技巧，歡迎留言！！！