背景

美團COS：全稱美團網核心業務系統部，以持續整合O2O線下資源，共建高效率、低成本的供應鏈系統，高效推動O2O生態環境建設為業務目標，負責美團網核心業務系統的建設和管理。

COS系統，伴隨著美團3年多的發展，前端也積極參與到系統的建設中。 在這幾年里，通過優化系統前端環境，改進代碼組織結構，豐富公共資源和自動化工具，不斷提高了業務響應效率，也在不斷努力去逐步縮短系統的前端開發周期，以下簡單介紹在這個過程中的一些變化。

第一個COS系統——合同系統

• 沒有獨立的靜態資源服務，無壓縮，采用YUI3的Loader，手動維護依賴關系。
• 忙著寫控件，第一個控件Autocomplete，后來有了Table、Tree、Form、IO等。
• 線上代碼經常不穩定，靜態資源地址采用加時間戳的方式來更新。

公共模板部署

由于前端需要支持的業務系統眾多，對每個系統而言，都有一些相同的處理邏輯，如前端環境初始化(包括系統的參數配置、YUI部署、UI部署、控件初始化、GA統計源、頁面加載時間統計、瀏覽器升級提醒、問題反饋等)針對每個系統都是一樣的，不希望每個系統都要去處理這些邏輯，于是集成了mt-fe.jar到每個后臺系統，節約了新開系統的成本。

模塊化道路

• 模塊目錄結構扁平化

  所有的模塊在目錄結構上都是平行的，無區別的。 同時增加了主模塊和子模塊的概念，并在此基礎上定義了統一的加載規則。

• 模塊名稱和路徑關系約定

  知道一個模塊名就可以知道這個模塊的代碼所在的位置，是否是主模塊以及屬于某個系統，如：

  crm-module 對應的三個屬性應該是： { path: "/static/module/module.js"， isMainModule: true， app: 'crm' } deal-module/sub 對應的即： { path: "/static/module/sub.js"， isMainModule: false， app: 'deal' }

• 模塊加載機制

  使用YUI3的自動加載，需要給Loader配置一個依賴關系表。最初新增一個模塊時，需要在模塊定義和Loader配置中都聲明該模塊的依賴。這樣在兩個地方維護依賴關系，容易產生不一致，從而帶來維護問題。 為解決上述問題，開發了腳本自動計算所有模塊的依賴關系，生成依賴關系表傳遞給Loader使用，面臨的問題是修改模塊依賴關系需要運行腳本才能生效，而在開發時更想要所見即所得的效果。于是又針對開發環境，在Loader加載時根據約定的模塊名，自動計算出模塊的加載路徑和類型，從而實現不提前配置依賴關系表也可自動加載。

  一個簡單的加載配置 var metaGroups = {"fecore": {//發布時自動生成的metaGroups，用于線上環境modules: {"moduleA": {path: "moduleA/moduleA.js",requires: ["moduleB", "moduleC"]},...},//根據pattern和文件名約定進行自動加載，用于開發環境patterns: {"prefix": function(cfg) {cfg.path = "moduleA/moduleA.js";cfg.type = "js";return true;},...}} };YUI({...groups: metaGroups,... }).use('moduleA', function(Y) {});

• 模塊依賴關系梳理

  模塊中存在間接依賴，如A依賴B、C，B依賴C，這時在A的依賴關系中只需要聲明B就可以工作，如果某天B不需要依賴C了，這時在B中去掉C的成本就變大了。為了解決這類問題，規范了依賴關系聲明，并開發工具對源文件進行分析，自動化校驗和修改，也計劃將該校驗加入到各代碼倉庫的git hooks中。通過該工具的梳理，讓開發者能非常明確了解所有模塊之間的關系，對宏觀掌握當前模塊的使用狀態也是非常有幫助的。

• 模塊的豐富和穩定

  前端支持的項目眾多，如何在應用層花最小的代價寫代碼，是我們一直在思考的問題。 通過不斷豐富可復用的組件庫、定義統一的UI方案以及提取和整合所有系統的公共模板等來避免重復工作。 目前，除了所有前端公用的代碼倉庫fe.core外，也為COS系統新增專門的前端代碼倉庫cos.core，存放和業務相關的模塊。同時為了保障模塊的穩定性和易用性，開發了模塊文檔，并進行了測試用例的覆蓋。

  • 模塊內目錄結構完善 模塊中從只包含css、css、tpl文件到包含tests、guide等文件，目前一個完整的模塊的目錄結構如：

  • 組件方面 從簡單的構造器、prototype寫對象實現繼承到基于YUI3的Widget or Base框架，并在此基礎上進行了擴展；不斷新增組件和完善組件功能，使其能滿足大多數業務需求；對代碼進行不斷重構，使得組件可以更加穩定。 我們提倡只要是能被重用的代碼，都應該放到相應的公共代碼倉庫中。

  • UI方面 不得不說Bootstrap帶給web行業的影響是巨大的，特別是針對后臺系統。 簡潔大氣的設計，對于大多數網頁元素來講已經能較好的滿足需求，不過針對COS系統，還是有不少需要單獨處理的需求，比如各個系統的Layout，一些簡單的UI模塊和少量交互的組件等，所以在全兼容Bootstrap的基礎上做了COS-UI，并對所有的COS系統頁面進行了遷移，統一了風格。 也為界面外觀定義提供統一標準，降低開發與維護成本。

  • 測試方面 從使用YUI3提供的YUI Test模塊編寫單元測試用例，到使用mocha+chai+sinon結合，采用phantomjs進行無界面測試，無縫集成到開發環境，讓寫測試變的更簡單，從而提高了寫測試用例的積極性。

  • 文檔方面 從最初專門開發一個應用去為模塊編寫使用文檔，到文檔靜態化。在完善的模塊目錄結構基礎上，通過梳理文檔規范，根據約定自動輸出靜態化的文檔；從靜態的demo展示到可以在線修改；從手寫的使用說明，到根據YUIDoc生成的注釋自動提取文檔內容等。使得只需要寫最少的內容，即可生成豐富的文檔和demo。 如下是一個簡單的構建demo的規范：

    <div class="demo"><h1>簡單demo</h1><div class="html-content">...</div><script>...</script> </div>

    只需要按照上述格式寫代碼，工具就會自動生成如下靜態頁面，可以在頁面中進行參數修改，便可即時查看到效果。

COS系統前端分層

用戶端和核心業務端的模塊都是基于YUI3進行開發，同時在模塊化機制的前提下，共用底層庫fe.core。 為了更好地針對所有系統業務場景做抽象，開發了專門提供給業務系統使用的模塊cos.core。

配置中心會處理所有系統的前端配置，如當前系統環境(開發環境、測試環境、線上環境)，YUI的版本號，是否使用Combo服務，是否是調試模式等。

系統前端開發環境

為了方便系統開發，針對一些平時應用比較普遍的場景開發了自動化的工具，如發布、自動化文檔、依賴關系檢測、自動化單元測試、全部系統范圍內搜索、自動build template等。為了使工具更容易維護，權責更加明晰，在代碼組織和管理方面，先后對代碼倉庫進行了拆分，發布package到內部源，并使用npm來進行包管理，解決了package之間的依賴管理問題。

同時針對各系統提供了一系列的服務，如靜態資源、Combo、日志、頁面加載性能報表等。 未來還計劃開放UI定制，一鍵開站，動態修改系統配置，在線為某個模塊寫文檔、demo、test，在線管理靜態資源等功能。

開發平臺旨在希望作為一個窗口，索引與前端有關的所有服務和資源，為開發者提供開發輔助。

系統發布

• 系統運行初期，使用Shell腳本處理發布過程(包括資源的壓縮、加版本號、計算依賴關系等)。后來由于涉及到的代碼倉庫增多，發布過程也增加了更多的邏輯，如打包公共模塊、修改模板中引用的CSS、圖片資源地址等，使得腳本一度維護比較困難，后對腳本進行了拆分。 再后來，考慮到Node的靈活以及社區的活躍，將發布腳本遷移到Node平臺，使用Grunt來管理發布任務，同時獨立了配置，代碼庫進行了更細粒度的拆分，使得發布這一過程更加靈活和便于維護。

• 系統發布從后端人工操作到集成到OPS平臺一鍵發布，大大提高了發布效率，減少了bug處理時間。

• 從使用外部npm源到內部npm源，減少了發布本身的耗時。

以上也為前端cos組在系統建設方面做一個簡單總結。非常有幸能在一個重視技術，重視前端的公司里學習成長。回想起這么多的日日夜夜，曾面對每一次技術改造和調整都興奮不已，會偶爾想方案徹夜難眠，走了很多彎路，開發了很多系統，但每次都能從看似相似其實充滿新挑戰的系統中獲得新的收獲。期望每天的點滴進步會讓系統開發變得越來越簡單高效，Happy Coding！

總結

以上是生活随笔為你收集整理的COS系统的前端演变和发展的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。