自我介紹
大家好，我是洛塵，來自於政採雲前端團隊，2014 年畢業於浙江工業大學，做過 .NET ，寫過 Java ，玩過資料庫，2015 年才加入前端這個大家庭，這一路上，見證了前端從 jQuery -> Angular -> React/Vue 的轉變，經歷過降薪、裁員，還經歷過一個子公司從創立到解散。2019 年 1 月，正式加入政採雲有限公司，負責“魯班”搭建系統相關的前端基建工作，是一枚普通的前端打字工程師。
搭建系統話題引入
完成業務需求是我們的本職工作，需求評審 -> 開發 -> 提測 -> 上線，上線完了以後呢，又是下一輪的需求評審 -> 開發 -> 提測 -> 上線，3 年，5 年，10 年過去了，你學會了什麼？需求評審，還有開發，這只不過是在出蠻力。那麼如何優雅的去解決業務問題，這就涉及到我們今天要討論的話題 —— 搭建系統。
業務場景
技術是用來服務於業務的，沒有業務場景的技術建設，都是耍流氓。那讓我們一起來看看搭建系統的業務場景有哪些：
上述場景都是真實存在的，在我們公司，入口網站的需求量是很大的，而且很多入口網站的相似度極高，這就意味著，只要視覺規範保持一致的情況下，前端的元件、元件、模組甚至是模板是可以進行大量複用的；還有，運營所提的需求體量小，功能小點多，需求的優先順序自然提不上來，運營自己又無能為力，最終導致流量和使用者的流失；對於前端來說，重複的業務需求，對於自身成長毫無價值可言，漸漸的也就麻木了，離當時定下的一個億的小目標越來越遠，成為了無情的編碼機器。
業務例項
下面這些都是我們公司的入口網站，頂用、頭部導航、banner 位、商品類目、快捷入口等等都是極度的相似，這也將元件/模組的重複利用成為了可能，也是搭建系統存在的前提之一。
我們再看另一個例子，圖中紅框選中區域，都是運營/產品希望手動配置資料的模組，它幾乎佔據了頁面內容的 70% 之多，也就可以想象運營所提需求不能得到及時解決時，內心到底有多痛苦。
搭建系統長什麼樣
我們的搭建系統一共分為 3 個主要功能模組，1 個資料模組，1 個許可權模組:
- 站點管理：站點這個東西，為了方便理解，你可以認為是一種業務分類，每類業務對應一個站點（分類）
- 頁面管理：這是搭建的核心功能，具體功能可以看下面連續的四段錄屏（圖 2 ~ 圖 5）。
- 元件管理：一個頁面會用到很多元件，不同的頁面也會用到同一個元件的不同版本，這就是元件管理存在的意義。
- 資料看板：如何體現一個系統是否帶來了價值，是否被有效的利用，資料才是最直觀的表達方式。
- 許可權：許可權分為兩部分：一部分是選單和操作許可權的控制，另一部分是系統自身的資料許可權控制，也就是約束使用者的資料可見範圍，資料許可權這塊尤為重要，如果任何人都可以對資料進行編輯，那是非常危險的事。
架構圖
部署
搭建系統要怎麼部署？有小夥伴可能會疑惑：這尼瑪還能怎麼部署，測試、預發、生產環境各來一套唄。你只說對了一半。問大家一個問題：不同環境的頁面是不是同一個？是同一個吧！不對，是長得一樣的三個頁面！！那麼這個時候，我們就會有一個心理預期：只做一次頁面搭建，能在三個環境生效。那這要怎麼做？讓搭建系統本身部署在一個環境上，而且最好是生產環境單獨伺服器（圖中的運維 VPC ），然後讓這臺伺服器和其他三個業務環境（左側的 test/staging/pro 環境）打通，也就是說，在搭建系統的環境上產出頁面，然後通過“釋出”操作把頁面同步到測試，預發，生產這三個業務環境，這樣就可以達到我們的預期。
上面說了這麼多，大家也應該對於搭建有一定的印象了，接下來我們進入這次分享的正題。
如何配資料
JSON Schema
說到資料，大家肯定會想到什麼？String，Number，Boolean，但今天我要說的是 JSON，準確的來說是 JSON Schema，那麼請大家來思考一下這個問題，JSON Schema 到底是 JSON 的擴充套件？還是 JSON 的約束？
答案是：約束。其實 JSON Schema 就是一個標準化/規範化的 JSON 資料。那 JSON Schema 是怎麼定義出來的，這也就是下面我要講解的內容。我們先從簡單示例入手。
簡單示例
這是一個很常見的 form 表單，其中包括輸入框，下拉框，開關。其中包含的元素包括：label（主題色、賬號）、placeholder、type（input、switch）、data（下拉框的選項）、key（欄位名）、value（欄位值）。剛才說的這些都和我們的 JSON Schema 定義息息相關。
把剛才屬性的定義整理一下，拿其中一個“主題色”的下拉框舉例：
可以看到我們用一段 JSON 資料描述了一個具體的頁面元素，這就是 JSON Schema 在搭建中要達到的效果。
當然了除了頁面元素的定義以外，頁面還需要有初始資料，初始資料的定義就簡單很多，大概是這樣：
擴充套件型別
上面說到的 input、switch 都是根據場景定義的型別，我們也可以將 input 定義為 String ，switch 定義為 Boolean ，這些都是通過場景人為定義的一些分類標準，沒有固定的表達形式，只要你確保定義合理，並且容易被人理解即可。除此之外，平常業務當中比較常見的還有這些：
總結
在平時編碼過程中，我們用來定義資料最多，也最常見的複雜型別是物件（Object）和陣列（Array），而構成物件和陣列的最常見的基本型別是 String 和 Number ，那也可以是擴充套件型別。
說了這麼多 JSON Schema 相關的內容，那它和我們的業務到底有什麼關係，讓我們一起來看看
業務場景
還是回到我們剛才那個入口網站，剛才說到紅框部門是運營/產品希望手動配置資料部分，那麼問題來了，怎麼讓他們能夠配置資料，而資料配置又如何和我們的 JSON Schema 產生關係呢？
將業務轉化為資料
第一步，我們需要將業務場景轉化為客觀存在的資料，拿其中一小塊來舉例：
從圖左可以看到這是一個各省份的快捷入口，這一小塊頁面它對應的資料就是圖右所示：
很常見，也很簡單對不對，那接下來我們進入第二步：
將資料轉化為定義
上面我們提到過很多的型別定義，那我們先在將這些定義引入到我們的業務場景中來。
我可以看到這份資料，它的資料型別是 Array，其中包括了“地名”、“圖示”、“連結”、“描述”欄位。我們拿地名、圖示這二個欄位來進行舉例說明：
- 地名：label = 地名，key = addressName，type = String；
- 圖示：label = 圖示，key = icon，type = Select，data = { icon1: icon1, icon2: icon2 } 。
然後，我們將他們進行整合，可以得到圖右這樣的結果。
將定義規範成結構
我們已經有能力可以將一個頁面模組轉化為一份簡單的 JSON Schema 片段，同樣的，我們也可以將其他模組做同樣的轉化，不管是 Object ，還是 Array ，甚至是 Two-dimensional Array（二維陣列），然後，我們將每一份 JSON Schema 片段進行整合，當然了，光有定義還不夠，頁面還需要有資料，這樣我們就可以得出完整的 JSON Schema 結構：
視覺化
最後你可以根據你的視覺化需要，寫一個符合你自己頁面設計的 format 函式，對這一份 JSON Schema 資料進行轉化，最終渲染成為一個表單、表格或者其他樣子。下圖是我將 JSON Schema 轉化後渲染得到的運營資料配置頁，給大家做個參考：
總結
體系和擴充套件
搭建系統是前端工程化體系之一，我們可以根據不同的業務場景，建設不同規模的搭建系統：元件級、元件級、模板級、甚至是應用級的；從搭建場景來看，可以是單個頁面、也可以是整條業務鏈路、營銷活動、甚至是整個中臺；從終端型別來看：可以是 PC、H5、Native、小程式等等；為保證搭建系統的穩定性，產出高質量、高效能的頁面，我們還需要一些其他能力的支援：自身的系統的容災策略，比方說，頁面丟了需要怎麼樣的兜底方案，資料丟了怎麼找回，釋出失敗了怎麼回滾；從規範層面來說，我們需要有一套完整的腳手架，約束和規範元件的開發生命週期；從產出層面來說，我們需要保證搭建產出的頁面效能相對可觀，因此就涉及到頁面效能檢測，這又是一套完整的系統，我們的效能檢測系統叫做“百策”，它和搭建系統進行橫向打通，提供搭建頁面效能檢測能力。忽然說到了頁面，自然就少不了資料：BFF 層、資料共享、Ajax 請求聚合等等。
上面說到的這一切的一切，不管是一個小點還是一個大的方向，只要你抓住了業務的痛點，為其設計一套通用的可行性方案，並落地成為一套系統反哺於業務，那都是一種質突破，也是走向產品化、智慧化的一大步。謹記：你的一小步，業務一大步。
快到碗裡來，我們招人啦！！！
團隊最新的招聘資訊，請掃下方二維碼關注“政採雲前端團隊”微信公眾號獲取，期待你的加入。
簡歷自薦推薦，請傳送至 ZooTeam@cai-inc.com
