進階 | 同樣做前端，為何差距越來越大？
前端應用越來越復雜，技術框架不斷變化，如何成為一位優秀的前端工程師，應對更大的挑戰?今天，阿里前端技術專家會影結合實際工作經驗，沉淀了五項重要方法，希望能對你的職業發展、團隊協作有所啟發。
過去一年，阿里巴巴新零售事業群支撐的數據相關業務突飛猛進，其中兩個核心平臺級產品代碼量急速增長，協同開發人員增加到數十人。
由于歷史原因，開發框架同時基于 React 和 Angular，考慮到產品的復雜性、人員的短缺和技術背景各異，我們嘗試了各種方法打磨工具體系來提升開發效率，以下分享五點。
???
一、基于 Redux 的狀態管理
從2013年React發布至今已近6個年頭，前端框架逐漸形成 React/Vue/Angular 三足鼎立之勢。幾年前還在爭論單向綁定和雙向綁定孰優孰劣，現在三大框架已經不約而同選擇單向綁定，雙向綁定淪為單純的語法糖。框架間的差異越來越小，加上 Ant-Design/Fusion-Design/NG-ZORRO/ElementUI 組件庫的成熟，選擇任一你熟悉的框架都能高效完成業務。
那接下來核心問題是什么?我們認為是狀態管理。簡單應用使用組件內 State 方便快捷，但隨著應用復雜度上升，會發現數據散落在不同的組件，組件通信會變得異常復雜。我們先后嘗試過原生 Redux、分形 Fractal 的思路、自研類 Mobx 框架、Angular Service，最終認為 Redux 依舊是復雜應用數據流處理較好選項之一。
慶幸的是除了 React 社區，Vue 社區有類似的 Vuex，Angular 社區有 NgRx 也提供了幾乎同樣的能力，甚至 NgRx 還可以無縫使用 redux-devtools 來調試狀態變化。
?
??
無論如何優化，始終要遵循 Redux 三原則：
?
??
這三個問題我們是通過自研 iron-redux 庫【1】來解決，以下是背后的思考：
如何組織 Action?
- action type 需要全局惟一，因此我們給 action type 添加了 prefix，其實就是 namespace 的概念;
- 為了追求體驗，請求(Fetch)場景需要處理 3 種狀態，對應 LOADING/SUCCESS/ERROR 這 3 個action，我們通過 FetchTypes 類型來自動生成對應到 3 個 action。
如何組織 Store/Reducer?
- reducer 和 view 不必一一對應，應用中同時存在組件樹和狀態樹，按照各自需要去組織，通過 connect 來綁定狀態樹的一個或多個分支到組件樹;
- 通過構造一些預設數據類型來減少樣板代碼。對于 Fetch 返回的數據我們定義了 AsyncTuple 這種類型，減少了樣板代碼;
- 明確的組織結構，第1層是 ROOT，第2層是各個頁面，第3層是頁面內的卡片，第4層是卡片的數據，這樣劃分最深處基本不會超過5層。
最終我們得到如下扁平的狀態樹。雖龐大但有序，你可以快速而明確的訪問任何數據。
?
??
Redux 狀態樹
如何減少樣板代碼?
使用原生 Redux，一個常見的請求處理如下。非常冗余，這是 Redux 被很多人詬病的原因：
?
??
使用 iron-redux 后：
?
??
代碼量減少三分之二!!
主要做了這2點：
- 引入了預設的 AsyncTuple 類型，就是 {data: [], loading: boolean, error: boolean} 這樣的數據結構;
- 使用 AsyncTuple.handleAll 處理 LOADING/SUCCESS/ERROR 這 3 種 action，handleAll 的代碼很簡單，使用 if 判斷 action.type 的后綴即可，源碼【2】。
曾經 React 和 Angular 是兩個很難調和的框架，開發中浪費了我們大量的人力。通過使用輕量級的 iron-redux，完全遵循 Redux 核心原則下，我們內部實現了除組件層以外幾乎所有代碼的復用。開發規范、工具庫達成一致，開發人員能夠無縫切換，框架差異帶來的額外成本降到很低。
二、全面擁抱 TypeScript
TypeScript 目前可謂大紅大紫，根據 2018 stateofjs【3】，超過 50% 的使用率以及 90% 的滿意度，甚至連 Jest 也正在從 Flow 切換到 TS【4】。如果你還沒有
使用，可以考慮切換，絕對能給項目帶來很大提升。過去一年，我們從部分使用 TS 變為全面切換到 TS，包括我們自己開發的工具庫等。
TS 突出的優勢是它提供了強大的靜態分析能力，結合 TSLint 能對代碼做到更加嚴格的檢查約束。傳統的 EcmaScript 由于沒有靜態類型，即使有了 ESLint 也只能做到很基本的檢查，一些 typo 問題可能線上出了 Bug 后才被發現。
下圖是一個前端應用常見的4層架構。 代碼和工具全面擁抱 TS 后，實現了從后端 API 接口到 View 組件的全鏈路靜態分析，具有了完善的代碼提示和校驗能力。
?
??
前后端協作簡圖
除了上面講的 iron-redux，我們還引入 Pont 【5】實現前端取數，它可以自動把后端 API 映射到前端可調用的請求方法。
Pont 實現原理：(法語：橋) 是我們研發的前端取數層框架。對接的后端 API 使用 Java Swagger，Swagger 能提供所有 API 的元信息，包括請求和響應的類型格式。Pont 解析 API 元信息生成 TS 的取數函數，這些取數函數類型理想，并掛載到 API 模塊下。最終代碼中取數效果是這樣的：
?
??
Pont 實現的效果有：
- 根據方法名自動匹配 url、method，并且對應到 prams、response 類型完美，并能自動提示;
- 后端 API 接口變更后，前端相關聯的請求會自動報錯，再也不擔心后端悄悄改接口前端不知曉;
- 再也不需要前后端接口約定文檔，使用代碼保證前端取數和后端接口定義完全一致。
另外 iron-redux 能接收到 Pont 接口響應數據格式，并推導出整個 Redux 狀態樹的靜態類型定義，Store 中的數據類型提示。效果如下：
?
??
最終 TS 讓代碼更加健壯，尤其是對于大型項目，編譯通過幾乎就代表運行正常，也給重構增加了很多信心。
三、回歸 Sass/Less
2015 年我們就開始實踐 CSS Modules，包括后來的 styled-components 等，到 2019 年 css-in-js 方案依舊爭論不休，雖然它確實解決了一些 CSS 語言天生的問題，但同時增加了不少成本，新手不夠友好、全局樣式覆蓋成本高漲、偽類處理復雜、與AntD等組件庫結合有坑。與此同時 Sass/Less 社區也在飛速發展，尤其是 Stylelint 【6】的成熟，可以通過技術約束的手段來避免 CSS 的 Bad Parts。
- 全局污染：約定每個樣式文件只能有一個頂級類，如 .home-page{ .top-nav {//}, .main-content{ // } }。如果有多個頂級類，可以使用 Stylelint rule 檢測并給出警告。
- 依賴管理不徹底。借助 webpack 的 css-loader，已夠用。
- JS 和 CSS 變量共享。關于 JS 和 Sass/Less 變量共享，我們摸索出了自己的解法：
?
??
在 scss 文件中，可以直接引用變量：
?
??
四、開發工具覆蓋全鏈路
2019 年，你幾乎不可能再開發出 React/Angular/Vue 級別的框架，也沒必要再造 Ant-Design/Fusion-Design/Ng-Zorro 這樣的輪子。難道就沒有機會了嗎?
當然有，結合你自身的產品開發流程，依舊有很多機會。下面是常規項目的開發流程圖，任何一個環節只要深挖，都有提升空間。如果你能通過工具減少一個或多個環節，帶來的價值更大。
?
??
單拿其中的【開發】環節展開，就有很多可擴展的場景：
?
??
一個有代表性的例子是，我們開發了國際化工具 kiwi【7】。它具有非常強大的文案提示，另外還有：
- VS Code 插件 kiwi linter【8】，自動對中文文案標紅，如果已有翻譯文案能自動完成替換;
- Shell 命令全量檢查出沒有翻譯的文案，批量提交給翻譯人員;
- Codemod 腳本自動實現舊的國際化方案向 Kiwi 遷移，成本極低。
除了以上三點，未來還計劃開發瀏覽器插件來檢查漏翻文案，利用 Husky 在 git 提交前對漏翻文案自動做機器翻譯等等。
未來如果你只提供一個代碼庫，那它的價值會非常局限。你可以參照上面的圖表，開發相應的擴展來豐富生態。如果你是新手，推薦學習下編譯原理和對應的擴展開發規范。
五、嚴格徹底的 Code Review
過去的一年，我們一共進行了 1200+ 多次 Code Review(CR)，很多同事從剛開始不好意思提 MR(GitLab Merge Request，Code Review 的一種方式) 到后來追著別人 Review，CR 成為每個人的習慣。通過 CR 讓項目中任何一行代碼都至少被兩人觸達過，減少了絕大多數的低級錯誤，提升了代碼質量，這也是幫助新人成長最快的方式之一。
?
??
[其中一個項目MR截圖]
Code Review 的幾個技巧：
- No magic;
- Explicit not implicit;
- 覆蓋度比深度重要，覆蓋度追求100%;
- 頻率比儀式感重要，坐公交蹲廁所打開手機都可以 Review 別人代碼，不需要專門組織會議;
- 粒度要盡可能小，一個組件一個方法均可，可以結合 Git Flow;
- 24h 小時內處理，無問題直接 merge，有問題一定要留 comment，并且提供 action;
- 對于亟待上線來不及 Review 的代碼，可以先合并上線，上線后再補充 Review;
- 需要自上而下的推動，具有完善的規范，同時定期總結 Review 經驗來豐富開發規范;
- CR 并不只是為了找錯，看到好的代碼，不要吝嗇你的贊美;
- 本質是鼓勵開發者間更多的溝通，互相學習，營造技術文化氛圍。
總結
以上5點當然不是我們技術的全部。除此之外我們還實踐了移動端開發、可視化圖表/WebGL、Web Worker、GraphQL、性能優化等等，但這些還停留在術的層面，未來到一定程度會拿出來分享。
如果你也準備或正在開發復雜的前端應用，同時團隊人員多樣技術背景各異，可以參考以上5點，使用 Redux 實現規范清晰可預測的狀態管理，深耕 TypeScript 來提升代碼健壯性和可維護性，借助各種 Lint 工具回歸簡單方便的 CSS，不斷打磨自己的開發工具來保證開發規范高效，并嚴格徹底實行 Code Review 促進人的交流和提升。
阿里數據技術及產品部(DT)正在招聘前端開發工程師，這里有豐富海量的數據和前端應用場景，如果你對文中提到的5點深有感觸，渴望快速成長，歡迎和我聯系：shaoyin.ssy@alibaba-inc.com
參考資料:
1.https://github.com/nefe/iron-redux
2.https://github.com/nefe/iron-redux/blob/master/index.ts#L288
3.https://2018.stateofjs.com/javascript-flavors/overview/
4.https://github.com/facebook/jest/pull/7554
5.https://github.com/nefe/pont
6.https://stylelint.io/
7.https://github.com/nefe/kiwi
8.https://marketplace.visualstudio.com/items?itemName=undefinedvs.vscode-i18n-linter
