第二屆搞基建|崇志 - 如何設計大型前端團隊基建路線

前端早早聊大會，前端成長的新起點，與掘金聯合舉辦。加微信 codingdreamer 進大會專屬內推羣，贏在新的起跑線。前端

第十四屆|前端成長晉升專場，8-29 即將直播，9 位講師(螞蟻金服/稅友等)，點我上車👉 (報名地址)：json

正文以下

本文是第五場講師 - 崇志的講稿文字版，來看看他是如何講的，視頻及 PPT 將來在公衆號放出。後端

你們下午好，我今天要分享的主題叫【大型前端團隊的基建設計整合之路】，主要會跟你們分享下咱們團隊這麼多年積累下來的前端基礎設施相關方面的一些成果和心得。前端工程化

自我介紹

簡單自我介紹下，我叫崇志，我是阿里媽媽的前端技術專家，入職大概 8 年多，目前主要專一在團隊的前端工程化上，右邊是個人釘釘二維碼，有想進一步交流的同窗，能夠加我釘釘。緩存

業務介紹

主要的業務是一些對接商家的後臺管理型站點頁面，好比像鑽展，直通車，達摩盤之類的，這些站點都是 SPA 單頁應用構架，交互也比較複雜，好比像一些很複雜的計劃建立流程，報表展現之類的。還有就是這些應用基本都是維護不少年了，迭代也很頻繁，而後如何保持這種項目長期的可維護性，代碼的健壯性都是咱們團隊長期在關注和優化的點。另外還有一類是屬於知識站點類，基本上都是一些靜態的文檔內容。還有一類是營銷活動類型的頁面，好比像雙十一活動，年貨節這類的，都是上線時間很短的一些頁面前端框架

前端工程化發展之路

在早期的話，基本上咱們前端都是以開發頁面 demo 的形式而後提交給後端去套 Java 的 VM 模板之類的，先後端代碼耦合嚴重，另外就是前端基本沒有本身的本地開發環境，都是讓後端工程師幫忙安裝後端的開發環境，好比 JBoss，Tomcat 之類的，而後才能進行調試，很是麻煩。服務器

到了如今整個前端工程化以後，基本上就能夠作到一個是先後端分離，這個主要是 SPA 單頁應用構架以後帶來的結果，後端基本只須要提供接口給到前端就能夠。另一個就是咱們會作一些腳手架工具沉澱，包含一些最佳實踐配置，而後新開發項目的話基本就能夠作到開箱即用。還有就是如今有很完善的本地開發環境，主要就是用 Node.js 開發的命令行工具，能夠提供本地開發時對接模擬接口，而後在聯調時能夠對接後端真實接口的能力。而後咱們也作了單獨的接口管理平臺，這樣開發項目時只須要前期讓後端開發者在平臺上錄入接口信息，就能夠先後端並行開發，互不干擾。還有就是咱們也作了專門的數據埋點統計平臺，方便運營或產品來直接的看效果數據。最後就是咱們如今的項目都是在雲端構建跟發佈的，帶來的好處一個是項目倉庫裏再也不有 build 之類構建後的代碼，另外就是能夠保證項目構建環境的一致性。微信

在這整個前端工程化的過程中沉澱了不少前端的基礎設施，後面我會逐個簡單介紹下。markdown

前端基建跟工程化的關係

首先由於咱們集團內各 BU 的前端團隊很是多，這麼多年下來其實已經累積了很多頗有亮點的單點基建，能夠說輪子很是多，因此咱們這邊工程化的思路就是先梳理好咱們本身團隊的前端開發流程，在各個流程上都先去調研集團或社區內有沒有什麼能夠爲我所用的工具，若是有就看看可否這些工具之上進行二次開發，以更好的符合咱們團隊的開發需求，若是沒有就能夠嘗試自行研發，而後將這些全部基建工具整合串聯起來，覆蓋到整個前端開發鏈路，最後就能夠達到提升開發效率的目標。架構

前端開發的全鏈路過程

基本上包含如下這些流程，包括項目初始化、本地開發、接口聯調，數據埋點、構建發佈，還有就是性能監控。咱們的思路是經過開發一個命令行工具 rmx-cli ，來將整個前端開發鏈路串聯起來，也是經過這種方式將散在各處的前端基建整合起來，來達成 1 + 1 > 2 的效果。

接下來我會圍繞着 rmx-cli 命令行工具來說講咱們前端開發全鏈路上的各個基礎設施的狀況。

前端開發鏈路裏包含的基建

在項目初始化，本地開發，接口聯調這些流程裏咱們有如下這些基建，包括最基本的項目代碼管理，咱們是用 GitLab 來管理的。而後前端框架體系，咱們有自研的 Magix 體系框架，部分項目是用瞭如今社區很成熟的 React 體系。而後基於 Magix 框架，咱們有自研的組件庫 Magix-gallery 。還有咱們也在本地開發時提供了可視化搭建的插件，Magix-desiger。而後咱們也有一個自研的叫 MAT 的本地開發聯調服務插件，主要提供本地開發服務，接口模擬，接口代理等功能。接口管理部分則是有一個叫 RAP 的接口服務平臺，底層是用到了 Mock.js 的能力。字體圖標方面則是用到了 Iconfont ，這個你們應該都比較熟悉，是咱們阿里媽媽開發的一個字體圖標管理平臺。圖表體系則是用的咱們自研的圖表管理平臺： Chartpark ，相似組件庫同樣，提供經常使用的各類類型業務圖表。

在數據埋點方面咱們有自研的 Dataplus 平臺，提供單頁應用頁面的自動埋點，以及埋點後的效果數據查看。性能監控方面，咱們是經過命令行工具接入了集團的 Clue 監控平臺，會在項目初始化時自動接入。另外就是咱們也有一個自研的相似 TMS 的內容管理系統 ALP ，主要是用來快捷發佈一些活動頁面之類的功能。最後在構建發佈方面咱們有 Magix 體系的 Magix-combine 來負責代碼的構建，同時咱們也經過命令行工具接入了集團的 DEF 平臺來實現前端資源的雲端構建發佈能力。

命令行工具 rmx-cli

早期咱們團隊成員在開發項目的時候，每一個人都有本身的方式去處理本地開發服務的問題，好比有的人用 Nginx ，有的人用 Java 的服務器，環境很不統一，在須要開發對方項目的時候，環境的搭建是一個很繁瑣的事情，後來 Node.js 出來了，咱們就想着是否是能夠搞一套基於 Node.js 的命令行工具來將整個開發流程給統一塊兒來，因此就有了 rmx-cli 命令行工具。這個命令行工具也迭代了不少個版本，從最初的只支持 Maginx 體系，到如今利用套件體系能夠支持其餘不一樣的框架體系，更具備通用性。

而後來看下如今 rmx-cli 命令行工具的基本架構， rmx-cli 主要是三層結構，一個是底層是 Cli 命令行入口，主要提供一些系統的命令，好比登陸，登出，安裝卸載之類，中間層是 Rmx-core 核心包，主要提供系統命令和默認套件命令的具體實現邏輯。另外就是最外層的套件和插件體系，負責不一樣框架體系的具體的命令邏輯實現。一些比較基本通用的套件命令咱們會在命令行工具裏直接內置，好比像 init 初始化， build 構建， publish 發佈等等這些命令。而後不一樣框架體系有特殊邏輯的命令能夠經過重寫或增長套件命令的形式進行自定義擴展。

插件命令屬於跨框架的全局的通用命令，好比咱們就有一個 clear 插件專門用來清除 Chrome 的 HSTS 和 DNS 緩存。而後插件體系也是支持擴展的，任何人均可以按照咱們的插件規範開發一個插件包，而後申請接入咱們的插件體系。

另外就是咱們也作了配套的 Webui 工做臺，基本上就是對 Cli 命令行的可視化實現，背後的核心邏輯是同一套代碼，而後同時供 Cli 命令行和 Webui 調用。咱們能夠在 Webui 工做臺裏進行開發命令的可視化操做，項目的管理，還有套件和插件的安裝和刪除等等功能。

前端開發框架 Magix

Magix 是咱們阿里媽媽自研的區塊化管理框架，主要應用場景是 SPA 單頁應用（同時也支持傳統的多頁應用）。 Magix 在咱們阿里媽媽的歷史比較悠久，甚至比 React 當年出來的還要早一些，是咱們常年開發那些後臺管理型站點所慢慢沉澱出來的一個框架，通過不少個版本迭代，如今基本上已經很成熟穩定。Magix 主要是以 view 來作區塊化開發管理的，包括組件庫的組件也是基於 view 寫的。而後也提供雙向綁定的能力，還有就是咱們配套開發了 Magix-combine 離線處理插件來提高性能，好比 HTML, CSS, JS 的合併，樣式的局部隔離等等。另外就是藉助 rmx-cli 命令行工具，咱們也實現了在本地開發時，實時熱更新的能力。

前端腳手架 rmx init

事實上咱們在這麼多年的業務開發過程中，確定會有不少不一樣類型的包含最佳實踐的前端腳手架沉澱下來，在開發新項目的時候就能夠直接初始化使用。咱們這邊主要是經過命令行工具的 rmx init 命令來進行腳手架初始化的，能夠看下大體的運行效果。這個命令只要輸入項目名稱就能夠一鍵初始化項目環境，快速投入開發，包括幫助你在本地和 GitLab 上都建立好項目，對接各個平臺等等。

而後看下咱們 rmx init 的具體流程，首先咱們會先選擇一個套件，好比 Magix 或者 React ，而後再指定腳手架，腳手架支持不一樣類型，好比後臺管理型跟營銷頁面型的站點，而後再輸入一個項目名稱，肯定好後 Cli 命令行就能夠自動在 GitLab 平臺建立好相應的項目。還有就是對接各個開發平臺，好比接口管理平臺 RAP , Iconfont ， Chartpark 等等，也會在相應的平臺上建立好項目，而且將項目 id 配置到項目的 package.json 中，供後續 Cli 命令行工具在本地開發中使用。基本上咱們經過套件體系和多腳手架選擇就能夠覆蓋到大部分不一樣類型的項目初始化需求，能夠作到開箱即用，很好的提高了開發效率。

本地開發服務命令 rmx dev

這個也是咱們整個前端開發鏈路裏很是核心的環節。 rmx dev 時會在本地起一個 KOA 服務器，根據項目中配置好的 RAP 的項目 id ，就能夠作到本地開發時的接口模擬數據來自 RAP 平臺，同時 rmx dev -d 加後端提供的接口 IP 地址的話，就能夠直接跟後端聯調真實接口。而後利用 RAP 平臺數據也能夠作到本地接口校驗的能力，提升接口的準確性。另外就是也支持直接聯調線上 HTTPS 類型的接口，由於如今線上環境大部分都是強制要求 HTTPS 的，若是要在本地開發聯調線上接口的話，就須要在本地也要搭建 HTTPS 服務，這個有作過的人都知道很麻煩，須要安裝簽名證書什麼的，因此咱們作了一個很取巧的方式，就是本地仍是起的 HTTP 服務，而後接口經過咱們的 MAT 插件轉發到線上接口時加上 HTTPS 協議，就能夠繞過這個問題了。

還有就是本地開發時咱們加了不少提升效率的輔助功能，好比 Magix-hmr 支持對 Magix 項目的實時熱更新。而後咱們會在本地開發時頁面注入幫助文檔，在開發時方便查看，同時咱們也注入了 Magix-desiger 可視化搭建系統，能夠快速建立指定模板的頁面。還有就是咱們的本地開發服務會直接接入 Magix-combine 進行實時離線編譯。

開發幫助浮層工具 rmx dev

咱們如今開發的項目通常都會有不少配置，好比像各個關聯平臺的項目 id ，還有開發環境的接口 IP 地址之類的，而後這些配置咱們就經過浮層的形式注入到本地開發頁面中，很方便的以可視化的形式進行配置的修改與保存。另外就是提供一些幫助文檔的地址，好比 rmx-cli 使用文檔、組件庫文檔地址等等，方便在本地開發時查看。

微前端

時下很熱門的一個概念：微前端，咱們這邊也有在 Magix 體系下作了相關的嘗試。

來看下業務場景：一開始咱們可能只有一個達摩盤項目，而後過了一段時間產品說我要再開發一個達摩盤小二版和服務商版，他們是不一樣的域名站點，可是裏面的某些模塊頁面好比人羣列表是同樣的。而後咱們想到的思路就是這個通用的人羣列表模塊是否是能夠以 view 的形式加載到其餘項目中，可是這三個項目實際上是不一樣的倉庫，直接加載是不行的，因此咱們須要作些處理。

固然若是用 iframe 加載的形式也是能夠解決剛纔提到的那個業務場景，但 iframe 方案的弊端也很明顯：一個是由於 iframe 是徹底隔離的，HTML, JS, CSS 都是完整加載的，加載速度會慢不少，割裂感很明顯。另外就是 iframe 的樣式寬高無法像 div 那樣自動撐開，要處理 iframe 的自適應的寬高是一個很麻煩的事情。

因此咱們這邊是用到 Magix 裏面一個 vframe 加載的方案， Magix vframe 是用來管理 view 的，若是咱們要跨項目加載其餘項目的 view 的話，咱們只須要配置跨項目的前端資源地址，以及跨項目的接口 host 配置就能夠實現。而後咱們的 Magix-combine 離線編譯插件提供了 scope 樣式隔離的能力，避免被加載的模塊影響宿主樣式。通用樣式會進行本地化，就是你的 view 被加載進另外一個項目時，通用樣式會直接用對方項目的。而後由於都是 Magix 項目，因此咱們組件庫是共享了同一個，避免屢次加載的性能問題。而後咱們也加了一個 xSite 插件作到資源按需加載，就是有加載那個 view 的頁面時，才加載相關資源。

這樣基本就能夠作到不一樣的項目模塊能夠互相加載的能力，大大提升模塊的跨項目的複用性。

而後基於跨項目加載 view 的這個能力，咱們也開發了一個配套的 Chrome 插件，用來輔助本地開發時，配置跨項目加載的子 view 的前端資源地址和接口 host 配置。也就是咱們能夠在本地同時起兩個項目的服務，而後修改 Chrome 插件的配置，就能夠同時調試開發兩個項目的代碼，而不須要改動到項目裏的相關配置代碼。
另外就是這個 Chrome 插件也能夠在訪問線上站點的時候，修改跨項目加載的子 view 的配置，直接進行子 view 的本地調試開發。

可視化搭建 Magix-desiger

最先沒有任何工具的時候，只能是經過手動建立頁面，再 copy 一些現有的頁面代碼，而後再進行開發工做。後來咱們有了 rmx-cli 命令行工具後，經過 rmx add 這個命令來直接生成預設好模板的 view 頁面，好比表格、表單這些通用類型的頁面，也能夠選擇根據 RAP 平臺的接口生成與接口相關聯的頁面，可是基本上仍是比較固定化的模板方式，不是很靈活。

爲了解決相似這種快捷搭建經常使用頁面的效率問題，咱們就開發了 Magix-desiger 可視化搭建插件，接入咱們的 rmx-cli 命令行體系。主要是經過編寫 Schema 描述模板，再結合 RAP 平臺的接口數據，在本地開發時注入一個可視化的操做界面，來進行實時快捷的頁面搭建。後來更進一步，咱們也加入了 AI 識別設計圖直接生成頁面的能力，就是直接上傳一個設計圖，系統能夠自動識別出圖片裏的下拉框，表格，表單輸入框等元素，自動的生成頁面，而後開發人員再基於這個生成的頁面繼續開發就能夠了。

到目前 Magix-desiger 可視化搭建系統，甚至能夠提供給後端開發人員進行一些經常使用的表單或表格頁面搭建，減輕了很多前端的工做量。

咱們來看下一大體的運行效果：

就是在本地開發的時候，經過 rmx-cli 命令行工具在頁面上注入 Magix-desiger 相關的 JS 文件，Magix-desiger 插件會在本地起一個 WebSocket 服務進行一些文件的讀取、寫入之類的操做。而後依賴這個插件就能夠直接在頁面上進行操做，能夠新建一個頁面，也能夠選取當前的頁面進行編輯。

接口管理 RAP

咱們這邊開發的一個用來管理接口模擬數據的平臺：RAP

由於如今咱們主要的業務都是先後端分離的開發模式，跟後端最重要的一個交互方式就是經過接口，因此咱們開發了 RAP 這個平臺專門用來維護接口信息。這個平臺主要提供了接口信息錄入、文檔說明、還有接口模擬數據的功能。

來看一下這些年咱們團隊關於接口管理的發展過程：

Mock.js 可能你們都有據說過，是咱們這邊的一個同事開發的專門用來生成模擬數據的 JS 庫，而後早期的話，咱們就是把 Mock.js 庫直接引入項目，同時在項目中保存 mock 數據的規則文件，來解決最初只能在具體的業務頁面手動模擬接口的痛點。這樣作帶來的問題一個是上線的時候須要將 Mock.js 移除，另外就是 mock 模擬規則文件會在項目中冗餘。

因此爲了解決這些問題，咱們開發了 RAP 接口管理平臺，接口 mock 規則信息就統一維護在平臺上，不須要在本地儲存 mock 數據了，可是在本地開發環境中須要引入一個 RAP.js 文件來將接口轉發到 RAP 平臺來獲取模擬數據，另外還須要在項目代碼裏判斷是不是本地開發環境，至關因而在生產環境的代碼中仍是冗餘了一些本地開發時的輔助代碼。

而後到如今咱們經過 rmx-cli 命令行工具，在本地開發階段就能夠將接口經過命令行工具轉發到 RAP 平臺獲取模擬數據，再也不須要 RAP.js 文件在前端代碼層面進行接口攔截與轉發。還有就是咱們也提供了命令來將 RAP 平臺上配置好的接口信息直接同步到項目中，不須要在項目中手動的維護接口列表信息。另外就是咱們如今有 RAP 平臺的接口信息，同時也有本地開發時的接口請求信息，這樣咱們就能夠作到在本地開發時校驗接口的能力，就是能夠有效的校驗後端返回的真實接口信息與 RAP 平臺上的接口信息是否匹配。

而後目前咱們的這種解決方案，就是能夠作到在生產環境中沒有冗餘的侵入式的代碼，同時咱們前端也再也不關心接口的維護，基本上都是由後端同窗在 RAP 平臺上錄入他們的接口信息就能夠了， RAP 平臺同時也承擔了接口文檔說明的功能。

組件體系 Magix-gallery

咱們基於 Magix 框架開發的組件庫， Magix-gallery 。組件體系在一個相對大一點的團隊裏基本上都是要自行開發的，也只有自研的組件庫纔可以快速響應視覺交互對組件的高定製需求，也利於咱們統一跨產品線通用組件的前端交互行爲。咱們組件庫積累到目前已經有 60 多個通用組件和業務組件，基本涵蓋了大部分的交互類型，同時也在組件層面提供了雙向綁定的能力，提升平常業務開發體驗。事實上咱們的組件庫成熟穩定以後，平時開發平常業務，基本上就是拼裝各類組件，而後再加一些邏輯代碼就完成了，這樣就能夠有很高的【平常業務】的開發效率。

而後咱們也將 rmx-cli 命令行工具與組件庫相結合，提供了一鍵同步組件代碼到項目中的能力，也支持指定某個版本的組件同步，還有就是在組件有新版本時，會在命令行裏給到升級提示。

而後由於咱們產品線有不少，並且主題色都不同，因此咱們組件平臺提供了一個快捷編輯主題顏色的功能，只要選取一個主題色，其餘全部的輔助顏色就會自動生成，也能夠再細調各個輔助顏色，最後提供下載到本地的功能，就能夠直接應用到項目中了。

圖標管理 Iconfont

咱們團隊開發的圖標管理平臺 Iconfont ，這個應該你們都比較熟悉了。

目前同時支持單色的 Webfont 形式，和多色的 SVG 形式圖標，而後也能夠提供設計師上傳 SVG 圖標，並在線調整的能力。

而後看下咱們團隊圖標方案的這些年發展過程：

早期的話頁面上若是要有圖標，基本上就是從 PSD 裏切出來，而後爲了減小請求，會將全部的圖標拼在一塊兒，經過位置來決定用哪一個圖標，這種方案基本上缺少靈活性，大小、顏色啊都是固定的。

後來咱們基於 Webfont 的形式開發了 Iconfont 圖標管理平臺， Webfont 的優點很明顯，就是大小跟顏色能夠隨便定義， HTML 裏面引用也很方便。可是 Webfont 形式最大的弊端就是隻能是單一顏色，因此後來咱們也加入了 SVG 模式，能夠支持多色圖標。

而後如今經過 rmx-cli 命令行工具，咱們在初始化項目的時候，就能夠自動在 Iconfont 平臺建立好關聯的項目，而後在開發時能夠在 Iconfont 平臺上添加好圖標以後，經過命令一鍵同步字體配置到項目當中。同時 cli 命令行工具也提供了用來檢測項目中是否有冗餘圖標字體的命令，這個主要是爲了解決項目長期維護致使的 Iconfont 項目無效字體愈來愈多的問題。

圖表體系 Chartpark

看一下咱們團隊的圖表體系 Chartpark ，先說下咱們爲何要本身研發圖表庫：

一個是由於咱們產品對圖表的需求不少都是很定製化的，只有咱們本身開發的圖表體系才能快速響應他們的需求。
另外就是咱們後臺管理型頁面的不少圖表都是有很高的交互效果的，自研的圖表庫纔可以更好的開發出相應的互動效果。

來看下咱們的圖表體系構架，主要分了三層：底層 Canvax 庫是封裝了 Canvas 的 context2d 和 Webgl 的渲染器功能。而後中間層 Chartx 庫是基於 Canvax 作了對常見業務圖表的封裝，好比柱狀圖，餅圖之類的。最後的就是最上層的 Chartpark 圖表管理平臺，主要是對項目的圖表配置進行集中管理。

而後這個就是咱們的 Chartpark 圖表管理平臺，通過多年來的沉澱積累，如今官方圖表庫已經有 100 多個，基本上能夠覆蓋業務中經常使用的圖表類型。
複製代碼

咱們當初作這個平臺的目標是但願有一個能夠直觀的配置圖表的地方，來快速的知足交互視覺對圖表的定製需求。因此咱們作了這個平臺來將項目裏全部圖表的配置集中在一塊兒進行開發調試，項目中只須要配置圖表的 id 就能夠了。
因此咱們這個平臺提供了在線編輯預覽圖表的能力，在線配置好圖表以後，就能夠經過 rmx-cli 命令行工具一鍵同步圖表庫配置到項目當中，無須手動操做。另外也能夠支持直接下載配置好的圖表庫到本地，而後經過 import 的形式引入到項目中使用。

埋點平臺數據小站 Dataplus

當時開發這個平臺的背景：一個是由於咱們的產品、運營、交互對業務產品有很強的打點需求，來印證他們上線的產品的效果。另外就是咱們集團已經有一個很成熟的傳統頁面埋點平臺 SPM ，可是咱們這邊主要是單頁應用， SPM 不支持單頁應用的 UV、PV 的統計。因此後來咱們就基於 SPM 開發了本身的 Dataplus 數據小站平臺，主要是解決了一些 SPM 沒法知足咱們項目需求的問題，好比自動埋點的功能，還有剛纔提到的單頁應用的 PV、UV 的統計，另外就是平臺產出了有價值的數據報表，主要基於業務的數據，作了用戶數據分層，能夠幫助咱們的產品經理更好的瞭解不一樣層級的用戶在使用各個業務產品的狀況。

看下數據小站 Dataplus 的基本構架：

底層埋點是由咱們集團的 SPM 打點系統提供支持，而後數據小站會將 SPM 那邊儲存的埋點數據拉取到平臺上進行個性化處理，而後就能夠作業務站點的全站概覽，頁面分析，單點分析等等功能。還有就是咱們也開發了一個配套 Chrome 插件，在訪問業務站點的時候，能夠直接查看頁面上的 PV、UV，或者某個功能點的埋點數據，還有就是能夠在頁面上選取某個具體的功能埋點直接添加到數據小站平臺裏。

而後就是接入 rmx-cli 命令行工具方面，主要就是經過命令行工具，在項目初始化時能夠直接建立好數據小站相關的埋點信息，而且配置到項目當中。另外咱們在項目的構建發佈命令裏接入了自動埋點和同步配置的功能。這樣的話基本上咱們開發一個項目，零配置零操做就能夠達到全站自動化的埋點。

內容管理系統 ALP

咱們團隊也開發了一個通用的內容管理系統 ALP ，它是一個相似 TMS 的頁面發佈系統。

ALP 誕生的背景主要是爲了應對咱們部門愈來愈複雜多變的業務場景，提供一個快速上線產品的能力。好比咱們前端能夠基於 ALP 快速的開發併發佈一個平常活動頁面，還有就是提供給運營像編寫 Word 文檔同樣簡單的製做一個推廣頁面，能夠直接發佈到生產環境，來完成一次活動宣傳。

對咱們後臺管理型業務來講，經常使用的一個功能是 Jsonp 接口管理模塊，好比像項目中的活動頁浮層，或者一些純靜態展現的文案和圖片，而後這些內容又常常改動的頁面，咱們就能夠用 Jsonp 接口的形式配置到 ALP 平臺上，以可視化的形式提供給運營隨時去更改內容，這樣就能夠省去咱們前端不少無謂的重複性工做。

Serverless 體系 Fether

咱們團隊如今也在嘗試開發的 Serverless 體系：Fether

像咱們團隊中有不少自研的服務平臺，像數據小站平臺，圖表 Chartpark 平臺， RAP 接口平臺等等，這些都須要本身去搭建、運維服務器資源，對前端開發來講不是很擅長，也是很費心費力的事情。因此咱們團隊的同事就基於集團的 Aliyun 計算開發了本身的 Serverless 平臺。如今基本上咱們團隊內部自研的平臺都已經慢慢往 Fether 上遷移了，那用了 Serverless 給前端帶來最明顯的好處是免運維，不須要關心服務器負載什麼的，只須要關注在本身的業務邏輯上就行了。而後咱們也基於平臺的能力提供了統一的監控和數據統計功能。

構建發佈

咱們這邊主要的項目都是 Magix 框架的，因此構建都是經過 Magix-Combine 這個包來執行的，Magix-Combine 是一個爲了提升性能的離線處理包，好比模板提早變成 function ，減小線上的臨時編譯，還有就是樣式的 Scope 隔離，以及提供 Typescript, ES6 的支持，還有一些基礎的代碼錯誤檢測等等。

而後就是發佈階段，咱們在 Cli 命令行工具裏集成了集團的雲構建平臺 DEF ，雲構建的好處一個是項目倉庫裏再也不須要構建後的 build 目錄，另外就是能夠保證不一樣開發人員構建環境的一致性，還有就是平臺化之後，全部分支管理、發佈記錄均可以在平臺上進行回溯和查看。咱們經過 Cli 命令行工具也集成了一鍵發佈平常和線上環境的命令，命令內部包含了主幹代碼的 merge 合併、代碼 commit 提交、 SPM 埋點、調用 DEF 雲端構建的這些邏輯，基本上免去了全部手動操做的重複性工做。

總結

咱們團隊是沒有單獨的架構組的，因此咱們基本上都是在常年累月的業務當中，去發現問題，定位問題，最後解決這個問題，而後在這個過程中天然而然的沉澱出前端各個面向的基礎設施，團隊成員也會在這個過程中找到適合本身的前端領域，而且深耕下去。而後隨着團隊裏的各個領域的基建慢慢成熟，就會必然走上前端工程化之路，實際上工程化就是將散落在各個點上的優秀的基建串聯起來，最後造成一個適合本身團隊的完整的體系化的東西。最後完善的前端工程化一定是會反哺到咱們的業務當中，極大的提升咱們的開發效率和體驗。

前端發展到如今這個階段，雖然比之前那個時代成熟完善許多，可是橫向對比其餘語言，好比後端 Java 體系，仍是有不少不完美的地方，因此如今遠遠不是終點，從長遠來看仍是有不少前端領域值得去開拓和探索的。

而後就是咱們的招聘廣告時間，對，咱們要招人。咱們是阿里媽媽的前端二組，主要業務是對接商家的後臺管理型站點。咱們沒有獨立的架構組，但基本上每一個人都會負責某個領域的基礎設施開發，目前整個技術棧鋪開的面也比較多，後續發展的空間也比較大。還有就是咱們團隊很穩定，不少年沒有太大的變更，適合長期發展，氛圍也比較輕鬆。另外咱們是屬於阿里系的，福利跟集團靠齊，算是比較好的。最後就是咱們阿里媽媽雖然對外不是很知名，可是是阿里最賺錢的部門，因此你懂的，有興趣的同窗能夠掃描個人釘釘二維碼聯繫我。

第三期 2020.3.28 在線上直播，主題「前端搞搭建」，掃碼關注「前端早早聊」公衆號參與報名：