成爲一名前端架構師

前言

你是一位經驗豐富的前端開發，你的經驗和能力在不斷成長。有一天，公司決定任命你爲前端架構師。你躊躇滿志決定大展身手，然而，一個問題困擾了你。

什麼是前端架構，前端架構師的職責是什麼？

今天，讓咱們從多個角度來看看什麼是前端開發，什麼是前端架構。

前端開發是什麼

首先，讓咱們來回顧一下近年來前端開發所走過的一些歷程，瞭解什麼是「前端開發」。

三駕馬車

HTML、JS、CSS是前端的三駕馬車，是前端最重要的組成部分。

HTML是前端的入口，一切從瀏覽器加載HTML文檔開始。隨後瀏覽器解析HTML文檔，並加載相應的JS與CSS文件並解析執行。

CSS負責修改文檔的展示樣式，JS則經過偵聽用戶行爲、修改文檔內容以及修改元素展示樣式來提供豐富的內容展示以及用戶交互行爲。

DOM & BOM

DOM（文檔對象模型）和BOM（瀏覽器對象模型）是瀏覽器提供給JS的一系列接口。JS能夠經過這些接口與瀏覽器/文檔交互，例如添加用戶交互監聽、修改文檔內容等等。

DOM包括與文檔相關的接口，例如查找元素、遍歷文檔、修改文檔內容等。BOM則提供了許多其餘的功能，例如添加定時器、獲取當前頁面地址等等。

ECMAScript

ECMAScript是JS的標準，JS是ECMAScript的實現與擴展。從ES6版本開始，大量新特性的加入與演進，標誌着JS的發展進入了一個新的時代。

對於一個新特性而言，將經歷如下幾個階段：stage0（內部提議）、stage1（正式提案）、stage2（規範草案）、stage3（候選，部分瀏覽器已經實現該功能並獲取用戶反饋）、stage4（就緒，進入下個版本的ES規範）。

ES6+的出現爲JS引入了許多優秀的語言特性，例如let/const提供了更好的變量/常量申明方式，Promise/async/await解決了回調地獄問題，class提供了更好的面向對象範式，ES modules提供了模塊化的新標準。除此以外還有Proxy、Symbol、Map/Set等等特性一樣值得關注。

瀏覽器

瀏覽器是前端的主要載體。瀏覽器主要包括用戶界面、渲染引擎、JS引擎、網絡、數據持久層等組件。

nodejs

nodejs使用了JS的語法規範，並在其上提供了包括網絡/文件IO在內的系統交互能力。官方的nodejs是構建在Chrome v8引擎上的JS運行時。

npm最初是針對nodejs設計的依賴管理工具，而現在npm/yarn已經統一了web與nodejs的包管理。

web2.0

web2.0表明着門戶網站向網站應用的轉型。網站應用提供豐富的交互並且僅靜態的信息展現。UGC（用戶生成內容）的大量產生也是web2.0的標誌之一。

這一時代標誌性的技術包括jQuery、AJAX和先後端分離。

jQuery大大下降了瀏覽性兼容性帶來的開發成本，同時sizzle提供的以css selector查詢元素的方式大大提升了前端開發效率。隨之而來的是構建在jQuery之上的前端組件庫的大量出現，大大豐富了前端交互的可能性。即便隨着新API的出現和瀏覽器兼容性的提高，現在jQuery已非主流，但其鏈式（fluent API）、集合操做、事件代理、構造函數重載等設計模式的靈活應用仍然值得咱們學習與借鑑，更不用sizzle和jQuery對於前端發展的巨大推進。

AJAX容許前端向後臺發起異步請求並更新數據，打破了本來必須向後臺提交表單並最終請求新頁面的模式。在以後的日子裏，SPA（單頁面應用）應運而生。

而在AJAX以後，web socket和web RTC進一步擴展了瀏覽器與服務器的通訊方式。前者賦予了web實時通訊的能力，然後者提供了實時語音/視頻的功能。

隨着前端庫的大量出現、前端交互變得愈加複雜，先後端分離的概念開始興起。從總體的架構視角來看，這對應的是軟件分層架構（表現層，業務層，持久層等等）的出現。如同康威定律所述，人員架構也在相應變化：前端開發、後端開發、DBA等等。

頁面模板的編寫慢慢從後端開發手中交到了前端開發手中，在此時，包括handlebar、mustache在內的基於字符串拼接的前端模板庫出現。

HTML5 & CSS3

HTML5表明HTML規範的5.x版本，與2008年發佈正式版，與2014年最終定稿。因爲其發展歷程與移動互聯網高度重合，H5一詞漸漸成爲了「移動web網頁/網站/應用」的代名詞。

HTML5規範爲web帶來了許多新特性，包括更多語義化的標籤，更豐富的表單項，canvas/WebGL，多媒體（web、audio）、地理定位、數據存儲（localstorage、web SQL）、多線程（web worker）等等。

而與2010年正式推出的css3規範一樣帶來了media query、圓角、漸變、陰影、變形、動效/動畫等一系列新特性。

爲了應對紛繁的手機屏幕尺寸，media query與box-sizing、rem分別推進了響應式和自適應兩大設計理念的發展。同時爲了應對兼容性不一的問題，相似Modernizr、html5shiv這樣的工具也應運而生。

HTML5與css3的誕生使得移動web開發如虎添翼，多媒體、富交互時代正式來臨。

依賴管理

隨着前端代碼愈加龐大，一個交互複雜的頁面極可能包含大量依賴。要管理並理清這些依賴（js、css）並不容易。

面對這一問題，bower和require.js應運而生。

bower是面向web的包管理工具，經過bower咱們能夠追蹤項目依賴庫，並在新環境下檢出項目時一鍵安裝全部依賴。最終隨着npm/yarn統一了web和nodejs的包管理，bower慢慢退出歷史舞臺。

在bower處理包管理的同時，require.js則致力於理清依賴關係。require.js經過異步加載依賴（js/css）使得樹狀的依賴最終收斂於根節點，樹上的每一個節點只須要關心本身的依賴。若是一個節點被複用，依賴子樹會一塊兒複用，而無需再檢查依賴。最終頁面所須要關心的，則僅剩依賴的根節點以及require.js自己。

編譯/轉譯

在前端領域，編譯/轉譯的概念首次獲得關注或許該歸功於coffee script和less（sass、stylus）的出現。

二者最終會被轉換爲js和css，而在此以前它們爲語法添加了許多實用的功能，大大提升了開發效率。

除了coffee script和less以外，語法檢測工具（eslint、tslint、csslint等）、代碼壓縮/合併工具等等也是創建在相同的技術基礎之上。

現在做爲後繼者的babel、typescript和postcss等等已經成了前端開發中不可或缺的工具。

若是你對這一話題感興趣，acorn.js或許是個不錯的學習起點。

而以提升JS性能爲目的而誕生的wasm，也是當下前端領域的熱門話題之一。其產出是JS解釋器所對應的字節碼而非JS。

前端工程化

隨着grunt、gulp等工具的出現，前端工程化在歷史舞臺閃亮登場。

針對不一樣部署目標對代碼（js、css、html）進行壓縮與合併，替換指定佔位符，爲生成的js、css文件名添加hash，並最終輸出到指定目錄，等等這一系列操做已經成爲了前端開發中的標準流程。

隨後出現的webpack提供了更契合時代的依賴管理模式、方便的開發環境（熱更新、接口代理）等等功能，並逐漸成爲最主流的前端開發工具。

webpack4.x的出現，以及各類腳手架工具/項目的普及，使得配置前端工程化這一部分的工做對大多數前端開發而言變得透明。

隨着http2和ES module的普及，前端打包理念是否會發生新的變化？

單頁面應用

說到單頁面應用，首先要提到的是history API。

單頁面應用的一大基礎即是由前端操控的路由行爲。在history API出現以前，JS代碼能夠改變URL中hash的部分並監聽hashchange事件，這已經使得單頁面應用變得可能。而history API的出現，則使得單頁面應用的路由實現有了更好的用戶體驗，SPA成了前端開發口中的熱門話題。

其次要說的則是mv*框架。

backbone即是先驅之一。backbone將前端代碼抽象爲模型（Model/Collection）與視圖（View）層，視圖層能夠操控模型，而模型經過事件（Events）與視圖層交互。backbone的路由（Router）基於hash API。

縱使backbone基於jQuery、須要本身操做DOM更新、相比於MVVM和MVP模式過於笨重，卻任然不能掩蓋昔日輝煌與歷史地位。

angular經過藏檢測機制由框架層負責DOM操做與更新，使得開發者沒必要先掌握原生DOM API或是jQuery的使用便能開發前端應用，將經歷集中於業務邏輯、數據交互與用戶交互。而angular大而全的特色則是有人喜歡有人厭。

React和vue的出現，爲前端框架提供了更多選擇。React引入了virtual DOM、jsx、immutable、高階組件（HOC）、css in js、React Native等衆多概念與玩法。vue則勝在易學易上手以及博覽衆家所長，同時提供了vuex、vue-cli、vue loader、scoped css等實用工具。

混合開發

關於前端最後一個話題是混合開發。

隨着智能手機的普及，可否合併安卓與ios的開發成本成爲了許多人關注的焦點之一，而混合開發如此的初衷，也註定了這條路的曲曲折折。

首先說說cordova。cordova在webview的基礎上將原生與web的互通機制分裝爲jsbridge，並經過插件機制擴展其能力。雖然這是頗有趣的嘗試，而後web自己性功能（性能、功能）上的缺陷限制了cordova應用的發展。

不過原生（或非原生）應用經過內嵌webview提供部分高可變內容，或是提供部分非核心業務頁面來下降開發成本，還是APP開發中重要的一部分。

對於功能問題，一個頗有趣的嘗試是native script，其經過反射機制使得JS代碼能夠自由調用原生功能。

而對於性能問題，react native則給出了本身的方案。React引入的virtual DOM的設計使得JS能夠經過調用封裝好的原生代碼來建立原生界面，從而提升了渲染性能。同時React Native構建在JS/web基礎上的本質，使得其保留了動態下發內容的能力。

最初被設計來挑戰JS的dart語言終於在Flutter開花結果。Flutter經過Dart VM、Skia繪圖引擎等來實現跨平臺開發，爲了提升重繪性能，其重繪算法與virtual DOM的Diff算法一模一樣。

electron經過將瀏覽器（Chromium）、nodejs運行時一同打包的方式爲web提供了開發桌面應用的能力。Atom編輯器、VSCode即是經過Eletron開發的。

PWA（漸進式WEB應用）則是經過Manifest（實現添加至主屏幕），service worker（實現離線緩存/緩存管理），Push & Notification（消息推送）來彌補web應用的一些使用缺陷，使用戶得到更好的體驗。

混合開發還有一個有趣的話題，是小程序。小程序具有了web應用輕快的特色（甚至更輕更快），易傳播易更新，同時又提供了優於web應用的性能、功能體驗。

小程序的本質是webview，在經過原生擴展webview功能的同時，小程序也對web開發中涉及內容下發的不肯定因素（例如DOM操做、eval、new Function、功能受限的Rich Text等）進行了必定限制。同時小程序用原生的頁面棧管理替代了web的路由管理，提供了更友好更接近原生的頁面跳轉體驗。

爲了幫助web開發者更方便的開發不一樣環境下的web/小程序應用，構建在React/Vue之上的工具，例如taro、uniapp也陸續出現，這要感謝編譯/轉譯技術在前端領域的進一步普及。

隨着w3c推出小程序（MiniAPP）白皮書，小程序做爲混合應用一次成功的嘗試，可否走得更遠？

前端架構是什麼

架構包含很是普遍的概念與內容，有許多不一樣的維度。初次肩負起架構設計或許會讓人感到不知從何處開始。

接下來，請容許我來聊聊，關於做爲一名前端架構師，你須要負責思考的問題。

技術選型

技術選型或許是你們最熟悉也最容易開始工做的部分。

你喜歡angular、react、vue仍是其餘框架？路由庫、網絡請求庫、數據層用什麼工具管理？使用或是定製化哪一套UI庫？

你會使用less、sass仍是postcss？是否須要爲多語言和換膚功能引入額外的工具？

你和你的小夥伴是不是ts鐵粉？項目中是否須要引入wasm？兼容性預期是什麼，應該如何配置babel、是否須要引入特定的polyfill？

你將面對的是一個PC網站的開發，移動web應用，或是一個electron桌面項目？響應式和自適應如何選擇？若是你開發的是小程序，你會選擇taro、uniapp/mpvue或是選擇不使用這些工具？

你的應用是否須要與APP整合？直接使用webview仍是選擇使用cordova？若是你開發的是一個跨平臺APP，你將選擇RN、weex仍是flutter？若是是一個web應用，是否須要經過PWA來支持離線使用？

技術選型只是第一步。請切記，咱們須要考慮的不只僅是技術自己的優劣（不少時候不一樣技術自己就難以分出勝負），你還要考慮你和你的團隊對於技術的熟悉程度和學習成本，並帶領他們掌握你所選擇的技術棧。

代碼規範

你須要制定一系列規則來使團隊的代碼風格儘量一致，當面對大型和長期維護的項目時，這點每每比想象得重要。

你可能須要藉助一些工具，例如jslint、tslint、csslint、prettier等等。你還須要考慮使用BME命名、OOCSS、scoped css、css in js仍是其餘什麼方法來避免CSS衝突。

固然這只是問題的一部分，還有許多問題或許沒法經過工具來限制。例如，對於數組命名，使用arr、list仍是複數單詞（sheep這樣的單詞是否會讓人感到困擾？）？文件目錄如何組織？點擊事件是否統一以on開頭？

做爲架構師或是Team Leader，你須要保持按期code review的習慣來保證團隊正在以好的習慣書寫代碼。

以及，你是否須要統一團隊的工具配置，例如IDE配置、git配置（例如使用LF仍是CRLF做爲換行符）、是否須要使用nrm來管理npm源並使用nvm來確保統一的node/npm版本？

UI規範

除了代碼規範以外，若是有機會和設計師一塊兒來制定一系列UI/UX規範，這會令你的項目長期受益。

肯定主題與配色，typography（排印）規範（包括字體、字號、行高）。

你還要與設計師一通設計一套經常使用的組件以及交互方式，以確保你的界面在設計上遵循親密性、對比、對其、重複的規則（《寫給你們看的設計書》），同時給用戶帶來及時、一致、可控可預期的交互體驗，例如」肯定「統一使用綠色按鈕，」取消「統一使用灰色按鈕並在彈窗的左側，藍色文字表明鏈接與跳轉，」刪除「按鈕使用紅色而且每次點擊會彈出二次確認框。

品質，來源於對細枝末節的把控。

公共代碼

你須要管理你的公共代碼，不管是UI組件仍是非UI功能。

即便是隻考慮單獨的項目，也應該將具備複用可能意義的代碼放到單獨的目錄下管理。

爲了使用公共代碼庫，你須要搭建私有npm倉庫，仍是使用git submodule的形式？你的庫是針對web仍是nodejs設計的，對於web，你將經過webpack仍是cdn的形式引入代碼？若是不一樣形式都須要兼容，那如下形式的代碼你應當很是熟悉了：

(function (global, factory) {
  typeof exports === 'object' && typeof module !== 'undefined' ? module.exports = factory() :
  typeof define === 'function' && define.amd ? define(factory) :
  (global = global || self, global.VueRouter = factory());
}(this, function () {
  //
}));
複製代碼

文檔

正如以前所言，你須要帶領你的團隊掌握新技術並高效高質量的開發項目，並提煉可複用的代碼與組件，許多內容都須要文檔化。

對於非UI組件，JSDoc是一個不錯的文檔工具。對於UI組件，storybook絕對是一個神奇，你能夠經過它建立一系列可展現、可交互的組件示例，而且讓其餘人能夠直接拷貝實例代碼。

對於非來源於代碼的文檔，你可能須要藉助靜態網站生成器（static site generator）或是博客工具來書寫文檔，vuepress、wordpress、conflurence、石墨文檔等等都是不錯的選擇。

爲你的團隊提供可參考的代碼模板是個好主意，對此你可使用例如hygen（jondot/hygen）這樣的工具。當我須要添加一個列表頁面時，我會用模板生成初始代碼，其中包含了分頁加載、彈窗交互、篩選查詢等等代碼的模板，保證我添加的頁面有一致的代碼風格和交互行爲。

分支管理

你須要爲團隊設立一套分支管理規範，若是對此你還不瞭解，搜索」gitflow「你能夠找到須要有用的資料。

除此以外，是否全部提交到主分支的代碼合併都須要提交pull request並經過code review？如何與CI/CD流程整合？commit message和提交頻率是否要加以規範？merge仍是rebase？

演進能力

對於架構而言，演進能力一樣重要。將webpack從3.x升級到4.x，將vue從2.x升級到3.x，或許每次升級都會成爲陣痛，但咱們不能停滯不前，不然項目會慢慢變成一個難以維護的老頑固。

好在微前端理念能幫助咱們處理升級和重構所帶來的麻煩。single-spa是目前最流行的微前端框架之一，qiankun（umijs/qiankun）在其之上爲多項目結構提供了可行的實施方案。

經過微前端架構，咱們能夠逐步替代項目中的代碼，引入最近的技術，而沒必要由於畏懼而停滯不前，或是每次都翻江倒海一翻。

自動化：部署 & 測試

做爲架構師，你須要認真瞭解你所使用/搭建的腳手架和webpack，熟悉每一項配置（module、optimization、plugins...）的意義與使用。

除此以外，你須要瞭解git hooks、docker，懂一些shell script，以便和運維團隊一塊兒整合CI/CD流程。

你須要經過自動化測試以及代碼覆蓋率檢測來保證項目穩定前進，並制定合適的適應度函數來觀察項目的健康程度。可選的工具包括jest、instanbul等等，若是你須要編寫e2e測試，那你可能還須要熟悉headless chrome。

若是你決定添加自動化測試，或是遵循TDD/BDD的開發理念，這很好，不過請作好準備，這但是一項會持續牽扯團隊開發經歷的大工程。

大前端

從更大的視野來看，你可能還須要瞭解許多其餘的內容：

BFF（Backend for Frontend）、SSR（服務端渲染）、nodejs、graphql、grpc、消息隊列（mq）、受權與認證（oauth/JTW...）、nginx、數據庫（SQL、mongoDB、redis、elastic search、TiDB/cockroachDB、TSDB、graphDB...）、日誌管理、docker & k8s、微服務、service mesh（istio...）、serverless...

作好準備啦嗎 :)