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

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

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

?

一、基于 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ù)。

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

慶幸的是除了 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，其實就是 namespace 的概念；

為了追求體驗，請求（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點：

引入了預(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ā)中浪費了我們大量的人力。通過使用輕量級的 iron-redux，完全遵循 Redux 核心原則下，我們內(nèi)部實現(xiàn)了除組件層以外幾乎所有代碼的復(fù)用。開發(fā)規(guī)范、工具庫達成一致，開發(fā)人員能夠無縫切換，框架差異帶來的額外成本降到很低。

二、全面擁抱 TypeScript

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

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

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

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

前后端協(xié)作簡圖

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

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

Pont 實現(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 讓代碼更加健壯，尤其是對于大型項目，編譯通過幾乎就代表運行正常，也給重構(gòu)增加了很多信心。

三、回歸 Sass/Less

2015 年我們就開始實踐 CSS Modules，包括后來的 styled-components 等，到 2019 年 css-in-js 方案依舊爭論不休，雖然它確實解決了一些 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 這樣的輪子。難道就沒有機會了嗎？

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

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

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

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

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

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

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

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

五、嚴格徹底的 Code Review

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

[其中一個項目MR截圖]

Code Review 的幾個技巧：

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

總結(jié)

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

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

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的同样做前端，为何差距越来越大？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。