基於web/h5應用的外掛/擴充套件方案設計

本文是一個系列文章，談談如何降低應用的複雜度，增加可維護性。
文章裡面提供的是一種思路，並根據此思路進行實現，將遇到的問題進行解決。

背景

隨著使用者體量的增加，功能會越來越多，系統會越來越龐大，基於後端的微服務越來越大火，前端層面更多的關注vue，react之類的框架上，
他們解決的是檢視和資料的分離，但業務層面的框架或者思想的分享則不多，畢竟偏離了技術的路線。

思想

類似與微信與小程式，瀏覽器與擴充套件，或者作業系統與應用程式之間的關係，都是面向開發者的服務（如果客戶沒有開發能力，也可以根據情況由我方開發者開發）

實現

根據我們自身業務系統的特性，找到我們系統本身獨特的，核心的業務性的東西，以此為主線，將各個業務模組或者通用服務抽離。
上面講的有些抽象，讓我們來舉幾個具體的例子。

假如我們的系統是iconfont.cn

需求： 我的職業是寫PPT，每天會高頻詞找圖示放入PPT，它只有複製svg的功能，沒有直接複製圖片的功能，我不想每次都下載PNG，
我期望有個複製圖片的功能，類似於下圖

程式碼方案設計，以下為虛擬碼，實際生產環境不會這樣寫，但這不重要，在此，只是提供一種思路給大家。

1. 基礎功能裡將按鈕設計成一個陣列
2. 我們初始化會獲取當前使用者的擴充套件並執行（利用new Function()，後續文章我會詳細說明如何設計）
3. 動態擴充套件獲取到btnGroup，並追加進一個按鈕。（這裡的難點是如何獲取btnGroup，我們不可能將btnGroup設定為全域性變數，這樣不符合我們的初衷，這裡需要我們在設計之初就想好，框架不同，方案不同，後續的文章，我會針對ES5,ES6，Vue等出針對性的寫法方案）

我們打包後的部分程式碼片段如下

//我們系統的基礎功能
const btnGroup=[{
    name:"SAG 下載",
    fn(){}
}];

通過介面獲取到的程式碼片段（此程式碼片段由使用者或管理員上傳至我方資料庫，並經過介面返回至客戶端）

//動態擴充套件，使用者自己上傳或者我們分配的擴充套件
btnGroup.push({
    name:"複製 PNG",
    fn(){/*具體的實現*/}
})

結束，完成一個簡單的功能。

優點

1. 功能獨立出去了，系統的程式碼量會變小很對，我們對系統減負，開發員將關注點放在基礎功能上，而不是這種定製功能。
2. 系統架構清晰，維護起來就容易。
3. 需求的響應速度加快，一個功能從提出到使用者實際得到，如果使用者自己有開發能力，時間等於他自己的開發時間，如果使用者沒有開發能力，時間等於傳達耗時+我方開發員的開發時間。
4. 翻車也不怕，如果功能有問題，第一，它隻影響使用它的使用者，第二，使用者或者管理員後臺直接設定為無效，即可完美脫離擴充套件，不影響其他功能，待改進後啟用即可。
5. 不但可以加功能，還可以打補丁，如漏洞，bug等，完美避開版本控制，領導的最愛。
6. 其他的一些好處-_-…

缺點

1. 基礎程式碼需要留出一些鉤子，以便擴充套件在合適的時機去執行特定的功能。
2. 因擴充套件是直接執行在瀏覽器上，es6架構下，程式碼壓縮後，擴充套件執行需要開發員對webpack和babel的一些打包策略及原理比較熟悉。
3. 擴充套件變多，會不會相互影響，以及更改基礎功能後，受影響的擴充套件如何解決，有待一套完美的方案。
4. 千人千面系統管理起來不知道費勁不，許可權控制可能有點麻煩。

總結

好處肯定大於壞處，誰用誰知道，我經過實測，效果極佳。

結束語：歡迎在評論區交流，如果覺得不錯，可以點贊和收藏，持續更新。

下一篇

等待更新