移動前端架構升級

做者 俊餘， 前端界一名小學生。

背景

最近移動前端架構升級，總結一下咱們作了哪些改變。 框架的事情越說越抽象，很難像show me the code 那樣直觀，除非你也在作相似的事情，不然很難以爲有所收穫。 每一個公司的組織架構都不盡相同況且是給挑剔的程序員用的框架呢。因此說框架必然是要不斷更新，不斷優化調整以後才能適應這家公司。

其實新老更迭自己就會帶來不少挑戰。 看似穩定的一切其實都是能夠被替代的，目前的存在只是現階段的妥協。

• 規範化

若是公司沒有本身的docker化平臺,那上線要作的事情就是同步。 把須要上線的代碼同步到服務器上。 咱們是基於jenkins作自動化部署。主要有兩方面的改造，

1. 明確開發&發版流程 咱們主要使用ESLint和StyleLint作強制代碼check，git commit hook強制描述規則，文檔描述使用markdown git分支規範（gitflow） Commit描述 核心模塊CodeReview（人工）

2. 配合運維搭建自動化構建 輸出統一目錄 使用縮寫作統一nginx配置

if ($uri ~ /hybird/(.*)/.*) {
      set $hybird /hybird/$1;
    }
    location ~ /hybird/(.*)/.* {
  }
複製代碼

• 前端框架

  除了要解決老系統的問題，咱們還須要作到安全、解耦、可監控、可度量、能夠快速發版、組件化、高性能、模塊化、可擴展、熱修復、一致性、隔離發版、BU化支持……

  團隊大多推崇vue，整個技術棧切換到了vue、webpack、Postcss…的技術體系。

  使用選型後的技術體系，如何基於這樣的技術選型設計一套能支撐3年（前端的平均壽命 週期可能比這個還要低）的框架呢？首先這個框架必須進行合理的粒度拆解，必須能輕 鬆的支持縱向功能級分層，橫向按照BU分業務線。

  爲了提升複用性，按照UI組件、BC組件、頁面、模塊、前端服務按照不一樣粒度層 次進行組合。

• 粒度化

一個大的系統，不管從功能層級角度、仍是從業務角度、都應該能靈活的進行縱橫拆 解。一個系統應該能夠分爲獨立的系統、系統中的標準流程、流程中的模塊、模塊中的 組件、組件中的元素…，這些不一樣大小粒度表明了不一樣層級的複用性。

1. 頁面上的每個獨立的可視/可交互區域均可以視爲一個組件
2. 按鈕、label、panel等無業務邏輯的可視區域抽象爲UI組件
3. 包含業務邏輯的信息區域和交互區域，根據業務場景，抽象爲可大可小的業務組 件，業務組件能夠由多個UI組件組合而成

組件與組件之間能夠自由組合；通常狀況業務組件會包含UI組件，可是不建議太復 雜的業務組件嵌套業務組件。依賴太深會下降獨立性。

頁面做爲組件的容器，頁面的數據適配器負責提供組件化數據，並負責組合組件爲 功能完整的界面。 模塊也是自包含的，能夠獨立打包，和其餘模塊徹底獨立，不容許嵌套和功能依 賴。 模塊能夠和其餘模塊按照協議組合爲一個標準業務流程。