前端早早聊大會，前端成長新起點，幫你提前二十天，站在新的起跑線，目標成為用得上，聽得懂，抄得走的前端大會，計劃 2020 年辦 12 期，由前端早早聊與掘金聯合舉辦。
- 第一期 2020.1.11 在杭州舉辦，主題 「前端轉管理」，450 人報名參加，反響強烈
- 第二期 2020.2.29 線上上直播，主題 「前端搞基建」，760 人報名參加，反響強烈
- 第三期 2020.3.28 線上上直播，主題 「前端搞搭建」，報名請加關注「前端早早聊」公眾號跟進歷屆大會 PPT/錄播視訊/圖文講稿，回覆 "大會" 二字獲取。
第三屆報名連結：www.huodongxing.com/go/tl3
- 團隊成立 3 年|小爝 - 如何推動基礎架構專案落地
- 團隊成立 4 年|堂主 - 如何推動前端團隊的基礎設施建設
- 團隊成立 5 年|Scott - 如何在人單力薄時立項推動基建
- 團隊成立 6 年|芋頭 - 如何在大前端團隊實現基建價值突破
- 團隊成立 12 年|崇志 - 如何設計大型前端團隊基建路線
本文是第五場講師 - 崇志的講稿文字版，來看看他是如何講的，視訊及 PPT 未來在公眾號放出。
大家下午好，我今天要分享的主題叫【大型前端團隊的基建設計整合之路】，主要會跟大家分享下我們團隊這麼多年積累下來的前端基礎設施相關方面的一些成果和心得。
自我介紹
簡單自我介紹下，我叫崇志，我是阿里媽媽的前端技術專家，入職大概 8 年多，目前主要專注在團隊的前端工程化上，右邊是我的釘釘二維碼，有想進一步交流的同學，可以加我釘釘。
業務介紹
主要的業務是一些對接商家的後臺管理型站點頁面，比如像鑽展，直通車，達摩盤之類的，這些站點都是 SPA 單頁應用構架，互動也比較複雜，比如像一些很複雜的計劃建立流程，報表展示之類的。還有就是這些應用基本都是維護很多年了，迭代也很頻繁，然後如何保持這種專案長期的可維護性，程式碼的健壯性都是我們團隊長期在關注和優化的點 。另外還有一類是屬於知識站點類，基本上都是一些靜態的文件內容。還有一類是營銷活動型別的頁面，比如像雙十一活動，年貨節這類的，都是上線時間很短的一些頁面
前端工程化發展之路
在早期的話，基本上我們前端都是以開發頁面 demo 的形式然後提交給後端去套 Java 的 VM 模板之類的，前後端程式碼耦合嚴重，另外就是前端基本沒有自己的本地開發環境，都是讓後端工程師幫忙安裝後端的開發環境，比如 JBoss，Tomcat 之類的，然後才能進行除錯，非常麻煩。
到了現在整個前端工程化之後，基本上就可以做到一個是前後端分離，這個主要是 SPA 單頁應用構架之後帶來的結果，後端基本只需要提供介面給到前端就可以。另外一個就是我們會做一些腳手架工具沉澱，包含一些最佳實踐配置，然後新開發專案的話基本就可以做到開箱即用。還有就是現在有很完善的本地開發環境，主要就是用 Node.js 開發的命令列工具，可以提供本地開發時對接模擬介面，然後在聯調時可以對接後端真實介面的能力。然後我們也做了單獨的介面管理平臺，這樣開發專案時只需要前期讓後端開發者在平臺上錄入介面資訊，就可以前後端並行開發，互不干擾。還有就是我們也做了專門的資料埋點統計平臺，方便運營或產品來直接的看效果資料。最後就是我們現在的專案都是在雲端構建跟釋出的，帶來的好處一個是專案倉庫裡不再有 build 之類構建後的程式碼，另外就是可以保證專案構建環境的一致性。
在這整個前端工程化的過程當中沉澱了很多前端的基礎設施，後面我會逐個簡單介紹下。
前端基建跟工程化的關係
首先因為我們集團內各 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 線上上直播，主題 「前端搞搭建」，掃碼關注「前端早早聊」公眾號參與報名：
