問答專欄Q & A COLUMN
你好，很高興為你解答，我是一個不折不扣的程序員，平時開發當然也無法避免會使用IF|ELSE。當然也會有一些“高端代碼”，怎么才能寫出區別于IF|ELSE的高端代碼呢？我覺得可以由一下幾個方面去學習：
算法是程序的靈魂，同樣的功能，用IF|ESLE可能要幾千行代碼，如果使用合適的算法，可能就只有幾百行代碼，甚至幾十行，例如遞歸、動態規劃算法等。
這是每個優秀程序員必備的優秀品質，高端代碼不是憑空產生的，它有一定的積累過程。積累并不是閉門造車，而是開源的思維。總所周知，各大論壇、代碼共享平臺上都有一些優秀的源代碼。可以根據自己的職業方向、編程語言去閱讀源代碼，并模仿它。
編程是一個需要動手的活，萬丈高樓平地起，沒有人一開始就能寫出高端代碼，都是一點點在坑里摸爬滾打，寫一些簡單代碼，一步一步完善，一點一點進步的。我現在經過幾個月的學習，回過頭看幾個月前的代碼，都想去修復它。
編程需要不斷學習，不斷提升。什么才是高端代碼，我現在寫的代碼一定比過去寫的高端，只要不斷學習，我未來寫的代碼，一定比現在高端。
希望我的回答能給你幫助，謝謝采納。
評論0
加載中...
你這問題問得很奇怪。計算機程序離開了if else，那根本就不叫程序了。就像你蓋房子，離不開磚頭。
一個優秀的程序員并不是說要用多高級的技巧，用越簡單的語句，寫出越高效的程序，那才叫高手。
評論0
加載中...
對于這個問題，首先要弄明白“if else”的作用是什么，為什么會有那么多“if else”的代碼邏輯；然后再來考慮如何解決這個問題。
“if else”表述的是一分為二的情況，表示一個業務邏輯只有有種狀態，要么是這樣，反之，就是那樣。通常是應用在一些能夠簡單分為兩種情況的環境中，在這種環境中，只有兩種可能，如果不是前一種，那么就一定是后一種。這樣的情況放到現實環境中，似乎聽起來過于極端，也過于簡單粗暴，畢竟現實環境是很復雜的；這樣子的極端情況畢竟是少數。
那為什么會出現那么多“if else”的代碼呢？其實，原因很簡單，因為簡單；
很多程序員，特別是初級，偏向于簡單處理問題，并沒有深入考慮過要實現的業務邏輯，簡單粗暴地將問題一分為二的處理；
對語言基礎知識、算法和數據結構的認識和了解不夠，沒有一個深厚的基礎知識加持，很多基礎知識基本上是來自于各種論壇，技術分享，而這些信息良莠不齊，所以導致基礎知識一知半解，只知其然，不知其所以然，實現代碼邏輯的時候就會以最簡單的方式來處理；
時間限制，很多公司、項目給的開發時間是見很急、很倉促的；有的時候連需求都沒有整理清楚就開始了，因為要快速完成任務，實現代碼的時候就會按照最簡單粗暴的方式來處理；
else 不到萬不得已，不要輕易使用，即便使用，也要清楚的在注釋中清楚、詳細的說明為什么要使用；
遇到一分為二的代碼邏輯時，可以考慮換種方式來處理：先在if 中使用一種情況做判斷，并在其中處理完相應的代碼邏輯后，返回處理結果；剩下的就是另一種情況了，這時就不用再使用“else”來處理了；
對于if - else if else這樣的情況，可以考慮使用“枚舉 + switch”來配合處理不同情況的代碼邏輯；
作為一個技術人員，深厚的基礎知識是行走IT江湖的內功心法，擁有深厚的內功，才能做到處變不驚；無論是學習新技術、新語言，還是提升自身實力，都是需要很深的基礎、底層知識；因為不斷學習，積累、進步就顯得尤為重要。
1.語言基礎、底層知識：
良好的語言基礎；基礎的數據類型，運算符、語法、語言的各種特性，也才能更好的使用語言來實現業務邏輯；
明確語言的邊界：明確該語言能做什么、不能做什么；有何不足，不足該如何解決；有何優勢，如何更好的發揮優勢；
語言底層編譯、解釋原理：掌握源程序的編譯、解釋過程，才能知道如何才能寫出高效、性能俱佳的代碼，也能更好的實現程序優化；
2.數據結構和算法
算法是程序的靈魂，數據結構是算法的精髓；優秀的算法基礎，能夠幫助你寫出高效率、高性能的代碼；使用幾千行代碼才能實現的極其復雜的代碼邏輯，使用算法實現后，可能只需要幾百行、甚至是幾十行代碼，不過這就得要求你及其熟練的掌握數據結構和多種算法實現；
3.網絡、通信協議
網絡交互協議、通信協議、網絡分層模型的學習也是非常有必要的，比如：TCP/IP，HTTP、HTTPSSSLTLS、IPFS等。
4.操作系統
無論是Windows、Mac OSX還是Linux系統，不一定都要精通，但要精通其一，在Linux系統的良好性能、優秀設計的大背景下，Linux系統是一個不錯的方向，當然Windows也是可以考慮的方向；將來還有鴻蒙、方舟編譯、Fuchsia等。
5.架構設計
在完成了多個項目以后，就可以開始著手整理、總結整個項目的架構設計了；剛開始可以是一個簡單的小型項目，然后不斷更新，迭代，要堅持下去；等項目達到一個體量之后，可以考慮分模塊，分庫分表的設計；然后可以考慮引進分布式部署，微服務技術。
在項目中不斷更新技術，讓自己的技術跟著自己的項目一起成長。
完結，希望以上回答能對你有所幫助。
評論0
加載中...
我前段時間針對某種情況下消除大量的if-else結構寫了一篇頭條《優雅地移除if-else/switch的應用實踐》，感興趣的話可以到我賬號里查看，或者前往https://www.toutiao.com/i6803897250528363019/
評論0
加載中...
用不用 if else 這種基礎語法不是區別代碼厲不厲害的關鍵啊。
年輕人剛開始總因為代碼越復雜，別人看不懂，越能說明自己的代碼高級。這種想法實際上錯的離譜。
什么是優秀的代碼呢?
在完成需求的前提下，能把代碼寫的越簡單越好，代碼具有易讀性、易擴展行，這些才是好代碼的關鍵因素。而不是說你的代碼用了一些高級牛逼的語法，就可以說你的代碼牛逼。
寫代碼不要追求“茴字有幾種寫法”這類問題，而應該學學白居易寫故事那樣子，要把代碼寫成初級程序員也能看懂，這才是功力。很多有些的開源代碼都做到這點，比如redis代碼之類的。
代碼中有if else 之類的代碼是再正常不過了，不要炫技，不要追求屠龍技術。當然，如果代碼中的if else同個地方出現太多，需要考慮下代碼是不是有更好的寫法，具體問題具體分析。
評論0
加載中...
首先題主的問題不簡單，雖然看起來像是小白白可能問得問題，但是作為有多年實戰經驗的老程序猿突然面對這種拷問靈魂的問題也有可能手足無措，不知如何解答！
那如何才能寫出比if else看著更高大上的邏輯呢？各層樓主其實已經給出解答了！這個得看應用場景，不能為寫代碼而寫代碼，關鍵在如何已巧妙的方式實現高性能代碼！比如 多層嵌套的if else可以轉換為 switch，如果多層嵌套if else中存在遞歸關系可以考慮編寫dsl特定領域語言，如 json 、Sql 等。
其實每一門語言解析器都是有規律的if else判斷！只不過在實現語言解析器時用了遞歸算法！樓主可以研究一下編譯原理以及編譯原理的實踐antlr4 .
當你看完編譯原理時就會明白這個世界確實存在比if else 更巧妙的代碼。
評論0
加載中...
不要去過度關注if/else的層數，而要關注接口語義是否足夠清晰；單純減少if/else的層數，然后拆出一堆do_logic1, do_logic2...這樣的接口是毫無幫助的。任何一個接口的執行過程都可以表示為：輸入 + 內部狀態 -> 輸出這樣的形式，我們分以下幾種情況來討論：輸入、內部狀態、輸出都很簡單，但中間邏輯復雜。比如說一個精心優化過的數值計算程序，可能需要根據輸入在不同的取值范圍采取不同的策略，還有很多邏輯用來處理會引發問題（比如除0）的邊界值，這種情況下if/else數量多是難以避免的，根據步驟拆分出一些內部方法有一定幫助，但也不能完全解決問題。這種情況下最好的做法是寫一篇詳細的文檔，從最原始的數學模型開始，然后表明什么情況下采取什么樣的計算策略，策略如何推導，知道得到代碼中使用的具體形式，然后給整個方法加上注釋附上文檔地址，并且在每個分支的地方加上注釋指明對應到文檔中哪個公式。這種情況下雖然方法很復雜，但是語義是清晰的，如果不修改實現的話理解語義就行了，如果要修改實現那么需要參考對照文檔中的公式。輸入過于復雜，比如輸入帶有一堆不同的參數，或者有各種奇怪的flag，每個flag有不同作用。這種情況下首先需要提高接口的抽象層次：如果接口有多個不同作用，需要拆分成不同接口；如果接口內部根據不同參數進不同分支，需要將這些參數和對應分支包在Adapter里，使用參數的地方改寫成Adapter的接口，根據傳入的Adapter類型不同進入不同的實現；如果接口內部有復雜的參數轉換關系，需要改寫成查找表。這種情況下的主要問題是接口本身抽象的有問題，有更清晰的抽象之后，實現也自然沒有那么多if/else了。輸出過于復雜，為了省事一個過程計算出了太多東西，又為了性能加了一堆flag控制是否計算之類。這種情況下需要果斷將方法拆分成多個不同方法，每個方法只返回自己需要的內容。如果不同計算之間有共用的內部結果呢？如果這個內部結果計算并不形成瓶頸，只要提取出內部方法然后在不同過程中分別調用即可；如果希望避免重復計算，可以增加一個額外的cache對象作為參數，cache內容對用戶不透明，用戶只保證相同輸入使用同一個cache對象即可，在計算中將中間結果保存到cache中，下次計算前先檢查有沒有已經得到的結果，就可以避免重復計算了。內部狀態過于復雜。首先檢查狀態設置的是否合理，是不是有一些本來應該作為輸入參數的東西被放到了內部狀態中（比如用來隱式地在兩個不同方法調用之間傳遞參數）？其次，這些狀態分別控制哪些方面，是否可以分組然后實現到不同的StateManager里面？第三，畫出狀態轉移圖，嘗試將內部狀態分成單層分支，然后分別實現到on_xxx_state這樣的方法里面，然后通過單層的switch或者查找表來調用。其實通常需要優化的都是整體接口抽象，而不是單個接口的實現，單個接口實現不清晰通常是因為接口實現和需求不同構造成的。
評論0
加載中...0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答1
回答
