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