如何推進前端團隊的基礎設施建設

1、前言

本文根據 2020.02.29 日，第 2 屆 「前端早早聊」 的「前端基建」專場分享整理而來。本文的標題是《如何推進前端團隊基礎設施建設》，一是契合大會全部分享都以 「如何」 爲切入的要求，同時也是對最近一年，我所負責的團隊在前端技術基礎設施建設方面如何從 0 到 1 的一次沉澱總結。

另外仍是很是感謝@Scott，感謝活動的組織者和參與者，感謝這一期的話題。業界關於前端系統性基建建設的分享輸出並很少，但願本次這些我的角度沉澱的文字，能爲一些同窗帶來一些啓動，產生一些改變。

廣義狀況下，技術架構、技術建設等是研發團隊基礎設施建設的一個真子集，除了這些，團隊的基建還包括了諸如制度、流程、文化、梯隊、培訓等其餘方面。在本次分享中，咱們是面向狹義的「技術基礎設施建設」進行，此外的偏軟能力的方面，可參考@堂主 在前端早早聊第 1 屆大會上的分享《如何影響與推進前端團隊的成長》。

2、介紹

堂主，本名馬翀，2006 年開始搗鼓前端，大學期間轉過系、休過學、失敗過創業。畢業前的 2011 年，在淘寶前端團隊實習了整一年，12 年畢業後即加入淘寶（花名@堂主）； 2016 年加入蘑菇街（蘑菇街時期花名@明淳），在蘑菇街作了 2 年的前端 TL；2018 年 8 月 ~ 至今，負責政採雲的前端團隊工做（花名又改回了@堂主）。

政採雲前端團隊目前有 50 多人，平均年齡不到 28 歲，妥妥的青年軍。團隊名字是 ZooTeam，團隊站點也是 https://zoo.team。Z 是政採雲拼音首字母，oo 是無窮的符號（♾），結合 Zoo有生物圈的含義，但願後續政採雲的前端團隊，不管是人才梯隊，仍是技術體系，都能各面兼備，逐漸成長爲一個生態。

下面是個人微信二維碼，有想進一步交流的同窗，歡迎掃描加我微信。

3、如何理解「技術基建」

「技術基建」，就是研發團隊的技術基礎設施建設，是一個團隊通用的技術能力沉澱。本次分享的絕大部份內容都會圍繞這個中心進行，但在這以前，讓咱們先來看看一些同窗的困惑（一樣的內容我在上個月第一期早早聊大會的分享中也提到過）：

上面三個問題都頗有典型性，且不是臆造的，都來源於脈脈的匿名社區。能看到這裏涉及到對 「作業務」 和 「作架構」 的認知不清，也有對能力評級的疑問 —— 到底要掌握多少知識技能才能得到更高的評級。對於後一個評級疑問，堂主稍早前寫過一篇長文《面試官角度看應聘：問題到底出在哪？》來闡述我的觀點，分爲了上、下兩篇，可點擊連接查看。而對於 「業務」 和 「架構」（或者今天我說的，基建）的區別和理解，我想說的是：

技術的價值在於解決業務問題，「業務支撐」 和 「基礎建設」 歷來都是同一件事的兩個面，這個 「同一件事」，就是幫助業務解決問題。任何脫離解決實際場景而發起的基建，都須要從新審視甚至不該被鼓勵。

基礎建設的發起從業務問題中來，其意義不只是能幫助業務解決問題。承擔建設的虛擬團隊，在建設過程當中能爲同窗提供不一樣維度的鍛鍊場景，在業務問題與場景的識別、方案設計、新技術實踐、項目管理和產品化思惟方面都能提供實踐成長的空間，起到練兵的做用。同時一個虛擬建設小組本質上也是一個團隊，過程當中能對不一樣角色進行鍛鍊和考察，這有助於團隊梯隊的完善。建設結果對於業務的促進，更容易得到內部合做方的承認；沉澱下來的好的經驗，能夠對外輸出分享，也是對影響力的有力幫助。

4、基建搞什麼

對於一個研發團隊，若是一直都是靠壓榨、純加班這種出蠻力的方式在支持業務，這個團隊會很是危險，業務也會危險。這種模式下，業務是沒法實現跨越式增加的 —— 你總不能期望業務量增加 10 倍的狀況下研發團隊規模也擴充 10 倍，成本會失控。有時候階段性的忙和加班是不可避免的，好比電商的雙 11 大促，或者 toB 業務定製的大項目的交付，時間點都是倒排，守時履約對結果的影響很是重。加班是應該的，不加班也是應該的，只有完不成工做是不該該的。當這一陣過去後，團隊必定要思考，怎麼作能更高效。站在將來看今天，若是一年、兩年後，業務量增加 N 倍，那時候該如何支持，如今的方式是否能知足？不可能靠堆人，只能靠技術建設去提效降成本，這就是基建最核心的價值：幫助業務更好的活在將來。

那基建該搞什麼？首先咱們要說，基建的內容和業務階段、團隊既有建設沉澱是分不開的。越是偏初創期的團隊，其建設，每每越偏向於基礎的技術收益，如腳手架、組件庫、打包部署工具等；越是成熟的業務和成熟沉澱的團隊，其建設會越偏向於獲取更多的業務收益，如直接服務於業務的系統，技術提效的同時更能直接帶來業務收益。

業界大部分的研發團隊，都不是阿里、騰訊、頭條這樣基礎完備沉澱豐富的狀況，起步期和快速爬坡期居多，建設滯後。體如今基建上，可能每每只有一個基於 Webpack 搞搞的腳手架，和一個第三方開源的 UI 組件庫上封裝下本身的業務組件庫，除此以外無他。若是看官如今剛好是我說的這種狀況，不用焦慮，1 年半前我剛來政採雲，當時這裏的前端也是同樣的狀況。後續的一年多時間到如今，咱們初步建設並落地了一系列的基礎設施，取得了蠻好的反饋。回顧當初，肯定建設的策略及步驟，主要是從拆解研發流程入手的：

如上圖所示，一個基本的研發流程閉環，通常是需求導入 - 需求拆解 - 技術方案制定 - 本地編碼 - 聯調 - 自測優化 - 提測修復 Bug - 打包 - 部署 - 數據收集&分析覆盤 - 迭代優化 —— 即新一輪的需求導入。

在這個基礎的閉環中，每個節點都有其進一步的內部環節，每個環節相連，組成了一個研發週期。這個週期順，研發流程就順。這個週期中每個環節的阻塞點越少，研發效率就越高。最初期的基建，就是從這些耽誤研發時間的阻塞點入手，按照廣泛性 + 高頻的優先級標準，挨個突破。

提效、體驗、穩定性，是基建要解決的最重要的目標，通用的公式是 標準化 + 規範化 + 工具化 + 自動化，能力完備後能夠進一步提高到平臺化 + 產品化。在方向方面，咱們團隊是從下面的 8 個主要方向進行歸類和建設，供你們參考：

• 開發規範：這一部分沉澱的是團隊的標準化共識，標準化是團隊有效協做的必備前提。
• 研發流程：標準化流程直接影響上下游的協做分工和效率，優秀的流程能帶來更專業的協做。
• 基礎資產：在咱們團隊，資產體系包括了工具鏈、團隊標準 DSL、物料庫（組件、區塊、模板等）。
• 工程管理：面向應用全生命週期的低成本管控，從應用的建立到本地環境配置到低代碼搭建到打包部署。
• 性能體驗：自動化工具化的方式發現頁面性能瓶頸，提供優化建議。
• 安全防控：三方包依賴安全、代碼合規性檢查、安全風險檢測等防控機制。
• 統計監控：埋點方案、數據採集、數據分析、線上異常監控等。
• 質量保障：自測 CheckList、單測、UI 自動化測試、鏈路自動化測試等。

如上是通常性前端基建的主要方向和分區，不管是 PC 端仍是移動端，這些都是基礎的建設點。業務階段、團隊能力的差別，體如今基建上，在於產出的完整性、顆粒度、深刻度和自動化的覆蓋範圍。

5、基建怎麼搞

下面，會針對一些你們都感興趣的方向，結合咱們團隊過去一年的建設產出，爲你們列舉一些前端基建類產品的案例，以供參考。

1. 規範&文檔（Docs）

規範是最應該先行的，始皇帝初統六國即「書同文車同軌」，規範意味着標準，是團隊的共識，是溝通協做的基礎。而文檔，是最容易被忽略的事情之一，除了明面上重要的技術文檔、業務穩定以外，還包括了行間的有效註釋。想一想，有多少時間是花在琢磨別人的代碼邏輯，或剛接手某個業務得問多少人才能搞明白你面前那幾個倉庫是怎麼回事，又有多少故障是由於不清楚前任留下的坑在哪裏不當心踩雷。

對於規範的制定，須要強調的一點，是規範的產出應是團隊內大部分同窗的共識，應該是集體審美。規範一旦肯定就應該嚴格執行，要能造成團隊行爲的一致性。對於文檔，爲了寫而寫的文檔是垃圾，不如不寫。文檔的重點在說人話，在於有效性，在於直觀、省事、不饒。想一想一個 UI 組件庫的文檔，先給你看可交互的 Demo 再提供 API 信息，和直接開頭就羅列一大堆的 API 文字介紹，哪一種對閱讀者的感覺更好、心理成本更低？

2. 本地工程化環境（CLI）

本地開發環境，相信是任何一個團隊都會作的標配，省事的可能直接擁抱框架選型對應的全家桶，如 Vue 全家桶，或者用 Webpack 擼一個腳手架。能力多一些的會再爲腳手架提供一些插件服務，如 Lint 或者 Mock。從簡單的一個本地腳手架，到複雜的一個工程化套件系統，其目的都是爲了本地開發流程的去人肉化、自動化。

咱們團隊的本地開發環境基建，是一個工程化套件環境，核心理念就是儘可能 「一步搞定全部事」，把本地環境的配置和使用盡可能變的傻瓜化無腦化。好比本地初始化一個應用的環境，從 CLI 命令行的操做出發的話（實際上政採雲前端團隊如今已徹底 GUI 化），一個 zoo init 命令就能搞定所有的本地環境搭建，這個所有是指在終端執行回車後，從倉庫本地目錄的生成到 npm 依賴的自動化安裝到腳手架插件的初始化再到喚起一個瀏覽器窗口，都是自動化執行的。是的，連 npm install 和 dev 什麼的都不用執行，能省一步操做就省一步，楚王好細腰，少就是性感。下圖是 CLI 本地工程套件的架構圖：

3. 可視化工程系統（GUI）

其實目前團隊的平常研發，已經基本上脫離了 CLI 操做，統一到了團隊自研的桌面客戶端 「敦煌」 平臺。基於客戶端的能力，能將分散的工程能力進行聚合，並造成鏈路的串聯能力，結合 GUI 的直觀和簡便操做，進一步的省事。經過桌面客戶端，能夠將平常的前端研發鏈路上的操做都聚合進來，從組件開發到模板開發再到應用開發；從喚起編輯器到啓動調試環境、進行包更新到打包部署發佈。同時桌面端系統還能和其餘的研發系統進行打通，造成更多的能力。

4. 組件開發與管理

通常狀況下，前端團隊都會完善本身的組件庫體系，有些狀況下一些 UI 組件庫可能採用社區開源的優秀三方庫，如 antd，但多多少少還會有本身的業務組件庫須要封裝。工具的價值在於抹平差別，將基礎標準一致化。對於組件開發，前面所述的 CLI 工具鏈是這裏的底層依賴，同理還有後面介紹的模板開發與使用，以及應用的開發。經過工具進行組件的開發和管理，能夠較好的實現諸如組件命名標準化、版本標準化、查找便利性、開發流程簡化等，還能實現組件的應用場景統計和版本覆蓋率等涉及到組件在接入場景更新成本相關的必要統計。

5. 模板開發與管理

同飛冰相似，咱們也沉澱了一套相似的模板化能力，便於中後臺業務場景的快速開發。由於中後臺的業務場景相對固化，諸如表單、列表等居多，基於模板的方式能夠省掉很大一部分製做 Demo 和實現交互的成本。模板的前提是 UI 組件庫的完備，和標準的中後臺交互、視覺設計，基於此沉澱標準化的業務模板庫，根據場景選擇合適的模板，配置下頁面信息和路徑後，就能夠一鍵安裝到本地並自動化配置好路由，安裝好依賴。

6. 項目建立與管理

項目的建立與管理，從一開始咱們的目標就是 「去耦合，單人可全流程 Hold」 —— 意思是在項目的建立、本地環境的搭建（也包括了環境的升級）、分支管理、構建、部署等環節，前端同窗能夠徹底一人搞定。不須要由於權限的問題找人幫忙建倉庫；不須要由於組件、區塊、模板、應用（SPA/MPA）、選型（React/Vue）致使本地開發環境的標準不一致進而每次都得學新的；不須要頭疼不一樣業務的版本流程不一致致使還得問這問那；不須要還得人肉的去配置打包腳本；不須要每次部署都得找人（或者是運維）幫忙... 總之，咱們但願藉助工具抹平平常中太多的不對稱，將開發者的專一力從新儘可能拉回簡單純粹的編碼中。即便是一個對 Git、命令行、應用管理流程不太明白的校園新人，在桌面端可視化工程的系統輔助下，也能很愉快的開始編碼。

7. 前端基礎資產

前面咱們提到了前端團隊的規範（標準化）、工具鏈（CLI）、基於工具鏈之上的可視化輔助客戶端（GUI），提到了組件（模塊）、模板、應用。對工具的抽象和業務的可複用抽象，是一個團隊的基礎資產。簡化到 Webpack 擼一個腳手架 + 一套開源三方 UI 組件庫，剩下的拼裝式生產全靠人肉；複雜些諸如阿里系正在突破的 UI2Code 、編輯器等能力，將標準、流程更自動化，進一步的去人肉。基礎資產這部分，咱們團隊目前業務階段下的建設分層以下：

8. CI/CD 自動化構建部署

前端具有本身的構建部署系統，便於專業化方面更好的流程控制。政採雲前端團隊在 2019 年下半年建設了本身的構建部署系統，實現了雲打包、雲檢測和自動化部署（打通對接運維的部署系統）。新的獨立系統在設計之初，重點就是但願能實現一種 Flow 的流式機制，以便實現代碼的合規性靜態檢測能力。這部分在系統中最終實現了一套插件化機制，能夠按需配置不一樣的檢測項，如某檢測項檢測不經過，最終會阻塞發佈流程，這些檢測項有諸如：

• *Lint 檢測
• 兼容性 API 檢測
• HTTPS 檢測
• 包檢測（黑名單、包版本）
• 合法性檢測（域、連接）
• 404 檢測
• 基礎的 UI 檢測（如是否缺乏吊頂）
• ...

9. 可視化搭建系統

可視化搭建系統是進一步高效利用組件的上層建築。頁面是由組件（業務模塊）組成，搭建系統將組件的拼裝由本地人肉操做，產品化到系統中可視化拼圖，將頁面搭建、數據配置、構建部署、數據埋點等等產品化，賦能給產品、運營等協做方。前端產出組件，運營搭建頁面，既能節省前端的人效，也能讓運營能力前置拓展，在營銷場景中進一步釋放運營的業務能力，實現雙贏。

關乎可視化搭建系統的更多，能夠查看咱們團隊以前輸出的這篇文章：《前端工程實踐之可視化搭建系統》

系統架構圖：

部署流程圖：

10. 數據埋點與分析

在不少公司，數據埋點與分析每每是 BI 部門的事情。在政採雲，由於公司前期 BI 能力相對不足，前端團隊首先發起並推進了面向業務的 Web 數據埋點收集和數據分析、可視化相關的全系統建設。先後實現了埋點規範、埋點 SDK、數據收集及分析、PV/UV、鏈路分析、轉化分析、用戶畫像、可視化熱圖、坑位粒度數據透出等數據化能力。

更多數據埋點與分析相關，能夠查看咱們團隊以前輸出的這篇文章：《前端工程實踐之數據埋點分析系統》

11. 頁面性能自動化分析

頁面性能，90% 在前端。尤爲是像咱們公司現階段 toB 爲主的業務，不一樣於個人老東家（淘寶、蘑菇街）早已移動端佔絕對主導，咱們依然是 PC 場景佔大頭，在頁面性能方面問題仍是比較突出。過去 1 年時間內，給你們可參考的路徑是，咱們首先發起了圖體積優化，針對佔據頁面體積大頭、請求數大頭的圖片首先發起優化策略，採用規範+工具的方式幫助業務快速實現圖體積的優化，相關沉澱可見早先團隊的這篇《爲你從新系統梳理下， Web 體驗優化中和圖有關的那些事》。後來，咱們逐步基於 Node 能力將梳理出的影響頁面性能的點，實現了自動化檢測能力，並依據不一樣的業務場景區分設計檢測模型，再後來作了定時任務來實現性能的連貫性分析及數據走勢能力，再以後又增長了業務性能數據大盤和每週的紅黑榜。關於頁面性能自動化分析系統的更多細節，可閱讀咱們團隊早前的文章 《自動化 Web 性能分析之 Puppeteer 爬蟲實踐》、《自動化 Web 性能優化分析方案》。

12. 2019 基建里程碑

上面介紹的一部分政採雲前端團隊的技術基礎建設，基本上都是在 2019 年一年內逐步建設落地並取得結果的。下圖是在上一年週期中的建設里程碑，能看出對應的建設週期和節奏。在我這個團隊，沒有單獨設立獨立的前端架構組，前端下的團隊都是業務團隊，咱們同窗從業務支撐中沉澱問題，針對問題進行思考和聚斂，從業務問題出發針對性的推動對應的建設。

對於研發同窗來講，身價取決於解決問題的能力，取決於面對不一樣的業務問題是否具有解決問題的方案。咱們團隊很慶幸的點在於，業務處於快速發展期，問題不少，既有的沉澱不多，咱們很幸運的能夠在幫業務解決問題、跟隨業務快速發展的過程當中，幾乎是從零開始作這些建設。這是很難得、很可貴的一段經歷，由於大部分的公司要麼是體量還沒到須要作這些的地步，要麼是早就作完了輪不到，沒法全程看到整個體系的發展。公司要爲員工創造環境，但員工的成長最終是靠本身。因此同窗們都承認用業餘的時間參與建設、甚至是主導某個方向，對自身的成長是個寶貴的機會。

6、基建以外

1. 凡是建設，必有數據

凡是建設，必需要有對應的數據收集和分析，數聽說明基建帶來的改變，說明投入產出比。數據指標的設計，須要在某專項建設的前期即設計好並進行採集，並在整個推進週期和落地後持續收集，這樣能夠獲得一個相對完整的變化曲線，用以做證工做的成效。數據不見得必定是徹底精準的，但數據必定要能說明趨勢，直觀化，反饋準確。

2. 從場景出發找方案

對於人力方面，任何狀況下人力都是缺失的。但不少時候咱們的建設推不下去，每每不是由於人力的問題，而是沒想清楚。《莊子·列寇傳》有一則寓言，「朱評漫學屠龍於支離益，單千金之家，三年技成而無所用其巧」。 講的是一我的散盡家資學習屠龍之技，學成卻發現世界上本沒有龍。對於研發同窗，一樣會存在從方案出發找場景的問題，如想學習 Node 不知道如何學習，照着書中的例子學，最後發現都忘了效果很很差。沒有一個做家是看小說當作的，也沒有一個語言學家是看字典當作的，同理技術專家也不會是經過看技術書籍養成的。在實踐中學習，歷來都是最快的方式。有價值的事歷來都是從業務自己的問題出發。問題就是機會，問題就是長蘿蔔的坑。

3. 不設限，拓展能力邊界

前端在研發體系中話語權偏低的現狀，從前端這個職能出現那一刻就存在了。不排除個別研發團隊，因其業務模式的緣由，對前端的依賴較深，前端的話語權相對偏高。絕大部分的研發團隊中，前端的工做，在其餘研發眼中，每每是 「技術含量低」、「很薄的一層」 等狀況。這個現狀的背後，看看下圖就知道了：

橫、縱，2 個維度。右邊的 「縱」，參考網絡應用系統的分層體系，前端的傳統工做範疇，都是集中在 「用戶界面層」，不多能往下深刻，深刻到網關 ~ 基礎設施層。後端則不一樣。從這個角度看，前端確實很 「薄」。如今良性的一面是，Node 能力爲前端提供了向下滲透的服務端能力。一些團隊也基於 Node 橫向擴展自身的工程化能力，和向業務縱深去拓展前端的系統化能力。

咱們再看左邊的 「橫」。只有不多的前端團隊，能較完善的去建設和發展技術體系。對於有了較完善體系的前端團隊而言，其技術體系也更可能是侷限於前端自身的職能範疇，沒能較好的互動滲透到業務側，更可能是在自嗨，業務的感知力是很弱的。將技術帶來的工程收益，轉變爲業務收益；將部門內的技術影響，轉變爲業務影響；將技術場景，升級到業務場景；將團隊的基礎能力，變爲業務能力。跳出前端，圍繞並深刻業務，這是每個正在推進團隊體系建設的同窗要更多想一想的事。

4. 業務的階段匹配性

基建的內容，是和業務階段相匹配的。不一樣團隊服務的業務階段不一樣，基建的內容和廣深度也會不一樣。高下之分不在於多寡，而在於對業務的理解和支持程度。若是你只須要一根針，千萬不要去磨鐵棒。

5. 技術的價值，在於解決業務問題

技術的價值，在於解決業務問題；人的身價，在於解決問題的能力。但解決問題，技術基建毫不是銀彈，甚至在我來看，都不是排在前三位的。

7、最後

最後，是一個須要你們都思考下的問題：