幾個業務場景中的重構示例
請求順序依賴
在這種場景中，首先還是業務的複雜度決定了代碼的複雜度。首先我們來看一個在前端和node都有可能出現的一個簡單的例子：
我們有 A, B, C, D 四個請求獲取數據的函數（函數自己實現）， C 依賴 B 的結果，D 依賴 ABC 的結果，最終輸出 D 的結果。
錯誤示例
雖然這個代碼是故意寫成這樣的，不過確實也有在一些初學者身上看到過。這份代碼還是能正確給出結果的，但是寫法醜陋，回調地獄。如果後來人不進行重構，還有請求依賴，得繼續回調嵌套。性能太差，沒有考慮 A 和 B 實際上是可以併發的。
這裏介紹了一下最原始的 callback ... 中間大家可以去回顧一下 整個 ES2015+ ，callback (async.js) --> Promise --> generator + co --> async + await 的進化過程。其實是從原生的語法層面不斷去簡化和增強我們對於異步的控制能力。
下面直接給目前階段原生提供的終極方案：基於 Promise + async/await
正確示例
我們重新思考了一下上面的問題，理清楚了邏輯順序的依賴。並且用最新的語法。
使用 Promise.all 結合 async/await 的形式，考慮了併發和串行，寫法簡潔，達到了在示例要求下的最快方案。解決了無限嵌套的問題。這是跟隨語言進化本身帶給我們可以進行的優化。
但又不僅僅如此。我們將問題進行歸類 將 B，C 有依賴順序的請求，抽離出單獨的函數。讓他們去處理自身的邏輯。這個點我們稍後再提。
折磨人的 if else
可能存在下面一些問題
1、過多的嵌套
2、邏輯處理冗餘
3、沒有做好防禦編程（錯誤處理
直接來一個代碼例子，這是一個獲取背景顏色的方法，但是隨着業務的不斷變化，背景顏色的來源越來越多，在一些業務人員的處理下可能是這樣的：
錯誤示例
相信你在讀上面的代碼的時候是極爲痛苦的，想要一目瞭然的知道最終會進入哪個分支，基本不可能。於是基於下面兩個原則
- 合理的抽取成函數
- 錯誤優先返回
有了一個基礎版本的重構：
正確示例
可以看到整個邏輯，經過了重新梳理。拆分成了三個函數，子方法分別去處理對應層級的邏輯，由一個主方法負責調度。整體都變得一目瞭然了。
當然，在我們基於上面的原則進行重構之後，這個代碼有沒有問題呢？當然有。可以看到我們這三個函數，都依賴了全局變量。函數本身就不純了。如果是全局的問題，還是不易於排查。
我們可以將其修改爲純函數，讓這一份代碼易於理解和測試。
以一個函數的修改爲示例：我們將 全局變量變成了參數，只需要在調用的時候，將全局變量傳入即可，但是這樣，我們得到了一個純函數。
爲什麼會在這裏特別強調這個點呢，其實在函數式編程中的一個最基礎的問題那就是純函數。只有這樣輸入輸出纔是可被觀測的，一個輸入一定會有一個輸出。也只有通過這樣的方式，才能讓系統中非純的函數越來越少。讓代碼變得更易於測試。
當然作爲我們如果以重構的角度去思考的話，我們還需要關注到這個點：
這裏的邏輯會將會 最後一個被匹配到的數據，設置爲 bgColor 。（我們都知道 find indexOf 等基本都是從前匹配。）是否真的是業務的需求呢？
可以看到將業務代碼寫好/重構的過程中其實也是對業務邏輯和業務理解的再一次提升。
不論是抽取成函數還是錯誤優先返回的設計，這其實也都是可以解決這樣一個問題：能在不去讀懂全局的情況下，瞭解某一個區域的細節邏輯，也就做到了讓代碼易於理解和修改。
... 這裏的代碼即便是經過這樣的重構後，依然有可以考慮進一步優化的空間，比如函數與參數的命名，完整的測試用例等等，受限於文章篇幅，暫不展開說明。
一些代碼中可能存在的其他問題
- 邏輯耦合在視圖層。
- a === 'a' && b ==='b' && c==='c' && d ==='d'? <div>...</div>:null
- 組件複用，函數複用，不封裝，代碼重複。
- 函數功能不單一，一個函數處理太多職責。且這些職責沒有任何關聯，但是都耦合在同一個區塊內。
- 參數列表混亂，有做好防禦編程，不處理錯誤（接口錯誤，超時，重複提交等等
- 魔法數字，魔法字符串，且沒說明。
- 糟糕數據結構 / 糟糕命名 （其實上面的具體代碼示例也存在）
關於優化代碼的思想準備
首先來說一下爲什麼會說需要優化代碼？
- 技術追求。
- 公司要求，線上有系統在用。有用戶在用，不寫好出問題實際上苦的還是自己。
- 團隊協作，我不好好寫，團隊成員其他人也不好好寫，惡性循環苦的還是自己。
- 快速迭代。系統需要不斷的增加新功能。必須要寫好代碼才能做到。
- 其他人的看法，怕別人覺得自己技術能力差... xxxx....
那麼就會有下面這些要求：
- 易於理解系統的架構
- 易於理解系統的生命週期與執行流程
- 易於理解每一個函數的作用
- 易於理解函數之間是如何調用與傳遞的（輸入輸出）
- 易於理解變量的含義，表達式的含義。
- 易於擴展...
最終實際上又回到了寫出來的代碼應該是 整潔的代碼，要使代碼易於理解/修改/測試。（這裏其實大部分時候，都隱含了一個人員協作的條件在裏面，所以，既要寫好代碼，又不能過度封裝，讓團隊其他成員看不懂（當然如果確實有些人經驗不夠，那麼是他自身的問題，需要他自己去加強。））
一些建議
- 更加清晰的去了解業務，去思考可能的變化。思考和設計清楚再動手。
- 看一些開源項目與業界最佳實踐，明白什麼樣的是好代碼，什麼樣的是不好的代碼。
- 建立明白代碼雖然是給計算機運行的，但最終還是人看的。不僅僅是沒有 bug 就行了，這樣的心智模型。
- 建立業務與代碼質量同等重要的思考模型。避免因爲時間導致的不得不這麼寫的代碼。
- 明白 code review 本身可能能發現和指出來一些問題，但最終的落實還的靠自己，不能變成形式，而是需要融合成自身的思考。
- 使用錯誤優先原則。儘可能的讓出錯的先返回， 這樣後面就會得到乾淨的代碼。（寫代碼的時候，不僅僅正向，反向的判斷也需要思考）
- 合理的拆分成獨立的函數。明確輸入輸出，錯誤處理等在函數內部的處理。（比如在一些場景中確實會存在大量邏輯判斷，首先就要思考在判斷內部的語句是否能被歸類與拆分出去）
- 對於多種狀態的判斷與組合，可以使用 組合狀態表 （map表）狀態機等模式
- 學習設計模式與重構等相關知識。
- 重構！！只要你覺得這個地方有問題了，那就不要等到以後。以後往往就是再也不。
結束
說到這可能會有一種戛然而止的感覺。在這一篇文章裏面，我們首先以兩個優化代碼的具體實例爲引子，讓大家明白了一些業務代碼的優化思路。在之後從列舉了一些其他可能出現的錯誤，以及是優化代碼的思想準備和理論指導。其實都是希望大家能夠在業務中去發現問題，再去思考如何解決問題，因爲說了那麼多，到底能不把代碼寫好，還是得靠自己。
作者：三省吾身