近兩年，前端複雜度持續攀升，從框架到開發模式都衍生出了無數的技術方案。單點的小規模嘗試，導致團隊內部技術棧以及實現方案出現分化，間接造成了知識庫之間的隔離、項目之間模塊複用率下降，人員在不同項目中的學習成本大大增加，技術管理成本被大量轉嫁到人員管理上。
例如，同一種平臺因為技術方案管控問題，導致執行路徑產生偏差，細節複用艱難。
那麼，如何實現人與工程的規模化管理，並優雅的驅動項目？本文將詳解阿里文娛的實踐及思考，尤其是整合各業務方向、技術實現拉齊、能力複用方面。
我們該怎麼做？
經過詳細的技術及收益評估，我們決定在阿里基礎前端工程服務的基礎上，搭建文娛自己的前端工程研發系統，用以高效承接及處理在前端工程領域上所遭遇的挑戰。
1. 收斂 & 聚焦
大部分問題的誘因是缺乏統一的工具入口，而工具作為工程開發模式的重要指導急需統一的工具開發規範。
在此之上以“收斂 & 聚焦”為目標，我們開啟了“終端 + 服務”的執行思路，落地了兩個工具：
1） 工具集成工具 Hub Cli：集成其他二次開發工具，提供統一的工具接入接口；
2） 工具服務平臺 Hub Service：提供工具依賴的基礎服務。
2. 強化 & 賦能
通過工具服務平臺對一些能力型問題進行針對性增強，如用戶身份校驗，從而將通用型能力賦能到各業務開發場景。
1） 自動接入雲構建
基於 Hub Cli 開發的工具默認支持開啟雲構建，採用阿里集團雲構建方案，進行統一的數據採集。
2） 用戶識別
基於 Hub Cli 開發的工具自帶用戶識別接口，用以快速識別用戶針對性下發配置。
3） 工具灰度控制
傳統工具版本控制基於 Npm 管理，無法快速的進行回退或者廢棄版本；基於 Hub Cli 開發的工具，則可以通過工具服平臺，快速實現對人 / 系統 / 特定環境的快速灰度 (對雲構建同樣生效)。
4） 日誌採集
基於 Hub Cli 開發的工具自動識別工具上報錯誤信息，幫助工具開發者快速定位工具問題。
為什麼不使用集團前端工程工具
我們通過比較後決定下沉集團前端工程工具相關服務能力，以期在文娛層面達到更深的管理能力、靈活的方案定製能力。同時通過入口的收斂，降低各子團隊對於集團基礎前端工程服務的直接訴求，降低集團基礎前端工程服務團隊直接對接諸多一線業務團隊的壓力。
1） 大部分工程訴求不再依賴集團基礎前端工程服務團隊支持，方案制定更加靈活；
2） 對文娛前端工程狀態首次有了可觀測的可能；
3） 系統化的工具研發方案，大大加強工具能使用的能力，比如用戶信息的獲取，比如更新控制；
4） 自上而下的流程管控，便於隨時增加工程卡口。
工程抽象
為了更好的實現一個工具集成平臺，則需要對整個工程流程進行定義與抽象。
1. 工程生命週期
在工具入口層面定義了五個基礎的工程生命週期，覆蓋整個開發流程，降低工具間的學習成本，解決開發流程的規範問題。
1） 初始化項目：hub init
2） 將代碼部署至日常：hub daily
3） 將代碼部署至線上：hub publish
4） 構建項目：hub build
5） 啟動開發服務：hub server
6） 啟動代碼測試：hub test
2. 可編排流程
對於發佈流程的抽象，可幫助工具開發者更好的定義工具用戶的發佈行為，下圖展示了對與 Assets 發佈流程中的流程定義，實現了對分支的自動維護；工具開發者可自行定義流程從而降低使用者的操作成本。
3. 流程鉤子
從生產到完成發佈，整條流程線上分為三部分，分別提供流程鉤子，用於做中間狀態的校驗。鉤子校驗採取阻斷式。
4. 質量卡口
通過增加生產發佈前的強制卡口。
流程管控
1. 工程方案下放
Hub Cli 會在執行命令時啟動，啟動會經過一輪 Check 流程，包含兩部分內容更新:
1） 主程序更新檢測
2） 工具更新檢測
當發現存在新版本時，會通過 Hub Cli 內置更新模塊進行自動更新，確保所有模塊的運行版本為最新版本。
更新流程為強制更新，不可手動關閉是出於對工程方案覆蓋率的考慮。及時覆蓋就意味著版本斷層的問題會被削弱，集中更新，集中處理。
2. 自動化發佈流程
以改動提交場景為例，傳統流程操作下，至少需要三步操作：
<code>$ git add .
$ git commit -m '提交信息'
$ git push origin daily/0.0.1/<code>
步驟越多，出錯的可能性越高。我們通過流程編排，將操作完全自動化：
<code>$ hub daily -q/<code>
3. Commit 規範化
通過內置的 commit 管理模塊，簡化的同時取規範化 commit 提交數據，實現開發數據的有效沉澱，培養技術同學的優質編碼習慣。
4. 平臺聯動
基於鉤子的多平臺聯動，通過 hook 設置的方式，實現發佈後對其他平臺的調用通知。
5. 代碼質量檢測 &Code Review
使用 Hub 自動接入發佈系統的項目將默認開啟以下門神檢測插件：
- HTTPS 協議檢查
- 文件元信息檢查
- 內部域名檢查
- 代碼註釋檢查
- NPM 模塊 License 檢查
發佈的代碼需要經過自動校驗通過後才可發佈至生產環境。除開自動檢測外，還可以選擇打開 Code Review 流程，只有經過 Code Review 流程後才可進行發佈至生產的操作。
特定場景
1. 自動化更新
工具多是全局安裝，因為全局環境權限問題，導致全局工具不能自更新，所以目前主流終端方案是隻進行版本檢查提示更新。
這種方案雖然解決了新版本通知的問題，但是弊端是依舊要人主動更新。
為此我們設計了一套基於全局環境的更新流程。主程序啟動過程中會進入一個預先檢查環節，預檢查過程中會先檢測存在的程序副本，若副本存在則啟動子進程執行副本，而副本中會先進行自生版本檢查，如果存在版本更新則通知主進程進行副本版本更新，當自身版本檢查通過後，才會進入程序正式執行階段。
通過對副本儲存目錄的控制，繞過了全局的權限校驗，實現了任意環境下的自更新操作。
2. 模板引擎
對於模板引擎，我們簡化了相關設計，基於 Gitlab 託管，結合 Ejs 模板引擎，實現了一套輕量化的模板引擎系統。
3. 終端用戶識別
基於阿里基礎前端工程服務的終端授權模式，實現了 hub 的終端用戶授權能力，並實現了與阿里基礎前端工程服務登錄狀態的完全拉通。
4. 千項（目）千面
通過對項目內配置文件.hubrc 的識別，自動掛載對應的工具；根據工具的不同改變 Hub Cli 的能力。
垂線領域沉澱
通過基礎工程平臺的沉澱賦能特定領域工程方案，加速特定領域研發效率，讓工具開發者更專注於工程需求本身以及領域內的工程訴求。
1. 中後臺場景
基礎平臺完善後，中後臺技術方案開始聚焦，開始系統化設計 / 解決中後臺場景下的提效問題。
- 物料平臺（用於沉澱通用型物料）
- 中後臺研發中心（用於沉澱開發 / 設計規範）
- API 網關服務（用於前後端解耦，接口快速編排）
- 應用託管平臺（用於聯動發佈鏈路自動化部署）
2. 搭建平臺場景
文娛活動運營搭建平臺的工程訴求基於 Hub 孵化出的工程體系。
- 物料平臺（用於沉澱通用型物料）
- 依賴分析服務（用於在線搭建動態渲染）
- 構建服務（用於平臺特殊場景部署下的動態構建）
經驗複用
- 採集：將在日常開發中產生的錯誤收集起來，並統一解答歸類存檔。即可自動歸類生成一個錯誤的知識庫。
- 消費：在錯誤發生時即可從錯誤的知識庫中查找出對應結果處理。
工程數據化 (圖形化示例)
通過流程收斂，使得整個團隊的工程狀態可以被監控，讓數據的沉澱產生價值，優化 / 指導工程迭代，讓每個技術人的努力可以被量化。
小結
上面是我們對前端工程如何規模化管理的思考與實踐，整體來說就是工程入口的收斂 & 管控，加上領域方案的優勝劣汰，通過領域內經驗的橫向複用實現整體前端工程能力的提效。
閱讀更多 流浪的思維 的文章
