幾個(gè)業(yè)務(wù)場景中的重構(gòu)示例

請求順序依賴

在這種場景中，首先還是業(yè)務(wù)的復(fù)雜度決定了代碼的復(fù)雜度。首先我們來看一個(gè)在前端和node都有可能出現(xiàn)的一個(gè)簡單的例子：

我們有 A, B, C, D 四個(gè)請求獲取數(shù)據(jù)的函數(shù)(函數(shù)自己實(shí)現(xiàn))， C 依賴 B 的結(jié)果，D 依賴 ABC 的結(jié)果，最終輸出 D 的結(jié)果。

錯(cuò)誤示例 

雖然這個(gè)代碼是故意寫成這樣的，不過確實(shí)也有在一些初學(xué)者身上看到過。這份代碼還是能正確給出結(jié)果的，但是寫法丑陋，回調(diào)地獄。如果后來人不進(jìn)行重構(gòu)，還有請求依賴，得繼續(xù)回調(diào)嵌套。性能太差，沒有考慮 A 和 B 實(shí)際上是可以并發(fā)的。

這里介紹了一下最原始的 callback ... 中間大家可以去回顧一下 整個(gè) ES2015+ ，callback (async.js) --> Promise --> generator + co --> async + await 的進(jìn)化過程。其實(shí)是從原生的語法層面不斷去簡化和增強(qiáng)我們對于異步的控制能力。

下面直接給目前階段原生提供的終極方案：基于 Promise + async/await

正確示例 

我們重新思考了一下上面的問題，理清楚了邏輯順序的依賴。并且用最新的語法。

使用 Promise.all 結(jié)合 async/await 的形式，考慮了并發(fā)和串行，寫法簡潔，達(dá)到了在示例要求下的最快方案。解決了無限嵌套的問題。這是跟隨語言進(jìn)化本身帶給我們可以進(jìn)行的優(yōu)化。

但又不僅僅如此。我們將問題進(jìn)行歸類 將 B，C 有依賴順序的請求，抽離出單獨(dú)的函數(shù)。讓他們?nèi)ヌ幚碜陨淼倪壿?。這個(gè)點(diǎn)我們稍后再提。

折磨人的 if else

可能存在下面一些問題

1. 過多的嵌套
2. 邏輯處理冗余
3. 沒有做好防御編程(錯(cuò)誤處理

直接來一個(gè)代碼例子，這是一個(gè)獲取背景顏色的方法，但是隨著業(yè)務(wù)的不斷變化，背景顏色的來源越來越多，在一些業(yè)務(wù)人員的處理下可能是這樣的：

錯(cuò)誤示例

相信你在讀上面的代碼的時(shí)候是極為痛苦的，想要一目了然的知道最終會(huì)進(jìn)入哪個(gè)分支，基本不可能。于是基于下面兩個(gè)原則

• 合理的抽取成函數(shù)
• 錯(cuò)誤優(yōu)先返回

有了一個(gè)基礎(chǔ)版本的重構(gòu)：

正確示例 

可以看到整個(gè)邏輯，經(jīng)過了重新梳理。拆分成了三個(gè)函數(shù)，子方法分別去處理對應(yīng)層級的邏輯，由一個(gè)主方法負(fù)責(zé)調(diào)度。整體都變得一目了然了。

當(dāng)然，在我們基于上面的原則進(jìn)行重構(gòu)之后，這個(gè)代碼有沒有問題呢?當(dāng)然有?？梢钥吹轿覀冞@三個(gè)函數(shù)，都依賴了全局變量。函數(shù)本身就不純了。如果是全局的問題，還是不易于排查。

我們可以將其修改為純函數(shù)，讓這一份代碼易于理解和測試。

以一個(gè)函數(shù)的修改為示例：我們將 全局變量變成了參數(shù)，只需要在調(diào)用的時(shí)候，將全局變量傳入即可，但是這樣，我們得到了一個(gè)純函數(shù)。 

為什么會(huì)在這里特別強(qiáng)調(diào)這個(gè)點(diǎn)呢，其實(shí)在函數(shù)式編程中的一個(gè)最基礎(chǔ)的問題那就是純函數(shù)。只有這樣輸入輸出才是可被觀測的，一個(gè)輸入一定會(huì)有一個(gè)輸出。也只有通過這樣的方式，才能讓系統(tǒng)中非純的函數(shù)越來越少。讓代碼變得更易于測試。

當(dāng)然作為我們?nèi)绻灾貥?gòu)的角度去思考的話，我們還需要關(guān)注到這個(gè)點(diǎn)： 

這里的邏輯會(huì)將會(huì) 最后一個(gè)被匹配到的數(shù)據(jù)，設(shè)置為 bgColor 。(我們都知道 find indexOf 等基本都是從前匹配。)是否真的是業(yè)務(wù)的需求呢?

可以看到將業(yè)務(wù)代碼寫好/重構(gòu)的過程中其實(shí)也是對業(yè)務(wù)邏輯和業(yè)務(wù)理解的再一次提升。不論是抽取成函數(shù)還是錯(cuò)誤優(yōu)先返回的設(shè)計(jì)，這其實(shí)也都是可以解決這樣一個(gè)問題：能在不去讀懂全局的情況下，了解某一個(gè)區(qū)域的細(xì)節(jié)邏輯，也就做到了讓代碼易于理解和修改。

... 這里的代碼即便是經(jīng)過這樣的重構(gòu)后，依然有可以考慮進(jìn)一步優(yōu)化的空間，比如函數(shù)與參數(shù)的命名，完整的測試用例等等，受限于文章篇幅，暫不展開說明。

一些代碼中可能存在的其他問題

1.邏輯耦合在視圖層。

a === 'a' && b ==='b' && c==='c' && d ==='d'? <div>...</div>:null  

2.組件復(fù)用，函數(shù)復(fù)用，不封裝，代碼重復(fù)。

3.函數(shù)功能不單一，一個(gè)函數(shù)處理太多職責(zé)。且這些職責(zé)沒有任何關(guān)聯(lián)，但是都耦合在同一個(gè)區(qū)塊內(nèi)。

4.參數(shù)列表混亂，有做好防御編程，不處理錯(cuò)誤(接口錯(cuò)誤，超時(shí)，重復(fù)提交等等

5.魔法數(shù)字，魔法字符串，且沒說明。

6.糟糕數(shù)據(jù)結(jié)構(gòu) / 糟糕命名 (其實(shí)上面的具體代碼示例也存在)

關(guān)于優(yōu)化代碼的思想準(zhǔn)備

首先來說一下為什么會(huì)說需要優(yōu)化代碼?

1. 技術(shù)追求。
2. 公司要求，線上有系統(tǒng)在用。有用戶在用，不寫好出問題實(shí)際上苦的還是自己。
3. 團(tuán)隊(duì)協(xié)作，我不好好寫，團(tuán)隊(duì)成員其他人也不好好寫，惡性循環(huán)苦的還是自己。
4. 快速迭代。系統(tǒng)需要不斷的增加新功能。必須要寫好代碼才能做到。
5. 其他人的看法，怕別人覺得自己技術(shù)能力差... xxxx....

那么就會(huì)有下面這些要求：

1. 易于理解系統(tǒng)的架構(gòu)
2. 易于理解系統(tǒng)的生命周期與執(zhí)行流程
3. 易于理解每一個(gè)函數(shù)的作用
4. 易于理解函數(shù)之間是如何調(diào)用與傳遞的(輸入輸出)
5. 易于理解變量的含義，表達(dá)式的含義。
6. 易于擴(kuò)展...

最終實(shí)際上又回到了寫出來的代碼應(yīng)該是 整潔的代碼，要使代碼易于理解/修改/測試。(這里其實(shí)大部分時(shí)候，都隱含了一個(gè)人員協(xié)作的條件在里面，所以，既要寫好代碼，又不能過度封裝，讓團(tuán)隊(duì)其他成員看不懂(當(dāng)然如果確實(shí)有些人經(jīng)驗(yàn)不夠，那么是他自身的問題，需要他自己去加強(qiáng)。))

一些建議

1. 更加清晰的去了解業(yè)務(wù)，去思考可能的變化。思考和設(shè)計(jì)清楚再動(dòng)手。
2. 看一些開源項(xiàng)目與業(yè)界最佳實(shí)踐，明白什么樣的是好代碼，什么樣的是不好的代碼。
3. 建立明白代碼雖然是給計(jì)算機(jī)運(yùn)行的，但最終還是人看的。不僅僅是沒有 bug 就行了，這樣的心智模型。
4. 建立業(yè)務(wù)與代碼質(zhì)量同等重要的思考模型。避免因?yàn)闀r(shí)間導(dǎo)致的不得不這么寫的代碼。
5. 明白 code review 本身可能能發(fā)現(xiàn)和指出來一些問題，但最終的落實(shí)還的靠自己，不能變成形式，而是需要融合成自身的思考。
6. 使用錯(cuò)誤優(yōu)先原則。盡可能的讓出錯(cuò)的先返回， 這樣后面就會(huì)得到干凈的代碼。(寫代碼的時(shí)候，不僅僅正向，反向的判斷也需要思考)
7. 合理的拆分成獨(dú)立的函數(shù)。明確輸入輸出，錯(cuò)誤處理等在函數(shù)內(nèi)部的處理。(比如在一些場景中確實(shí)會(huì)存在大量邏輯判斷，首先就要思考在判斷內(nèi)部的語句是否能被歸類與拆分出去)
8. 對于多種狀態(tài)的判斷與組合，可以使用 組合狀態(tài)表 (map表)狀態(tài)機(jī)等模式
9. 學(xué)習(xí)設(shè)計(jì)模式與重構(gòu)等相關(guān)知識。
10. 重構(gòu)!!只要你覺得這個(gè)地方有問題了，那就不要等到以后。以后往往就是再也不。

結(jié)束

說到這可能會(huì)有一種戛然而止的感覺。在這一篇文章里面，我們首先以兩個(gè)優(yōu)化代碼的具體實(shí)例為引子，讓大家明白了一些業(yè)務(wù)代碼的優(yōu)化思路。從列舉了一些其他可能出現(xiàn)的錯(cuò)誤，以及是優(yōu)化代碼的思想準(zhǔn)備和理論指導(dǎo)。其實(shí)都是希望大家能夠在業(yè)務(wù)中去發(fā)現(xiàn)問題，再去思考如何解決問題，說了那么多，到底能不把代碼寫好，還是得靠自己~