本文轉(zhuǎn)自公眾號：阿里技術(shù) 作者：會影
導(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ù)捺檬。
那接下來核心問題是什么？我們認(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ù)流處理最佳選項之一渡处。
慶幸的是除了 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沉填，一個常見的請求處理如下疗隶。非常冗余，這是 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 能對代碼做到更加嚴(yán)格的檢查約束。傳統(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>
除了上面講的 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 {/<strong>/}, .main-content{ /</strong>/ } }。如果有多個頂級類筋栋，可以使用 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ī)范淳附。
五议慰、嚴(yán)格徹底的 Code Review
過去的一年蠢古，我們一共進行了 1200+ 多次 Code Review(CR)，很多同事從剛開始不好意思提 MR（GitLab Merge Request别凹，Code Review 的一種方式） 到后來追著別人 Review草讶，CR 成為每個人的習(xí)慣。通過 CR 讓項目中任何一行代碼都至少被兩人觸達過番川，減少了絕大多數(shù)的低級錯誤到涂，提升了代碼質(zhì)量脊框，這也是幫助新人成長最快的方式之一颁督。
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ù)的層面，未來到一定程度會拿出來分享剔宪。
如果你也準(zhǔn)備或正在開發(fā)復(fù)雜的前端應(yīng)用拂铡，同時團隊人員多樣技術(shù)背景各異，可以參考以上5點葱绒，使用 Redux 實現(xiàn)規(guī)范清晰可預(yù)測的狀態(tài)管理感帅，深耕 TypeScript 來提升代碼健壯性和可維護性，借助各種 Lint 工具回歸簡單方便的 CSS地淀，不斷打磨自己的開發(fā)工具來保證開發(fā)規(guī)范高效失球，并嚴(yán)格徹底實行 Code Review 促進人的交流和提升。
關(guān)于本文中八個參考資料教程鏈接歡迎評論區(qū)留言或私信我帮毁！
**歡迎關(guān)注公眾號：fkdcxy 瘋狂的程序員丶 **獲取更多前端教程实苞！
