前端應(yīng)用越來(lái)越復(fù)雜，技術(shù)框架不斷變化，如何成為一位優(yōu)秀的前端工程師，應(yīng)對(duì)更大的挑戰(zhàn)?今天，阿里前端技術(shù)專(zhuān)家會(huì)影結(jié)合實(shí)際工作經(jīng)驗(yàn)，沉淀了五項(xiàng)重要方法，希望能對(duì)你的職業(yè)發(fā)展、團(tuán)隊(duì)協(xié)作有所啟發(fā)。

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

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

?[[258963]]??

一、基于 Redux 的狀態(tài)管理

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

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

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

???

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

???

這三個(gè)問(wèn)題我們是通過(guò)自研 iron-redux 庫(kù)【1】來(lái)解決，以下是背后的思考：

如何組織 Action?

1. action type 需要全局惟一，因此我們給 action type 添加了 prefix，其實(shí)就是 namespace 的概念;
2. 為了追求體驗(yàn)，請(qǐng)求(Fetch)場(chǎng)景需要處理 3 種狀態(tài)，對(duì)應(yīng) LOADING/SUCCESS/ERROR 這 3 個(gè)action，我們通過(guò) FetchTypes 類(lèi)型來(lái)自動(dòng)生成對(duì)應(yīng)到 3 個(gè) action。

如何組織 Store/Reducer?

1. reducer 和 view 不必一一對(duì)應(yīng)，應(yīng)用中同時(shí)存在組件樹(shù)和狀態(tài)樹(shù)，按照各自需要去組織，通過(guò) connect 來(lái)綁定狀態(tài)樹(shù)的一個(gè)或多個(gè)分支到組件樹(shù);
2. 通過(guò)構(gòu)造一些預(yù)設(shè)數(shù)據(jù)類(lèi)型來(lái)減少樣板代碼。對(duì)于 Fetch 返回的數(shù)據(jù)我們定義了 AsyncTuple 這種類(lèi)型，減少了樣板代碼;
3. 明確的組織結(jié)構(gòu)，第1層是 ROOT，第2層是各個(gè)頁(yè)面，第3層是頁(yè)面內(nèi)的卡片，第4層是卡片的數(shù)據(jù)，這樣劃分最深處基本不會(huì)超過(guò)5層。

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

???

Redux 狀態(tài)樹(shù)

如何減少樣板代碼?

使用原生 Redux，一個(gè)常見(jiàn)的請(qǐng)求處理如下。非常冗余，這是 Redux 被很多人詬病的原因：

???

使用 iron-redux 后：

???

代碼量減少三分之二!!

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

1. 引入了預(yù)設(shè)的 AsyncTuple 類(lèi)型，就是 {data: [], loading: boolean, error: boolean} 這樣的數(shù)據(jù)結(jié)構(gòu);
2. 使用 AsyncTuple.handleAll 處理 LOADING/SUCCESS/ERROR 這 3 種 action，handleAll 的代碼很簡(jiǎn)單，使用 if 判斷 action.type 的后綴即可，源碼【2】。

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

二、全面擁抱 TypeScript

TypeScript 目前可謂大紅大紫，根據(jù) 2018 stateofjs【3】，超過(guò) 50% 的使用率以及 90% 的滿(mǎn)意度，甚至連 Jest 也正在從 Flow 切換到 TS【4】。如果你還沒(méi)有

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

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

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

???

前后端協(xié)作簡(jiǎn)圖

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

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

???

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

1. 根據(jù)方法名自動(dòng)匹配 url、method，并且對(duì)應(yīng)到 prams、response 類(lèi)型完美，并能自動(dòng)提示;
2. 后端 API 接口變更后，前端相關(guān)聯(lián)的請(qǐng)求會(huì)自動(dòng)報(bào)錯(cuò)，再也不擔(dān)心后端悄悄改接口前端不知曉;
3. 再也不需要前后端接口約定文檔，使用代碼保證前端取數(shù)和后端接口定義完全一致。

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

???

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

三、回歸 Sass/Less

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

1. 全局污染：約定每個(gè)樣式文件只能有一個(gè)頂級(jí)類(lèi)，如 .home-page{ .top-nav {//}, .main-content{ // } }。如果有多個(gè)頂級(jí)類(lèi)，可以使用 Stylelint rule 檢測(cè)并給出警告。
2. 依賴(lài)管理不徹底。借助 webpack 的 css-loader，已夠用。
3. JS 和 CSS 變量共享。關(guān)于 JS 和 Sass/Less 變量共享，我們摸索出了自己的解法：

???

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

???

四、開(kāi)發(fā)工具覆蓋全鏈路

2019 年，你幾乎不可能再開(kāi)發(fā)出 React/Angular/Vue 級(jí)別的框架，也沒(méi)必要再造 Ant-Design/Fusion-Design/Ng-Zorro 這樣的輪子。難道就沒(méi)有機(jī)會(huì)了嗎?

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

???

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

???

一個(gè)有代表性的例子是，我們開(kāi)發(fā)了國(guó)際化工具 kiwi【7】。它具有非常強(qiáng)大的文案提示，另外還有：

1. VS Code 插件 kiwi linter【8】，自動(dòng)對(duì)中文文案標(biāo)紅，如果已有翻譯文案能自動(dòng)完成替換;
2. Shell 命令全量檢查出沒(méi)有翻譯的文案，批量提交給翻譯人員;
3. Codemod 腳本自動(dòng)實(shí)現(xiàn)舊的國(guó)際化方案向 Kiwi 遷移，成本極低。

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

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

五、嚴(yán)格徹底的 Code Review

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

???

[其中一個(gè)項(xiàng)目MR截圖]

Code Review 的幾個(gè)技巧：

1. No magic;
2. Explicit not implicit;
3. 覆蓋度比深度重要，覆蓋度追求100%;
4. 頻率比儀式感重要，坐公交蹲廁所打開(kāi)手機(jī)都可以 Review 別人代碼，不需要專(zhuān)門(mén)組織會(huì)議;
5. 粒度要盡可能小，一個(gè)組件一個(gè)方法均可，可以結(jié)合 Git Flow;
6. 24h 小時(shí)內(nèi)處理，無(wú)問(wèn)題直接 merge，有問(wèn)題一定要留 comment，并且提供 action;
7. 對(duì)于亟待上線來(lái)不及 Review 的代碼，可以先合并上線，上線后再補(bǔ)充 Review;
8. 需要自上而下的推動(dòng)，具有完善的規(guī)范，同時(shí)定期總結(jié) Review 經(jīng)驗(yàn)來(lái)豐富開(kāi)發(fā)規(guī)范;
9. CR 并不只是為了找錯(cuò)，看到好的代碼，不要吝嗇你的贊美;
10. 本質(zhì)是鼓勵(lì)開(kāi)發(fā)者間更多的溝通，互相學(xué)習(xí)，營(yíng)造技術(shù)文化氛圍。

總結(jié)

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

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

阿里數(shù)據(jù)技術(shù)及產(chǎn)品部(DT)正在招聘前端開(kāi)發(fā)工程師，這里有豐富海量的數(shù)據(jù)和前端應(yīng)用場(chǎng)景，如果你對(duì)文中提到的5點(diǎn)深有感觸，渴望快速成長(zhǎng)，歡迎和我聯(lián)系：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