垃圾代碼和優(yōu)質(zhì)代碼的區(qū)別？
幾個業(yè)務場景中的重構(gòu)示例
請求順序依賴
在這種場景中，首先還是業(yè)務的復雜度決定了代碼的復雜度。首先我們來看一個在前端和node都有可能出現(xiàn)的一個簡單的例子：
我們有 A, B, C, D 四個請求獲取數(shù)據(jù)的函數(shù)（函數(shù)自己實現(xiàn)）， C 依賴 B 的結(jié)果，D 依賴 ABC 的結(jié)果，最終輸出 D 的結(jié)果。
錯誤示例
雖然這個代碼是故意寫成這樣的，不過確實也有在一些初學者身上看到過。這份代碼還是能正確給出結(jié)果的，但是寫法丑陋，回調(diào)地獄。如果后來人不進行重構(gòu)，還有請求依賴，得繼續(xù)回調(diào)嵌套。性能太差，沒有考慮 A 和 B 實際上是可以并發(fā)的。
這里介紹了一下最原始的 callback ... 中間大家可以去回顧一下 整個 ES2015+ ，callback (async.js) --> Promise --> generator + co --> async + await 的進化過程。其實是從原生的語法層面不斷去簡化和增強我們對于異步的控制能力。
下面直接給目前階段原生提供的終極方案：基于 Promise + async/await
正確示例
我們重新思考了一下上面的問題，理清楚了邏輯順序的依賴。并且用最新的語法。
使用?Promise.all?結(jié)合?async/await?的形式，考慮了并發(fā)和串行，寫法簡潔，達到了在示例要求下的最快方案。解決了無限嵌套的問題。這是跟隨語言進化本身帶給我們可以進行的優(yōu)化。
但又不僅僅如此。我們將問題進行歸類 將 B，C 有依賴順序的請求，抽離出單獨的函數(shù)。讓他們?nèi)ヌ幚碜陨淼倪壿嫛＿@個點我們稍后再提。
折磨人的 if else
可能存在下面一些問題
過多的嵌套
邏輯處理冗余
沒有做好防御編程（錯誤處理
直接來一個代碼例子，這是一個獲取背景顏色的方法，但是隨著業(yè)務的不斷變化，背景顏色的來源越來越多，在一些業(yè)務人員的處理下可能是這樣的：
錯誤示例
相信你在讀上面的代碼的時候是極為痛苦的，想要一目了然的知道最終會進入哪個分支，基本不可能。于是基于下面兩個原則
合理的抽取成函數(shù)
錯誤優(yōu)先返回
有了一個基礎版本的重構(gòu)：
正確示例
可以看到整個邏輯，經(jīng)過了重新梳理。拆分成了三個函數(shù)，子方法分別去處理對應層級的邏輯，由一個主方法負責調(diào)度。整體都變得一目了然了。
當然，在我們基于上面的原則進行重構(gòu)之后，這個代碼有沒有問題呢？當然有。可以看到我們這三個函數(shù)，都依賴了全局變量。函數(shù)本身就不純了。如果是全局的問題，還是不易于排查。
我們可以將其修改為純函數(shù)，讓這一份代碼易于理解和測試。
以一個函數(shù)的修改為示例：我們將 全局變量變成了參數(shù)，只需要在調(diào)用的時候，將全局變量傳入即可，但是這樣，我們得到了一個純函數(shù)。
為什么會在這里特別強調(diào)這個點呢，其實在函數(shù)式編程中的一個最基礎的問題那就是純函數(shù)。只有這樣輸入輸出才是可被觀測的，一個輸入一定會有一個輸出。也只有通過這樣的方式，才能讓系統(tǒng)中非純的函數(shù)越來越少。讓代碼變得更易于測試。
當然作為我們?nèi)绻灾貥?gòu)的角度去思考的話，我們還需要關注到這個點：
這里的邏輯會將會?最后一個被匹配到的數(shù)據(jù)，設置為 bgColor 。（我們都知道 find indexOf 等基本都是從前匹配。）是否真的是業(yè)務的需求呢？
可以看到將業(yè)務代碼寫好/重構(gòu)的過程中其實也是對業(yè)務邏輯和業(yè)務理解的再一次提升。不論是抽取成函數(shù)還是錯誤優(yōu)先返回的設計，這其實也都是可以解決這樣一個問題：能在不去讀懂全局的情況下，了解某一個區(qū)域的細節(jié)邏輯，也就做到了讓代碼易于理解和修改。
... 這里的代碼即便是經(jīng)過這樣的重構(gòu)后，依然有可以考慮進一步優(yōu)化的空間，比如函數(shù)與參數(shù)的命名，完整的測試用例等等，受限于文章篇幅，暫不展開說明。
一些代碼中可能存在的其他問題
邏輯耦合在視圖層。
a === 'a' && b ==='b' && c==='c' && d ==='d'?...:null組件復用，函數(shù)復用，不封裝，代碼重復。
函數(shù)功能不單一，一個函數(shù)處理太多職責。且這些職責沒有任何關聯(lián)，但是都耦合在同一個區(qū)塊內(nèi)。
參數(shù)列表混亂，有做好防御編程，不處理錯誤（接口錯誤，超時，重復提交等等
魔法數(shù)字，魔法字符串，且沒說明。
糟糕數(shù)據(jù)結(jié)構(gòu) / 糟糕命名 （其實上面的具體代碼示例也存在）
關于優(yōu)化代碼的思想準備
首先來說一下為什么會說需要優(yōu)化代碼？
技術追求。
公司要求，線上有系統(tǒng)在用。有用戶在用，不寫好出問題實際上苦的還是自己。
團隊協(xié)作，我不好好寫，團隊成員其他人也不好好寫，惡性循環(huán)苦的還是自己。
快速迭代。系統(tǒng)需要不斷的增加新功能。必須要寫好代碼才能做到。
其他人的看法，怕別人覺得自己技術能力差... xxxx....
那么就會有下面這些要求：
易于理解系統(tǒng)的架構(gòu)
易于理解系統(tǒng)的生命周期與執(zhí)行流程
易于理解每一個函數(shù)的作用
易于理解函數(shù)之間是如何調(diào)用與傳遞的（輸入輸出）
易于理解變量的含義，表達式的含義。
易于擴展...
最終實際上又回到了寫出來的代碼應該是?整潔的代碼，要使代碼易于理解/修改/測試。
（這里其實大部分時候，都隱含了一個人員協(xié)作的條件在里面，所以，既要寫好代碼，又不能過度封裝，讓團隊其他成員看不懂（當然如果確實有些人經(jīng)驗不夠，那么是他自身的問題，需要他自己去加強。））
一些建議
更加清晰的去了解業(yè)務，去思考可能的變化。思考和設計清楚再動手。
看一些開源項目與業(yè)界最佳實踐，明白什么樣的是好代碼，什么樣的是不好的代碼。
建立明白代碼雖然是給計算機運行的，但最終還是人看的。不僅僅是沒有 bug 就行了，這樣的心智模型。
建立業(yè)務與代碼質(zhì)量同等重要的思考模型。避免因為時間導致的不得不這么寫的代碼。
明白 code review 本身可能能發(fā)現(xiàn)和指出來一些問題，但最終的落實還的靠自己，不能變成形式，而是需要融合成自身的思考。
使用錯誤優(yōu)先原則。盡可能的讓出錯的先返回， 這樣后面就會得到干凈的代碼。（寫代碼的時候，不僅僅正向，反向的判斷也需要思考）
合理的拆分成獨立的函數(shù)。明確輸入輸出，錯誤處理等在函數(shù)內(nèi)部的處理。（比如在一些場景中確實會存在大量邏輯判斷，首先就要思考在判斷內(nèi)部的語句是否能被歸類與拆分出去）
對于多種狀態(tài)的判斷與組合，可以使用 組合狀態(tài)表 （map表）狀態(tài)機等模式
學習設計模式與重構(gòu)等相關知識。
重構(gòu)！！只要你覺得這個地方有問題了，那就不要等到以后。以后往往就是再也不。
結(jié)束
說到這可能會有一種戛然而止的感覺。在這一篇文章里面，我們首先以兩個優(yōu)化代碼的具體實例為引子，讓大家明白了一些業(yè)務代碼的優(yōu)化思路。從列舉了一些其他可能出現(xiàn)的錯誤，以及是優(yōu)化代碼的思想準備和理論指導。其實都是希望大家能夠在業(yè)務中去發(fā)現(xiàn)問題，再去思考如何解決問題，說了那么多，到底能不把代碼寫好，還是得靠自己~
---END---
長按進入小程序，進行打卡簽到
（更多精彩值得期待……）
最近熱文： 2021年2月程序員工資統(tǒng)計，平均15144元 兩款程序員常用的工具，非常實用！ 一周內(nèi)被程序員瘋轉(zhuǎn)5.6W次，最終被大廠封殺！ 程序員老婆VS非程序員老婆，太可愛了！ 炸裂！MySQL 82 張圖帶你飛！ 2T技術資源大放送！包括但不限于：C/C++，Linux，Python，Java，人工智能，考研，軟考，英語，等等。在公眾號內(nèi)回復「資源」，即可免費獲取！回復「社群」，可以邀請你加入讀者群！ 明天見(??ω??)??
