前端資源治理（一）：問題及思路

做者：李剛鬆

0.也談前端工程化

隨着前端技術的飛速發展，前端須要一種更加工程化的方式解決前端開發日益複雜的問題。前端工程化本質也是軟件工程的一種，因爲軟件工程並沒有嚴格的定義(或者說缺少統一的定義)，所以前端工程化的內涵其實至關寬泛，通常來講，前端工程化重點關注的是研發和維護效率，全部最終目的是這個的，均可以算做前端工程化的範疇。 前端工程化近幾年也是技術熱點，基本上大型前端技術交流會議都有此專題，從規範、組件、編譯及構建、工做流、持續集成、監控等多個維度都有涉及，筆者嘗試從前端資源治理的角度談一下前端工程化,本文是系列文章的第一篇，主要講問題及解決的思路，不涉及具體的實現細節。

1.前端資源治理的含義

首先，這裏所說的前端資源，並不是是僅指js、css、圖片等靜態資源，頁面、後端接口、配置數據、監控點等，均可以歸入前端資源的定義的範疇。

在工做中，你是否會碰到如下問題：

1. 同事或者領導發現某個頁面有bug，須要在微信羣或者內部溝通工具大羣裏問是誰負責？可能還要挨個艾特各個TL，須要各個TL確認。
2. 某個組件要升級，可是不知道那些頁面使用了，須要在溝通羣裏問或者搜項目源代碼，逐個找到負責人。
3. 某個大型營銷活動忽然要換一個新的氛圍logo，可是不知道哪些頁面使用了舊logo，須要安排巡檢，人肉去找出來。
4. 告警發現某個重要頁面的出現了內容空窗，緣由是運營同窗沒有及時補充運營數據，可是不知道是哪一個運營負責，須要在微信大羣或者內部溝通工具大羣裏問。
5. 大促來臨，某個重要頁面的流量預計有10倍或者20倍的增加，要通知各個接口的同窗作擴容和容災準備，須要手工梳理頁面的依賴的接口列表。
6. 某個限時的頁面已經到點下線，可是仍然有流量，不知道流量入口在哪裏。
7. 我要在統計系統上查看某個頁面的性能數據，可是該系統是以頁面名字而不是地址來查找的，查找過程找的人老眼昏花。
8. 某個後端接口要升級或者要下線，須要分析nginx的訪問日誌找到頁面地址，而後再拉各個TL，逐個確認都是哪些同事負責。
9. 等等等

上面的問題通常是大型複雜業務場景（一般是多個團隊合做開發，業務複雜，頁面成百上千甚至上萬）下才有的，若是你所在的團隊也有上面的問題，那麼我認爲你也須要對前端的資源進行治理。

那麼什麼是前端資源治理呢？筆者對其的定義是：

將前端相關的頁面、js/css/圖片/字體、接口、配置、監控點等的依賴關係進行收集、存儲和管理，並將割裂的組件系統、配置系統、監控系統、業務系統等進行重構和整合，最終造成以頁面管理爲基礎的統一的有序的平臺，全部關聯信息都可以被查詢和檢索，最終實現總體協做效率的提高。

此處使用「治理」而不是「管理」的緣由，「治理」一詞更強調合做整改的過程。在不少互聯網企業，一般已經有一些獨立的組件系統、配置系統、監控系統等，可是這些系統不少都是獨立的碎片化的系統，彼此都是割裂的，割裂意味着缺少協同，進而影響研發效率。所以，前端資源治理的一個關鍵詞是「整合」，整合已有的系統。

第二個關鍵詞是「關聯關係管理」，前端相關的頁面、組件、js/css/圖片/字體、接口、配置、監控點及負責人等，他們是存在關聯關係的，好比頁面是誰負責的、誰修改的、引用了哪些組件、圖片、字體、接口、在什麼地方配置數據、監控點都有哪些等，咱們須要把這些關聯關係在管理端記錄下來，並提供檢索和查詢。

2.前端資源治理的實現

前端資源信息看似繁雜，js、css、圖片、頁面、後端接口、配置數據、監控點等，可是他們有一個串聯的錨點，這個錨點就是頁面，不論是H五、小程序，仍是原生APP，不論是從研發的角度，仍是從反饋問題的角度，基本上都是以頁面爲單位進行的，其餘的如組件、CSS、圖片、接口、配置等，都是被頁面引用的，均可以經過頁面串聯起來的，下圖能夠清晰的表達出這些依賴關係。

所以，實現前端資源治理的第一個要點是作好頁面管理，把頁面自身的信息，如頁面名稱、頁面地址、負責人、修改時間等信息進行提取、存儲,使之可以被查詢和檢索。在頁面管理基礎之上，咱們還要把js、css、圖片、頁面、後端接口、配置數據、監控點等各個前端資源之間的關聯關係也要存儲和管理起來，使之可以被查詢和檢索。

關聯關係歷來源上講，主要有如下幾種來源：

1. 代碼靜態分析產生。一般包括頁面信息自身、頁面跟js/css/圖片等的依賴關係、頁面跟接口的依賴關係等。
2. 管理端配置產生。一般包括頁面跟監控系統的配置、頁面的運營配置數據等
3. 統計數據產生。一般包括頁面來源數據等。

2.1 頁面信息的提取

前端資源治理的第一要點是頁面信息管理，所以必須可以拿到頁面基本信息。頁面基本信息應該包括哪些呢？一般來講，至少應該包括頁面URL、頁面名稱、頁面建立人、建立時間等幾個字段。

當前的前端頁面開發，不論是H五、小程序，仍是原生APP，一般會通過編譯構建的過程（一般是命令行工具或者IDE，好比基於gulp和webpack的工做流工具），在構建完成階段能夠提取出頁面的基本信息。如下是編譯構建提取頁面信息的流程：

頁面的編譯構建流程，通常分爲兩種：

1. 獨立構建。常見於H5，此種場景通常是一我的負責一個頁面，不存在多人協做的狀況，也不須要git分支管理啥的，開發完成便可走構建流程，只須要在構建完成的時候分析便可，頁面的URL、頁面標題、建立人、建立時間等信息比較容易提取，好比頁面修改人能夠取自命令行工具的用戶登陸身份（命令行工具能夠作相似於NPM的login功能，登陸後記錄用戶身份ID）、頁面標題能夠解析頁面html的title的內容（小程序下則解析自頁面json文件的navigationBarTitleText字段）等。
2. 持續集成構建。這種通常是須要多人協做的H五、小程序、原生APP等，通常涉及到分支管理和合並的問題，同一個頁面可能被多人修改，所以頁面信息中的用戶信息部分提取相對複雜，須要分析git log信息才能拿到，其餘的信息字段提取邏輯與獨立構建狀況相同。 如下是一個典型的多人協做的頁面的git log信息。

對於上面的狀況，咱們能夠考慮定一個規則，好比取最近的5條log，並移除持續集成系統生成的log，管理端存儲的時候回，以用戶名+時間爲key，去掉重複的部分。

構建流程分析出頁面基本信息後，需提交到管理端保存，因此管理端須要提供post接口。管理端以此爲基礎，造成」頁面管理系統「。

2.2 代碼靜態分析出的關聯關係

構建流程除能夠分析基本信息外，還能夠分析出頁面的版本信息，好比頁面依賴的組件依賴表、靜態資源依賴表(js/css/圖片)、接口依賴表、修改人、修改時間等。 靜態依賴分析一般有3種方式：

1. 基於AST的依賴分析。 AST就是抽象語法樹，目前前端對他的研究和使用愈來愈普遍，webpack內部就使用了acorn這個AST分析庫。藉助於webpack強大的模塊解析和依賴分析能力，咱們能夠拿到js與npm組件、css與背景圖等之間的關聯關係（能夠在webpack的after-resolve鉤子中進行分析）。另外，除了構建前的依賴關係，咱們還能夠拿到構建處理後的資源依賴關係（能夠在webpac的emit鉤子中進行分析），前者咱們稱爲引用依賴關係（包括靜態資源依賴表、組件依賴表），後者咱們稱爲發佈依賴關係。
2. 基於DOM操做的依賴分析。 webpack並非以html爲入口的，可是實際上咱們的開發的入口能夠認爲就是頁面，藉助於JsDom等強大的類庫，咱們能夠用咱們熟悉的前端的DOM操做來分析html頁面對js、css、圖片等的依賴關係。
3. 基於正則匹配的依賴分析。 頁面對於接口的依賴分析，因爲這種是非明確的代碼依賴關係，因此通常經過正則匹配來解析。通常對代碼有必定的約束規則，好比不用用變量拼接接口地址。這個解析不會如AST那麼精確，可是隻要約定規則，基本上都能知足需求。能夠考慮把此類實現封裝爲webpack的loader。

   

   上面的第一種和第三種的分析，都應該是一個遞歸分析過程，最終生成頁面的靜態資源依賴表、組件依賴表、接口依賴表等。這些信息提交到管理端進行保存。

2.3 管理系統之間的關聯關係

在不少互聯網企業，一般已經有一些獨立的成熟的CMS系統（如給運營用的內容配置系統，配置活動時間、商品ID等）、監控系統（如測速系統、業務監控系統、異常監控系統）等，一般這些系統由不一樣的團隊開發，並且常常都有一個叫作"頁面管理"的東西，且要手工配置頁面地址。這些系統中的監控點配置、運營配置等信息，都是以頁面維度進行建立和使用的，可是這些信息很難經過對前端代碼靜態分析的方法進行提取（好比運營配置信息，這個能夠是前端直接使用，也多是後端使用，要分析的話兩端代碼都要分析，比較麻煩）。咱們的思路應該是在管理端經過頁面管理來進行關聯，實質上是要作系統整合。

整合的思路也比較簡單，就是原來各個系統廢棄掉原來自身的」頁面管理「，而是使用前面靜態分析提取到的統一的頁面管理，監控系統、運營配置系統等系統均可以以此爲入口進入，從而把頁面相關的各個管理系統關聯起來，進而把各類能力串聯。

2.4 統計數據產生的關聯關係

對於大型應用來講，通常都有一些業務統計數據，最典型的就是點擊流數據了。這種數據既不在代碼中，也不在管理端配置，並且經過統計和分析才能拿到。前面提到的「某個限時的頁面已經到點下線，可是仍然有流量，不知道流量入口在哪裏」這種問題的解決，其實依賴於點擊流的統計分析數據了，點擊流系統通常都有「來源分析」，這種數據也不是敏感數據，因此能夠考慮跟頁面管理作關聯和整合，或者提供API給頁面管理系統。另外還有一個例子就是，接口和頁面的關聯關係，前面提到經過靜態分析獲得的頁面和接口的依賴表有可能不夠準確，可是接口訪問Web Server的時候，通常都有access.log，能夠經過access.log來作分析，拿到比較完整的頁面依賴的接口信息，以及接口依賴的頁面信息，有些接口的調用須要有open api的那種註冊調用機制，就另當別論了。

2.5 關聯關係的查詢和存儲

管理端應該提供正反兩個方向的查詢和檢索能力：

1. 正向查詢。經過頁面來查詢依賴的組件、靜態資源(js/css/圖片)、後端接口等。此種比較簡單，由於提交的時候已經有完整的依賴信息，只須要提供簡單的查詢。
2. 反向查詢。經過組件、靜態資源、接口、運營配置信息、監控配置信息等，反查有哪些頁面依賴。

對於關聯關係的存儲，用關係型DB的話，通常只能使用like查詢，可能要掃描全表，於是性能比較差，能夠考慮存儲到MongoDB中建立索引，或者存儲到ElasticSearch中創建索引。

2.6 其餘

前面提到的，其實有一個假設的前提「只有一個Web應用，且接口都是前端發起的」，可是對於其餘狀況，思路是相似的：

1. 多應用（業務）。多應用狀況，一般要在頁面管理的上一層加上「應用管理」，即頁面屬於哪個應用(業務)。對於同一個頁面投放在不一樣應用的場景，可能頁面還得加上渠道標識。
2. 頁面直出（服務端渲染）。對於頁面直出邏輯的代碼，作前面相似的分析便可。 另外，本文主要是探討從前端視角考慮問題，因此關聯核心是頁面管理，可是從總體技術架構視角，可能就不是了。

3.結語

本文探討了前端資源治理的含義以及要解決的問題，並介紹了實現前端資源治理的思路，是筆者近期在前端工程化方面的思考，部分已經完成，部分正在推動。本文並不涉及實現的細節，細節在後面的系列文章中進一步講解。 前端治理的兩個關鍵點，一個是系統整合，一個是關聯關係管理，總體串聯的核心是頁面管理。

---

若是你以爲這篇內容對你有價值，請點贊,並關注咱們的官網和咱們的微信公衆號(WecTeam)，每週都有優質文章推送：