管控平臺

在上一篇中我們提到了元件化的大致思路，這一篇主要講述在這麼做之後，我們需要哪些外圍手段去管控整個開發過程。從各種角度看，面對較大規模前端開發團隊，都有必要建立這麼一個開發階段的協作平臺。

在這個平臺上，我們要做哪些事情呢？

1. HTML片段

我們為什麼要管理HTML片段？因為有介面要用它們，當這些片段多了之後，需要有個地方來管理起來，可以檢索、預覽它們，還能看到大致描述。

這應該是整個環節中一個相對很簡單的東西，照理說，有目錄結構，然後剩下的就是單個的HTML片段檔案了，這就可以解決儲存和檢索的問題了，但我們還要考慮更多。

已有的HTML片段，如何被使用呢？這肯定是一種類似include的方式，通過某種特殊標籤（不管是前端還是後端的方式）把這些片段引用進來，這時候就有了第一個問題：

假設有介面A和介面B同時引用了片段C，在某個開發人員修改片段C內容的時候，他如何得知將會影響到介面A和B呢？一個比較勉強的方式是全專案查詢，但這在很多情況下是不夠的。

如果我們的HTML片段是作為獨立的公共庫存在的，它已經不能通過專案內查詢去解決這一問題了，因為不管A還是B，只要他不處於片段C的專案空間，就無從追尋。

這時候很多人會問兩個問題：

1. 跨專案的介面片段重用，意義在哪裡？如果我們的產品是針對一個小領域，它的複雜度根本不需要劃分多個專案部分來協作完成。設想場景是面對很大的行業，各專案都是子產品，將來可能是其中若干個 聯合部署，這時候，保持其中的一致性是非常重要的。比如我們有個基本配置介面，在多個子產品中都要用，如果各自開發一個，其操作風格很可能就是不一致的， 給人的印象就是不專業。所以會需要把常見的介面片段都歸集起來，供業務方挑選使用。
2. 修改C，只提供說明，但是不通知A和B，不實時更新他們的版本，然後自行決定怎樣升級，如何？這會有一個問題，每次有小功能升級的時候，程式碼是最容易同步合併的，所以才會有“持續整合”這個概念，如果是一直伴隨升級，總要比隔一個大階段才升級好，升級成本應儘量分攤到平時，就像農婦養小豬，小豬每天長一點，每天都抱來抱去，不覺得吃力，即使長大了也還能抱得動。

現在問題就很明確了，一定要有一種方式來把這個依賴關係管理起來，很顯然，已有的版本庫是肯定管不了這些的，所以只能在外圍做一些處理。

我們建立一個管理平臺，除了管理實體檔案的版本，還管它們之間的關係。具體這個關係如何收集整理，有兩種方式：手動配置，程式碼分析。

手動配置是比較土的方式，開發人員每提交一個檔案，就去這系統上手動配置它的依賴關係。程式碼分析的話，要在每次提交檔案的時候解析檔案的包含規則，找出確切的檔案。這兩者各有利弊，前者比較笨，但容易做，後者對程式碼格式的要求比較高，要考慮的情況較多。

我們的介面往往不是那麼簡單，HTML片段也可能有層次的，舉例來說：

介面A裡面包含了片段B，但是片段B自身又包含了片段C，所以這個依賴關係也是有層級的，需要在設計的時候一併考慮。

2. JavaScript模組

JavaScript程式碼的管理，比HTML片段的狀況好一些，因為業界很多這方面的解決方案。但它們還是沒有解決當依賴項產生變更的時候反向通知的問題。

所以我們還是得像HTML片段一樣，把它們的依賴關係都管理到平臺裡。於是，每個JavaScript模組都顯式配置了自己所依賴的其他模組，通過這種單向關係，形成了一套完整的檢視。

在JavaScript模組的程式碼實現中，我們是不提倡直接寫依賴關係的。很多通用規範，比如AMD，往往建議我們這樣寫模組：

但我們的系統是面向行業的，比這種通用解決方案要苛刻一些。比如說，如果有一天重構程式碼，JavaScript模組們調整了目錄或者名字，這麼寫的 就痛苦了，他必須把所有影響到的都去調整一遍，這是要搜尋替換的。況且，就像上面HTML模板的部分提到的，影響了處於其他專案中依賴它的程式碼，缺少合適 的方式去通知他們修改。

所以我們期望的是，在每個編寫的JavaScript模組中只存放具體實現，而把依賴關係放在我們的平臺上管理，這樣，即使當前模組作了改名之類的重構處理，處於外部專案中依賴它的那些程式碼也不必修改，下一次版本釋出的生成過程會自動把這些事情幹掉。

對應到上面的這段程式碼，我們需要開發人員做的只是其中的實現，也就是moduleA的那個部分，外面這些依賴的殼子，是會在釋出階段根據已配置的依賴關係自動生成的。

如果需要，JavaScript模組還可以細分，比如類似Angular裡面那樣，把factory，controller和directive分離出來，這會對後續有些處理提供方便。

現在我們有必要討論一下模組的粒度了，我們這裡提到的都是基本的粒度，每個JavaScript模組中存放的應該只有一個很具體東西的實現。那麼，有個問題，在我們釋出的時候，是不是就按照這個粒度釋出出去呢？

很顯然不行，如果這麼做，很可能會出現複雜介面一次要用10多個HTTP請求才能載入完它所需要的所有JavaScript程式碼的情況，所以需要做一些合併。

那麼，合併的策略是什麼？在我們這個平臺上，開發人員又是要怎樣定義這個合併關係的呢？我們需要在模組之上定義一個更大粒度的組織方式，這個方式與 模組的關係，就好比Java裡面，jar檔案與class的關係。如果開發人員不顯式配置，也可以通過全域性策略，比如按最下層目錄來合併。

這個時候，在實際使用這些程式碼的時候，需要帶兩個配置資訊過去，一個是要動態載入的JavaScript檔案（合併之後的），二是每個JavaScript檔案中包含的原始模組。

3. 單元測試

如果JavaScript模組都已經被良好有序管理起來，就可以為它們考慮單元測試的事情了。單元測試對於提高基礎單元的可靠度，是有非常重要意義的。

在我們這個平臺裡，可以把單元測試跟JavaScript模組關聯起來，每個JavaScript模組可以掛一組單元測試程式碼，這些程式碼可以線上編寫，線上執行。

單元測試的本質就是編寫模擬程式碼來呼叫已有模組，考慮到我們的模組是JavaScript，所以很多思路都傾向於在瀏覽器端執行它們，對於單個模組的單元測試，這不是個問題。

如果要批量執行整個系統的單元測試，那就不一樣了。把JavaScript程式碼先載入到瀏覽器中，然後再執行，很多時候並不需要這麼複雜。我們完全可以在服務端把它們做了。

藉助Node.js的能力，我們可以在服務端執行JavaScript程式碼，也就意味著能夠把絕大多數JavaScript模組的單元測試在服務端就執行掉。當然，我們為此可能要多做不少事情，比如說，有些庫需要移植一份node版的，常見的有AJAX呼叫等等。

注意了，能夠在服務端做JavaScript單元測試是有先決條件的，程式碼的分層必須很良好，除了檢視層，其他任何層面都不能操作DOM。所以我們 這裡主要測試的也正是除了檢視層之外的所有JavaScript業務邏輯。至於檢視層怎麼辦？這個真的很難解決，這世界上不是所有東西都能自動做的，只能 先把可做的做了，以後再來考慮這些。

4. 文件和示例管理

4.1. 文件

現在我們有HTML片段和JavaScript模組了，需要給它們多一些描述資訊。簡單描述顯然是不夠的，我們還要詳細文件。

這種詳細文件可以通過某種方式生成，也可以由開發人員手動編寫。與傳統的離線文件不同，線上的文件更實時，並且，每當一個開發人員變更了他的文件之後，不需要經過全量構建，訪問者可以實時訪問到他的最新版本。

熟悉GitHub的朋友們可能早已習慣這種方式，在專案庫裡面存在一些以md格式結尾的文字檔案，使用markdown語法來編寫一些說明文件。

毫無疑問，這類格式很適合線上協作，所以我們也會在平臺上整合這麼一種編寫文件的方式，無論是針對HTML模板還是JavaScript模組，或者是其他什麼型別，甚至還可以用來當部落格，就像月影同學的gitpress平臺，能直接從GitHub上拉取文字或者HTML檔案形成部落格。

文件除了以整合的形式瀏覽之外，應當也可以以單獨連結的方式發出去，這時候使用者就可以像看一個新聞網頁一樣去瀏覽。如果再進一步做下去，還可以做電子書的生成，提供打包的離線文件。

4.2. 示例

在編寫程式碼文件的過程中，可能免不了要插入示例，示例有兩種形態，一種是純文字，類似gist這樣，一種是可線上執行，類似jsfiddle和jsbin這樣。

這兩種都有各自的優點，所以可以都做，示例的存放可以與文件類似，也應當能通過一個連結獨立執行。

4.3. 幻燈片

有時候我們看到一些線上的幻燈片，覺得效果很帥，比如reveal.js，我們的開發人員有時候作程式碼分析或者走查的時候也不免要寫一些演示，如果能把這些東西也隨專案管理起來，能線上檢視，會是很不錯的一件事。所以我們也可以考慮給它們加個儲存介面，甚至做個簡易的線上編寫器。

5. 專案與目錄管理

說到現在，我們似乎還遺漏了一點什麼。那就是以上提到的這些東西，以什麼為組織單位來儲存？

考慮到我們的這個平臺是要管理一整個大產品的全部前端內容的，它裡面應該分了很多專案，對應到子產品上，這麼一來，很自然地，專案就成了第一級組織單位。專案之下，沒有懸念地，只有目錄了。

對於一個專案而言，它有哪些要做的事情呢？首先要能配置其實體儲存位置。前面提到的這麼多程式碼、文件之類，最終都是要實體儲存的，怎麼存？我們當然 可以自己搞一套，在檔案系統上做起來，但是還要考慮它們的版本管理，非常麻煩，所以不如直接對接某個版本庫，呼叫它的介面去存取檔案，這裡配置的就是版本 庫的路徑。

其次，要考慮從已有專案複製，類似GitHub裡面的fork功能，不過內部處理機制可以略有不同，fork的專案預設未必要有實體檔案，只有當產 生了修改或者新增操作的時候才建立，剩下的還引用原來的就可以了。我們這裡的專案複製功能是為專案化版本而考慮的，經常出現一個產品版本支援多個客戶專案 的情況，所以可能會用得著這個特性。

然後，也要考慮專案的依賴關係。依賴一個專案，意思是需要用到它裡面的元件，所以實質是元件的依賴。提供專案依賴這個檢視，只是為了未來變更的一些考慮。

6. 評論管理

之前提到，我們整個平臺的目的是為了提高大型前端團隊的協作能力，協作是離不開交流的。上述的任何功能，都應當帶有交流溝通的能力。

比如說，如果開發人員A使用了其他人寫的一個程式碼元件a，對其中一些細節有疑問，他應當可以對它進行評論。在他評論的時候，任何參與維護過這個元件的人員都能收到一個提醒，這時候他可以選擇過來看看，回覆這個疑問。同理，在文件、示例下也可以如此操作。

在網際網路上有這類產品，用於在任意URL下掛接評論交流系統，比較有名的就是Disqus，我們可以看到很多網站下面掛著它，用於做交流評論，這樣使用者可以用一個賬號在多個網站之間交流。國內也有同類的，比如多說，能夠用微博、QQ等賬號登入進行交流。

從我們這個平臺本身看，如果是部署在企業內部作流程提升，引入外部評論系統的可能性就比較小了。因為在企業內部用，一定是希望這個員工的賬號資訊跟工號掛鉤，也能夠跟版本伺服器賬號等模組作整合，許可權也便於控制。

從另外一個角度講，某個人員登入這個系統的時候，他可能收到很多訊息，來自不同的程式碼或文件位置，挨個點過去回覆也有些麻煩，我們應當給他提供一個全域性檢視，讓他能在一個統一的介面把這些問題都答覆掉，如果他需要的話，也是可以點進去到實際的位置。

7. 使用者和許可權控制

從以上部分我們已經看到，這個系統是一個比較複雜的開發過程管控平臺。這樣的話，每個使用的人就應當可以登入，然後分配不同的許可權等級。

未登入使用者應當有一些東西的檢視許可權，但是不能發表評論。已登入的使用者根據許可權級別，可以控制能否建立、修改專案，建立、修改目錄，程式碼，單元測試，文件等。

8. 國際化字串管理

一個跨語言區域的Web應用不可避免要跟國際化打交道，這個事情通常是在服務端做，比如通過在介面程式碼中嵌入類似<% =getRes(key, lan) %>這樣的程式碼，去獲取相應的字串，替換到介面裡來。

這個事情是要佔用應用伺服器資源的，而且國際化本身其實是一個在執行之前就已經確定的事，完全可以把這個過程放在釋出階段就做掉。比如說，我們給每種語言預先就把程式碼生成多份，只是部署在一起，根據需要的情況來動態載入特定的那一份。

有不少客戶端的國際化方案，是把資原始檔拆細，以頁面為單位儲存，但這其實是不太合理的。第一個原因就是在Web2.0時代，“頁面”這個概念本身就已經弱化了，到了單頁應用裡，整個應用都只是一個頁面，這個時候，資原始檔以什麼粒度來組織呢？

我們提到過，採用MV*框架去做Web應用的架構，有一個目標是做元件化。元件化的意圖就是某個元件可以儘可能隨心所欲地放在需要的地方用。如果把資原始檔的粒度弄小到對應HTML片段和JavaScript模組這一級，靈活性倒是有了，帶來的問題就是管理成本增大。

做一個行業應用，最重要的就是業務一致性，這包括邏輯的一致性，也包括了術語的一致性。某一個詞，可能在多個資原始檔中都出現，這就增加了不一致的可能性。

所以，應當有一個統一的術語管理平臺，一切介面上出現的文字或者提示，都必須來自這個平臺。

9. 靜態資源的管理

在釋出系統的時候，除了需要釋出程式碼，還需要釋出圖片等靜態資源，這些東西也應當被管理起來。

靜態資源在兩種情況下可用：隨產品釋出，在本平臺被引用。比如說有一個圖片，在這個平臺上作了管理，它可以被配置到某個專案上，在釋出的時候匯出。這個圖片還可以被用連結的方式檢視或者下載，如果本平臺內部的一個文件或者示例要引用它，也是可以的。

10. 樣式與主題管理

在Web系統裡，樣式和主題是很重要的一環。樣式的管理和釋出一直是一個比較複雜的話題，早幾年一般都是分塊寫，然後組合合併，最近這些年有LESS，SASS和Stylus這類技術，解決了編寫和釋出的分離問題。

我們看看釋出的最大問題是什麼？是不同部分的合併。為了追求靈活性，不得不把東西拆得很細，之前HTML片段和JavaScript模組的處理方式都是這樣。這麼做，我們就需要另外一件事：這些細小的東西，儘可能要覆蓋全面。

對應到CSS裡面，我們要做的是把每種在系統中可能出現的元素、類別都作為單獨的規則維護起來，生成一個全域性的規則列表。不同專案間，實現可以不 同，但規則的名字是固定的，定製只允許修改實現，不允許修改規則。如果要新增之前沒有的規則，也必須在全域性規則列表裡先新增，再作實現。

樣式規則被管理之後，可以在介面元件上對它作關聯，也可以不做。做的好處是釋出的時候能只把用到的那些樣式規則生成釋出出去，如果能接受每次釋出全量CSS，那也無所謂。

除了規則，也需要考慮一些變數的管理，在CSS中合理使用變數，會大為減輕定製化所導致的工作量。

11. 一鍵釋出

我們引入了這麼一堆東西，其實是增加了釋出的複雜度。為什麼呢？

之前不管HTML、JavaScript還是CSS，都是手寫出來，最多經過一個minify的工作，就釋出了，整個過程很簡單，兩句指令碼搞定。

現在可複雜了，先要分析依賴關係，然後提取檔案，然後國際化字串替換，然後合併，然後程式碼壓縮，整個過程很折騰，不給配置管理員一個解釋的話，他一定過來砍人。

我們有個原則：解決問題的過程中，如果引入了新的問題，要求負責解決原問題的人也一起解決掉。現在為了一些意圖，增加了版本釋出的複雜度，那也要有個辦法再把這事擺平，至少不能比原來複雜。

所以我們就要把這些過程都整合到管控平臺裡，做一個一鍵釋出的過程，把所有的這些操作都整合起來，配置管理員釋出版本的時候只要點一下就可以把所有這些事情做掉。甚至說，這些流程還可以配置，能夠加減環節。

這時候我們做到了跟之前發版本一樣方便，能不能多做點什麼呢？

可以把JavaScript單元測試整合到版本釋出階段。因為我們已經把JavaScript按照職責做了分層，並且把UI部分做了隔離，就可以在瀏覽器之外把這個單元測試做掉，平時提交程式碼的時候也可以做，最終在版本釋出階段再全量做一下，也是很有意義的。

程式碼依賴關係管理的另一個目的是什麼呢？是最小化釋出，既然我們都管理了檔案之間的關係，那麼，從根出發，顯然是能夠得出哪些程式碼檔案在本專案中使用的，就可以每次從我們的全量程式碼庫中取得確切需要的一部分來發布。這也是我們整個管控平臺帶來的優勢。

12. 小結

我們這一篇比較複雜，提出了一整套解決大規模前端協作的管控機制。這套理論的本質是在開發和版本釋出之間加了一個環節，把Web體系中除了服務之外的一切靜態資源都納入其中，強化了現有主流的一些基於命令列的前端工程化組織模式。

相比於傳統行業，比如汽車製造，我們這個環節相當於生產流水線的設計，其中一些元件的儲存就類似倉儲機制，釋出就類似出廠過程。

這個平臺本身還有不少其他的可做的東西，比如甚至可以在上面做介面的視覺化定製等，這些是長遠的終極目標，在後面的文章裡會談談一些考慮。

後續文章中，我們會展望有了這個平臺之後，整個前端的協作流程是怎樣的。

---