這次if線的出現在方舟是有重大意義的。在此之前異格炎熔是史實，此次異格蒂蒂是if。

在這種情下 我只要寫控制我方人物移動的程式碼 就可以做到被地形水擋住去路 穿不過去（無需任何其他的判斷程式碼）。 layer設定或者tag的if判斷，貌似layer更方便點。

不要去過度關注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或者查詢表來呼叫。其實通常需要最佳化的都是整體介面抽象，而不是單個介面的實現，單個介面實現不清晰通常是因為介面實現和需求不同構造成的。

演算法是程式的靈魂，同樣的功能，用IF|ESLE可能要幾千行程式碼，如果使用合適的演算法，可能就只有幾百行程式碼，甚至幾十行，例如遞迴、動態規劃演算法等。

這是每個優秀程式設計師必備的優秀品質，高階程式碼不是憑空產生的，它有一定的積累過程。積累並不是閉門造車，而是開源的思維。總所周知，各大論壇、程式碼共享平臺上都有一些優秀的原始碼。可以根據自己的職業方向、程式語言去閱讀原始碼，並模仿它。

程式設計是一個需要動手的活，萬丈高樓平地起，沒有人一開始就能寫出高階程式碼，都是一點點在坑裡摸爬滾打，寫一些簡單程式碼，一步一步完善，一點一點進步的。我現在經過幾個月的學習，回過頭看幾個月前的程式碼，都想去修復它。

程式設計需要不斷學習，不斷提升。什麼才是高階程式碼，我現在寫的程式碼一定比過去寫的高階，只要不斷學習，我未來寫的程式碼，一定比現在高階。

對於這個問題，首先要弄明白“if else”的作用是什麼，為什麼會有那麼多“if else”的程式碼邏輯；然後再來考慮如何解決這個問題。

“if else”表述的是一分為二的情況，表示一個業務邏輯只有有種狀態，要麼是這樣，反之，就是那樣。通常是應用在一些能夠簡單分為兩種情況的環境中，在這種環境中，只有兩種可能，如果不是前一種，那麼就一定是後一種。這樣的情況放到現實環境中，似乎聽起來過於極端，也過於簡單粗暴，畢竟現實環境是很複雜的；這樣子的極端情況畢竟是少數。

那為什麼會出現那麼多“if else”的程式碼呢？其實，原因很簡單，因為簡單；

很多程式設計師，特別是初級，偏向於簡單處理問題，並沒有深入考慮過要實現的業務邏輯，簡單粗暴地將問題一分為二的處理；

對語言基礎知識、演算法和資料結構的認識和了解不夠，沒有一個深厚的基礎知識加持，很多基礎知識基本上是來自於各種論壇，技術分享，而這些資訊良莠不齊，所以導致基礎知識一知半解，只知其然，不知其所以然，實現程式碼邏輯的時候就會以最簡單的方式來處理；

時間限制，很多公司、專案給的開發時間是見很急、很倉促的；有的時候連需求都沒有整理清楚就開始了，因為要快速完成任務，實現程式碼的時候就會按照最簡單粗暴的方式來處理；

else 不到萬不得已，不要輕易使用，即便使用，也要清楚的在註釋中清楚、詳細的說明為什麼要使用；

遇到一分為二的程式碼邏輯時，可以考慮換種方式來處理：先在if 中使用一種情況做判斷，並在其中處理完相應的程式碼邏輯後，返回處理結果；剩下的就是另一種情況了，這時就不用再使用“else”來處理了；

對於if - else if else這樣的情況，可以考慮使用“列舉 + switch”來配合處理不同情況的程式碼邏輯；

作為一個技術人員，深厚的基礎知識是行走IT江湖的內功心法，擁有深厚的內功，才能做到處變不驚；無論是學習新技術、新語言，還是提升自身實力，都是需要很深的基礎、底層知識；因為不斷學習，積累、進步就顯得尤為重要。

1.語言基礎、底層知識：

良好的語言基礎；基礎的資料型別，運算子、語法、語言的各種特性，也才能更好的使用語言來實現業務邏輯；

明確語言的邊界：明確該語言能做什麼、不能做什麼；有何不足，不足該如何解決；有何優勢，如何更好的發揮優勢；

語言底層編譯、解釋原理：掌握源程式的編譯、解釋過程，才能知道如何才能寫出高效、效能俱佳的程式碼，也能更好的實現程式最佳化；

2.資料結構和演算法

演算法是程式的靈魂，資料結構是演算法的精髓；優秀的演算法基礎，能夠幫助你寫出高效率、高效能的程式碼；使用幾千行程式碼才能實現的極其複雜的程式碼邏輯，使用演算法實現後，可能只需要幾百行、甚至是幾十行程式碼，不過這就得要求你及其熟練的掌握資料結構和多種演算法實現；

3.網路、通訊協議

網路互動協議、通訊協議、網路分層模型的學習也是非常有必要的，比如：TCP/IP，HTTP、HTTPS\SSL\TLS、IPFS等。

4.作業系統

無論是Windows、Mac OSX還是Linux系統，不一定都要精通，但要精通其一，在Linux系統的良好效能、優秀設計的大背景下，Linux系統是一個不錯的方向，當然Windows也是可以考慮的方向；將來還有鴻蒙、方舟編譯、Fuchsia等。

5.架構設計

在完成了多個專案以後，就可以開始著手整理、總結整個專案的架構設計了；剛開始可以是一個簡單的小型專案，然後不斷更新，迭代，要堅持下去；等專案達到一個體量之後，可以考慮分模組，分庫分表的設計；然後可以考慮引進分散式部署，微服務技術。

在專案中不斷更新技術，讓自己的技術跟著自己的專案一起成長。

用不用 if else 這種基礎語法不是區別程式碼厲不厲害的關鍵啊。

年輕人剛開始總因為程式碼越複雜，別人看不懂，越能說明自己的程式碼高階。這種想法實際上錯的離譜。

什麼是優秀的程式碼呢?

在完成需求的前提下，能把程式碼寫的越簡單越好，程式碼具有易讀性、易擴充套件行，這些才是好程式碼的關鍵因素。而不是說你的程式碼用了一些高階牛逼的語法，就可以說你的程式碼牛逼。

寫程式碼不要追求“茴字有幾種寫法”這類問題，而應該學學白居易寫故事那樣子，要把程式碼寫成初級程式設計師也能看懂，這才是功力。很多有些的開原始碼都做到這點，比如redis程式碼之類的。

程式碼中有if else 之類的程式碼是再正常不過了，不要炫技，不要追求屠龍技術。當然，如果程式碼中的if else同個地方出現太多，需要考慮下程式碼是不是有更好的寫法，具體問題具體分析。