【原標(biāo)題：fetch：大前端如何與Node結(jié)合 為何差距越來越大】前端應(yīng)用越來越復(fù)雜，技術(shù)框架不斷變化，如何成為一位優(yōu)秀的前端工程師，應(yīng)對更大的挑戰(zhàn)？今天，阿里前端技術(shù)專家會影結(jié)合實(shí)際工作經(jīng)驗(yàn)，沉淀了五項(xiàng)重要方法，希望能對你的職業(yè)發(fā)展、團(tuán)隊(duì)協(xié)作有所啟發(fā)。來源 | 阿里技術(shù)責(zé)編 | Rainie Liu

過去一年，阿里巴巴新零售事業(yè)群支撐的數(shù)據(jù)相關(guān)業(yè)務(wù)突飛猛進(jìn)，其中兩個核心平臺級產(chǎn)品代碼量急速增長，協(xié)同開發(fā)人員增加到數(shù)十人。

由于歷史原因，開發(fā)框架同時基于 React 和 Angular，考慮到產(chǎn)品的復(fù)雜性、人員的短缺和技術(shù)背景各異，我們嘗試了各種方法打磨工具體系來提升開發(fā)效率，以下分享五點(diǎn)。

一、基于 Redux 的狀態(tài)管理從 2013 年 React 發(fā)布至今已近 6 個年頭，前端框架逐漸形成 React/Vue/Angular 三足鼎立之勢。幾年前還在爭論單向綁定和雙向綁定孰優(yōu)孰劣，現(xiàn)在三大框架已經(jīng)不約而同選擇單向綁定，雙向綁定淪為單純的語法糖。框架間的差異越來越小，加上 Ant-Design/Fusion-Design/NG-ZORRO/ElementUI 組件庫的成熟，選擇任一你熟悉的框架都能高效完成業(yè)務(wù)。

那接下來核心問題是什么？我們認(rèn)為是狀態(tài)管理。簡單應(yīng)用使用組件內(nèi) State 方便快捷，但隨著應(yīng)用復(fù)雜度上升，會發(fā)現(xiàn)數(shù)據(jù)散落在不同的組件，組件通信會變得異常復(fù)雜。我們先后嘗試過原生 Redux、分形 Fractal 的思路、自研類 Mobx 框架、Angular Service，最終認(rèn)為 Redux 依舊是復(fù)雜應(yīng)用數(shù)據(jù)流處理最佳選項(xiàng)之一。

慶幸的是除了 React 社區(qū)，Vue 社區(qū)有類似的 Vuex，Angular 社區(qū)有 NgRx 也提供了幾乎同樣的能力，甚至 NgRx 還可以無縫使用 redux-devtools 來調(diào)試狀態(tài)變化。

無論如何優(yōu)化，始終要遵循 Redux 三原則：

這三個問題我們是通過自研 iron-redux 庫【1】來解決，以下是背后的思考：

如何組織 Action？

action type 需要全局惟一，因此我們給 action type 添加了 prefix，其實(shí)就是 namespace 的概念；

為了追求體驗(yàn)，請求（Fetch）場景需要處理 3 種狀態(tài)，對應(yīng) LOADING/SUCCESS/ERROR 這 3 個 action，我們通過 FetchTypes 類型來自動生成對應(yīng)到 3 個 action。

如何組織 Store/Reducer？

reducer 和 view 不必一一對應(yīng)，應(yīng)用中同時存在組件樹和狀態(tài)樹，按照各自需要去組織，通過 connect 來綁定狀態(tài)樹的一個或多個分支到組件樹；

通過構(gòu)造一些預(yù)設(shè)數(shù)據(jù)類型來減少樣板代碼。對于 Fetch 返回的數(shù)據(jù)我們定義了 AsyncTuple 這種類型，減少了樣板代碼；

明確的組織結(jié)構(gòu)，第 1 層是 ROOT，第 2 層是各個頁面，第 3 層是頁面內(nèi)的卡片，第 4 層是卡片的數(shù)據(jù)，這樣劃分最深處基本不會超過 5 層。

最終我們得到如下扁平的狀態(tài)樹。雖龐大但有序，你可以快速而明確的訪問任何數(shù)據(jù)。

Redux 狀態(tài)樹

如何減少樣板代碼？

使用原生 Redux，一個常見的請求處理如下。非常冗余，這是 Redux 被很多人詬病的原因：

使用 iron-redux 后：

代碼量減少三分之二！！

主要做了這 2 點(diǎn)：

引入了預(yù)設(shè)的 AsyncTuple 類型，就是 {data: [], loading: boolean, error: boolean} 這樣的數(shù)據(jù)結(jié)構(gòu)；

使用 AsyncTuple.handleAll 處理 LOADING/SUCCESS/ERROR 這 3 種 action，handleAll 的代碼很簡單，使用 if 判斷 action.type 的后綴即可，源碼【2】。

曾經(jīng) React 和 Angular 是兩個很難調(diào)和的框架，開發(fā)中浪費(fèi)了我們大量的人力。通過使用輕量級的 iron-redux，完全遵循 Redux 核心原則下，我們內(nèi)部實(shí)現(xiàn)了除組件層以外幾乎所有代碼的復(fù)用。開發(fā)規(guī)范、工具庫達(dá)成一致，開發(fā)人員能夠無縫切換，框架差異帶來的額外成本降到很低。

二、全面擁抱 TypeScriptTypeScript 目前可謂大紅大紫，根據(jù) 2018 stateofjs【3】，超過 50% 的使用率以及 90% 的滿意度，甚至連 Jest 也正在從 Flow 切換到 TS【4】。如果你還沒有

使用，可以考慮切換，絕對能給項(xiàng)目帶來很大提升。過去一年，我們從部分使用 TS 變?yōu)槿媲袚Q到 TS，包括我們自己開發(fā)的工具庫等。

TS 最大的優(yōu)勢是它提供了強(qiáng)大的靜態(tài)分析能力，結(jié)合 TSLint 能對代碼做到更加嚴(yán)格的檢查約束。傳統(tǒng)的 EcmaScript 由于沒有靜態(tài)類型，即使有了 ESLint 也只能做到很基本的檢查，一些 typo 問題可能線上出了 Bug 后才被發(fā)現(xiàn)。

下圖是一個前端應(yīng)用常見的 4 層架構(gòu)。 代碼和工具全面擁抱 TS 后，實(shí)現(xiàn)了從后端 API 接口到 View 組件的全鏈路靜態(tài)分析，具有了完善的代碼提示和校驗(yàn)?zāi)芰Α?/p>

除了上面講的 iron-redux，我們還引入 Pont 【5】實(shí)現(xiàn)前端取數(shù)，它可以自動把后端 API 映射到前端可調(diào)用的請求方法。

Pont 實(shí)現(xiàn)原理：（法語：橋） 是我們研發(fā)的前端取數(shù)層框架。對接的后端 API 使用 Java Swagger，Swagger 能提供所有 API 的元信息，包括請求和響應(yīng)的類型格式。Pont 解析 API 元信息生成 TS 的取數(shù)函數(shù)，這些取數(shù)函數(shù)類型完美，并掛載到 API 模塊下。最終代碼中取數(shù)效果是這樣的：

Pont 實(shí)現(xiàn)的效果有：

根據(jù)方法名自動匹配 url、method，并且對應(yīng)到 prams、response 類型完美，并能自動提示；

后端 API 接口變更后，前端相關(guān)聯(lián)的請求會自動報錯，再也不擔(dān)心后端悄悄改接口前端不知曉；

再也不需要前后端接口約定文檔，使用代碼保證前端取數(shù)和后端接口定義完全一致。

另外 iron-redux 能接收到 Pont 接口響應(yīng)數(shù)據(jù)格式，并推導(dǎo)出整個 Redux 狀態(tài)樹的靜態(tài)類型定義，Store 中的數(shù)據(jù)完美的類型提示。效果如下：

最終 TS 讓代碼更加健壯，尤其是對于大型項(xiàng)目，編譯通過幾乎就代表運(yùn)行正常，也給重構(gòu)增加了很多信心。

三、回歸 Sass/Less2015 年我們就開始實(shí)踐 CSS Modules，包括后來的 styled-components 等，到 2019 年 css-in-js 方案依舊爭論不休，雖然它確實(shí)解決了一些 CSS 語言天生的問題，但同時增加了不少成本，新手不夠友好、全局樣式覆蓋成本高漲、偽類處理復(fù)雜、與 AntD 等組件庫結(jié)合有坑。與此同時 Sass/Less 社區(qū)也在飛速發(fā)展，尤其是 Stylelint 【6】的成熟，可以通過技術(shù)約束的手段來避免 CSS 的 Bad Parts。

全局污染：約定每個樣式文件只能有一個頂級類，如 .home-page{ .top-nav {//}, .main-content{ // } }。如果有多個頂級類，可以使用 Stylelint rule 檢測并給出警告。

依賴管理不徹底。借助 webpack 的 css-loader，已夠用。

JS 和 CSS 變量共享。

關(guān)于 JS 和 Sass/Less 變量共享，我們摸索出了自己的解法：

在 scss 文件中，可以直接引用變量：

四、開發(fā)工具覆蓋全鏈路2019 年，你幾乎不可能再開發(fā)出 React/Angular/Vue 級別的框架，也沒必要再造 Ant-Design/Fusion-Design/Ng-Zorro 這樣的輪子。難道就沒有機(jī)會了嗎？

當(dāng)然有，結(jié)合你自身的產(chǎn)品開發(fā)流程，依舊有很多機(jī)會。下面是常規(guī)項(xiàng)目的開發(fā)流程圖，任何一個環(huán)節(jié)只要深挖，都有提升空間。如果你能通過工具減少一個或多個環(huán)節(jié)，帶來的價值更大。

單拿其中的【開發(fā)】環(huán)節(jié)展開，就有很多可擴(kuò)展的場景：

一個有代表性的例子是，我們開發(fā)了國際化工具 kiwi【7】。它同樣具有 TS 的類型完美，非常強(qiáng)大的文案提示，另外還有：

VS Code 插件 kiwi linter【8】，自動對中文文案標(biāo)紅，如果已有翻譯文案能自動完成替換；

Shell 命令全量檢查出沒有翻譯的文案，批量提交給翻譯人員；

Codemod 腳本自動實(shí)現(xiàn)舊的國際化方案向 Kiwi 遷移，成本極低。

除了以上三點(diǎn)，未來還計劃開發(fā)瀏覽器插件來檢查漏翻文案，利用 Husky 在 git 提交前對漏翻文案自動做機(jī)器翻譯等等。

未來如果你只提供一個代碼庫，那它的價值會非常局限。你可以參照上面的圖表，開發(fā)相應(yīng)的擴(kuò)展來豐富生態(tài)。如果你是新手，推薦學(xué)習(xí)下編譯原理和對應(yīng)的擴(kuò)展開發(fā)規(guī)范。

五、嚴(yán)格徹底的 Code Review過去的一年，我們一共進(jìn)行了 1200+ 多次 Code Review(CR)，很多同事從剛開始不好意思提 MR（GitLab Merge Request，Code Review 的一種方式） 到后來追著別人 Review，CR 成為每個人的習(xí)慣。通過 CR 讓項(xiàng)目中任何一行代碼都至少被兩人觸達(dá)過，減少了絕大多數(shù)的低級錯誤，提升了代碼質(zhì)量，這也是幫助新人成長最快的方式之一。

其中一個項(xiàng)目 MR 截圖

Code Review 的幾個技巧：

No magic；

Explicit not implicit；

覆蓋度比深度重要，覆蓋度追求 100%；

頻率比儀式感重要，坐公交蹲廁所打開手機(jī)都可以 Review 別人代碼，不需要專門組織會議；

粒度要盡可能小，一個組件一個方法均可，可以結(jié)合 Git Flow；

24h 小時內(nèi)處理，無問題直接 merge，有問題一定要留 comment，并且提供 action；

對于亟待上線來不及 Review 的代碼，可以先合并上線，上線后再補(bǔ)充 Review；

需要自上而下的推動，具有完善的規(guī)范，同時定期總結(jié) Review 經(jīng)驗(yàn)來豐富開發(fā)規(guī)范；

CR 并不只是為了找錯，看到好的代碼，不要吝嗇你的贊美；

本質(zhì)是鼓勵開發(fā)者間更多的溝通，互相學(xué)習(xí)，營造技術(shù)文化氛圍。

總結(jié)以上 5 點(diǎn)當(dāng)然不是我們技術(shù)的全部。除此之外我們還實(shí)踐了移動端開發(fā)、可視化圖表 /WebGL、Web Worker、GraphQL、性能優(yōu)化等等，但這些還停留在術(shù)的層面，未來到一定程度會拿出來分享。

如果你也準(zhǔn)備或正在開發(fā)復(fù)雜的前端應(yīng)用，同時團(tuán)隊(duì)人員多樣技術(shù)背景各異，可以參考以上 5 點(diǎn)，使用 Redux 實(shí)現(xiàn)規(guī)范清晰可預(yù)測的狀態(tài)管理，深耕 TypeScript 來提升代碼健壯性和可維護(hù)性，借助各種 Lint 工具回歸簡單方便的 CSS，不斷打磨自己的開發(fā)工具來保證開發(fā)規(guī)范高效，并嚴(yán)格徹底實(shí)行 Code Review 促進(jìn)人的交流和提升。