if....else....使用思考

if…else…是一個偉大的發明

if…else…就像當年的AK47，成本低廉，足夠簡單，簡單到連小孩子都輕易理解；同時if…else…足夠強大，就像AK47，一梭子掃過來，打得人抱頭鼠竄。if…else…確實很強大，強大到你稍不留意，就能使一段代碼被衆多的if…else…搞得複雜無比。。。

如何正確使用if…else…是門藝術

if…else…本質來講是條件控制語句，它能夠用來實現強大的流程處理，這一點無可厚非。然而，不少時候，咱們把if…else…做爲一種實現技巧，爲提升減小代碼量，提升所謂的「複用率」，或者說爲了使程序更「精練」。

 

例如，A、B功能模塊具備相似的業務流程，但輸入數據不一樣，某一個字段的處理不一樣，因而聰明的程序員很天然的在A模塊的業務方法中增長了一段if…else…，根據傳入參數，來控制那個特殊字段的處理。這樣實現是正確的，至少在當時的業務需求前提下能夠很好的提升編碼較率。但這麼作的本質，其實是把不一樣業務實體之間的條件控制，轉移到了業務實體之中，把本來互相獨立的模塊，緊密地結合在了一塊兒。很明顯在咱們寫這樣的自覺得很精練、妙趣橫生的代碼時，咱們把每天掛在嘴邊的「高內聚，低耦合」拋到九霄雲外了。。。

好景不長，初版華麗的收尾了，第二版接踵而至，第二版增長了C模塊，C模塊的輸入和A、B一致，但邏輯處理和輸出與A、B差別較大。需求人員樂呵呵地描述了需求，心想C和A、B其實複雜度差很少，以前作A、B也沒遇到什麼問題，此次能有什麼問題呢？但是實現人員對此憤憤不平：這乍改，誰說複雜度差很少了，C和A、B明顯不同啊？！但他的話很明顯是沒有說服力的。他無奈地接受了這個糾結的命運——在以前A、B的那個if…else…後面再加了一個else，即便A、B、C真正共同複用的只有if前面那兩行代碼。。。

再後來的狀況或許你們都猜到了，A、B、C、D……，終於加到了第十個模塊，這個時候if…else…已經盤根錯節。同一個字段承擔了好幾個模塊場景下的不一樣業務意義的數據，只由於這些數據都是date類型。。一個整型數據，在一個模塊處理中是業務數據，在另外一個場景則變成了邏輯控制的一部分。。在無所不能的if…else…裏，一切皆有可能，這個時候，程序員以經沒法徹底按照本身的意願去改這坨代碼了，他們每每按照測試時的運行結果來調整各處代碼。。客觀的說，此時的代碼，已經不按人類的意志來運行了！愚蠢的人類啊，他們一手創造了這一切，確發現他們沒法掌控這一切，而當這些自覺得是的人類意識到問題的嚴重性時，結局已經難以挽回了。。

積極重構，合理使用設計模式破除if…else…

再回過頭來看看，最開始時把A、B模塊作如此高的複用，對仍是不對呢？固然是正確的，至少在當時是正確的：開發經理眉開眼笑，效率很高啊，來個效率之星表彰一下吧~複用是必需的，只是複用的方法不對而已。兩個模塊，咱們很容易發現其共性，三個或三個以上呢？其實也很簡單，設計模式啊~好比大量類似的表單，能夠用裝飾模式、建造者模式，取表單數據能夠和責任鏈、命令模式等。咱們一遍又一遍的學習設計模式，但很多人仍是對此不覺得意，認爲咱們日常實現過程沒機會用設計模式，致使各類模式看多少遍忘多少遍。其實不須要特地套用某個設計模式，能夠藉助其思想，咱們要用設計模式來實現業務，沒有哪一個業務是爲了某個設計模式而存在的。值得注意的是，沒有哪個設計模式將條件控制語句做爲其實現的憑仗。設計模式是爲了解耦，而if…else…其實就是一種耦合。

功能點與功能點估算的準確性

功能點估算是比較先進的估算方法，功能點估算把各個功能當作互相獨立的操做和文件來處理，所以才能達到不一樣的人做出估算得出相近結果的效果。若是在實現過程當中利用功能模塊內部的條件控制來實現不一樣模塊的複用，這樣確定會使工做量小於估算，因而功能點估算時引入了「複用程度」的概念。但問題是，「複用程度」還比較好估計，「不復用程度」呢，估算的時候，誰能預測以前的代碼會對現在的需求產生什麼影響呢？由於這自己就是個笑話，以前代碼怎麼會影響將來的需求，本末倒置啊。但事實的狀況是，它還真影響了，或者說是阻礙了新功能的引入。功能點具備不可控的工期，功能點估算就不許了。在功能模塊內部使用if…else…是極不合理的複用方法，等若飲鴆止渴。

功能點估算法，客觀上要求咱們不去糅合兩個不一樣模塊，這與複用並不矛盾。正確的方法其實很簡單，只要注意條件控制語句若是不可必免必定只能加在功能外部，把複用的部分抽取出來便可。引入其餘功能時，也要極力避免在已抽取的方法內添加if…else…，隨着複用的方法抽取愈來愈多，咱們就會慢慢意識到，這裏有點像XX設計模式耶。因此說，好的代碼、好的設計、好的架構，都是改出來的。

總結

沒有人刻意去寫爛代碼，每每咱們嗤之以鼻的爛代碼，每一坨都不是自然造成的。一坨爛代碼的造成，是日積月累的結果，項目團隊人員更迭，甚至是幾批、幾代程序員共同奮鬥的結果。if…else…有一種神奇的魔力，它依靠else if這種神奇的特性，把一坨坨代碼串在一塊兒。正如破窗效應，程序員們每每不由自主地在if…else…後繼續添加if…else…。做爲優秀的程序員，咱們必定要有足夠的定力，出淤泥而不染，拒絕if…else…的誘惑。一時爽一下，但終究仍是要還的。

記住，珍惜生命，預防猝死，遠離if…else…