如何設計實現 PC 站點搭建系統

掃碼關注，獲取更多原創好文～

介紹

你們好，我是洛塵，來自於政採雲前端團隊，2014 年畢業於浙江工業大學，作過 .net ，寫過 Java，玩過數據庫，2015 年才加入前端這個你們庭，這一路上，見證了前端從 Jquey —> Angular -> React/Vue 的轉變，經歷過一個降薪、裁人，還經歷過一個子公司從創立到解散。2019 年 1 月，正式加入政採雲有限公司，負責「魯班」搭建系統相關的前端基建工做，是一枚普通的前端打字工程師。

什麼是搭建系統

搭建系統話題引入

完成業務需求是咱們的本職工做，需求評審->開發->提測->上線，上線完了之後呢，又是下一輪的需求評審->開發->提測->上線，3 年，5 年，10 年過去了，你學會了什麼？需求評審，還有開發，這是出蠻力。那麼如何優雅的去解決業務問題，這就涉及到咱們今天討論的話題 —— 搭建系統。

業務場景

技術是用來服務於業務的，沒有業務場景的技術建設，都是耍流氓。那讓咱們一塊兒來看看搭建系統的業務場景有哪些：

上述場景都是真實存在的，在咱們公司，門戶網站的需求量是很大的，並且不少門戶網站的類似度極高，這就意味着，只要視覺規範保持一致的狀況下，前端的元件、組件、模塊甚至是模板是能夠進行大量複用的；還有，運營所提的需求體量小，功能小點多，需求的優先級天然提不上來，運營本身又無能爲力，最終致使流量和用戶的流失；對於前端來講，重複的業務需求，對於自身成長毫無價值可言，漸漸的也就麻木了，離當時定下的一個億的小目標愈來愈遠，成爲了無情的編碼機器。

業務實例

下面這些都是咱們公司的門戶網站，頂通、頭部導航、Banner 位、商品類目、快捷入口等等都是極度的類似，這也將組件/模塊的重複利用成爲了可能，也是搭建系統存在的前提之一。

咱們再看另外一個例子，圖中紅框選中區域，都是運營/產品但願手動配置數據的模塊，它幾乎佔據了頁面內容的 70% 之多，也就能夠想象運營所提需求不能獲得及時解決時，心裏到底有多痛苦。

搭建系統長什麼樣

咱們的搭建系統一共分爲 3 個主要功能模塊，1 個數據模塊，1 個權限模塊。

• 站點管理：站點這個東西，爲了方便理解，你能夠認爲是一種業務分類，每類業務對應一個站點（分類）
• 頁面管理：這是搭建的核心功能，具體功能能夠看下面連續的四段錄屏
• 組件管理：一個頁面會用到不少組件，不一樣的頁面也會用到同一個組件的不一樣版本，這就是組件管理存在的意義
• 數據看板：如何體現一個系統是否帶來了價值，是否被有效的利用，數據纔是最直觀的表達方式。
• 權限：權限分爲兩部分：一部分是菜單和操做權限的控制，另外一部分是系統自身的數據權限控制，也就是約束用戶的數據可見範圍，數據權限這塊尤其重要，若是任何人均可以對數據進行編輯，那是很是危險的事

架構圖

部署

搭建系統要怎麼部署？有小夥伴可能會疑惑：這尼瑪還能怎麼部署，測試、預發、生產環境各來一套唄。你只說對了一半。問你們一個問題：不一樣環境的頁面是否是同一個？是同一個吧！不對，是長得同樣的三個頁面！！那麼這個時候，咱們就會有一個內心預期：只作一次頁面搭建，能在三個環境生效。那這要怎麼作？讓搭建系統自己部署在一個環境上，並且最好是生產環境單獨服務器，而後讓這臺服務器和其餘三個業務環境打通，也就是說，在生產環境產出頁面，而後經過「發佈」操做把頁面同步到測試，預發，生產這三個業務環境，這樣就能夠達到咱們的預期。

上面說了這麼多，你們也應該對於搭建有必定的印象了，接下來咱們進入此次分享的正題。

如何配數據

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 相關的內容，那它和咱們的業務到底有什麼關係，讓咱們一塊兒來看看

業務場景

這是一個咱們公司的門戶網站，圖上紅框標記部分都是運營或者產品但願可以動態配置數據的地方，這幾乎包括了頁面 70% 的內容，也足以說明數據動態配置在業務中的重要性，那如何將數據配置和咱們的 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、H五、Native、小程序等等；爲保證搭建系統的穩定性，產出高質量、高性能的頁面，咱們還須要一些其餘能力的支持：自身的系統的容災策略，比方說，頁面丟了須要怎麼樣的兜底方案，數據丟了怎麼找回，發佈失敗了怎麼辦回滾；從規範層面來講，咱們須要有一套完整的腳手架，約束和規範組件的開發生命週期；從產出層面來講，咱們須要保證搭建產出的頁面性能相對可觀，所以就涉及到頁面性能檢測，這又是一套完整的系統，咱們的性能檢測系統叫作「百策」，它和搭建系統進行橫向打通，提供搭建頁面性能檢測能力。突然說到了頁面，天然就少不了數據：BFF 層、數據共享、Ajax 請求聚合等等。

上面說到的這一切的一切，不論是一個小點仍是一個大的方向，只要你抓住了業務的痛點，爲其設計一套通用的可行性方案，並落地成爲一套系統反哺於業務，那都是一種質突破，也是走向產品化、智能化的一大步。謹記：你的一小步，業務一大步。

快到碗裏來，咱們招人了！！！

團隊最新的招聘信息，請掃下方二維碼關注「政採雲前端團隊」微信公衆號獲取，期待你的加入。

簡歷自薦推薦，請發送至 ZooTeam@cai-inc.com