背景
由于之前的數(shù)據(jù)庫防火墻產(chǎn)品與數(shù)據(jù)庫審計產(chǎn)品使用的是同一套代碼盲镶,隨著兩個產(chǎn)品功能的差異越來越大侥袜,代碼的冗余度和偶合度越來越高,為了便于后期維護以及添加新功能溉贿,所以基于原來的項目代碼枫吧,進行了代碼結(jié)構拆分。
注意:本次拆分只拆分了可以拆分的部分宇色,有的模塊例如:規(guī)則九杂、關于我們,是沒有進行拆分的宣蠕,一是有的模塊很簡單例隆,沒必要拆分;二是有的模塊原先寫得代碼偶合太嚴重植影,無法拆分裳擎,如果要拆分,需要花費大量精力去梳理代碼思币,同時還要后端配合拆分鹿响。
目的
將此次代碼拆分方案記錄下來羡微,便于后來的開發(fā)人員快速熟悉項目結(jié)構。
拆分前
流程設計
項目拆分前惶我,區(qū)分數(shù)審和防火墻功能的流程如上圖所示妈倔。
訪問系統(tǒng)時,先加載入口文件 main.js绸贡,然后加載登錄頁 login.vue盯蝴,加載登錄頁的同時獲取產(chǎn)品模式并保存到 session.storage.platformType 中,接著用戶登錄系統(tǒng)進入具體頁面听怕,該頁面同時包含了數(shù)審和防火墻的功能捧挺,根據(jù) session.storage.platformType 保存的值來判斷,具體顯示哪個功能尿瞭。
目錄結(jié)構設計
項目拆分前的目錄結(jié)構如上圖所示闽烙。
該目錄結(jié)構是初始化一個 Vue 項目時的基本目錄,根據(jù)目錄結(jié)構声搁,基本上看不出該項目包含了兩個不同的產(chǎn)品黑竞,也不知道不同產(chǎn)品模式下會加載哪一部分文件,結(jié)構不清晰疏旨。
存在的問題
通過分析很魂,可以發(fā)現(xiàn)當前的系統(tǒng)流程和目錄結(jié)構是存在很多問題的,大概總結(jié)下:
- 加載登錄頁的時候才獲取產(chǎn)品模式檐涝,如果登錄頁加載完成遏匆,而產(chǎn)品模式還未獲取或者獲取不到,那么登錄頁顯示的產(chǎn)品信息有可能是錯誤的骤铃;
- 每次進入一個具體頁面拉岁,如果同時包含了數(shù)審和防火墻的功能,都要重新判斷一次惰爬,當前的功能是數(shù)審的還是防火墻的喊暖;
- 目錄結(jié)構不清晰,不清楚哪些模塊是公共模塊撕瞧,哪些是數(shù)審獨有的模塊陵叽,哪些是防火墻獨有的模塊;
- 可維護性和可擴展性差丛版。數(shù)審的代碼和防火墻的代碼混在一個文件內(nèi)巩掺,改代碼的時候需要重頭看一遍才知道哪塊代碼屬于數(shù)審,哪塊代碼屬于防火墻页畦。如果想要添加一個功能胖替,還得繼續(xù)加邏輯判斷,代碼越來越臃腫;
- 業(yè)務邏輯混亂独令,與后端通信使用了同一個接口端朵。
拆分后
流程設計
項目拆分后,區(qū)分數(shù)審和防火墻功能的流程如上圖所示燃箭。
訪問系統(tǒng)時冲呢,先加載入口文件 main.js,該文件中寫了路由攔截相關的邏輯招狸,在路由攔截時敬拓,如果沒有產(chǎn)品模式,則要先獲取產(chǎn)品模式裙戏,否則會被攔截乘凸,進不去系統(tǒng)。獲取產(chǎn)品模式后累榜,根據(jù)當前產(chǎn)品模式翰意,會注冊對應的登錄頁、路由配置信柿、接口請求等。當注冊完畢后醒第,每次訪問具體的頁面渔嚷,都應該是獨立的模塊了。
目錄結(jié)構設計
項目拆分后的目錄結(jié)構如上兩個圖所示稠曼。
該目錄結(jié)構經(jīng)過拆分形病,已經(jīng)可以清晰地看到不同產(chǎn)品之間分離出來的文件了,從入口文件開始霞幅,經(jīng)過路由攔截后漠吻,會加載指定的登錄頁,然后把對應產(chǎn)品需要的文件合并到公共文件中司恳。比如:http 請求途乃、路由配置等。最終結(jié)果扔傅,程序只會把需要的文件加載進去耍共。
解決的問題
經(jīng)過重新設計,解決了當前項目存在的一些問題:
- 在加載登錄頁之前猎塞,通過路由攔截试读,必須先獲取產(chǎn)品模式,才能進入系統(tǒng)荠耽,登錄頁是在獲取到產(chǎn)品模式之后才加載的钩骇,不會出現(xiàn)產(chǎn)品信息顯示錯誤的問題;
- 只有在第一次進入系統(tǒng)或刷新頁面的時候,才會重新獲取產(chǎn)品模式倘屹,合并產(chǎn)品模式對應的文件银亲,合并的文件是拆分后的文件,不需要在文件內(nèi)再次判斷該有數(shù)審的功能還是防火墻的功能唐瀑。
- 目錄結(jié)構清晰群凶,防火墻相關的功能模塊文件都放在 views-fw 文件夾內(nèi)。
- 提高了項目的可維護性和可擴展性哄辣,降低了代碼的偶合度请梢。數(shù)審的代碼和防火墻的代碼基本已經(jīng)拆分開,如果想要添加一個防火墻的功能力穗,只需要在防火墻相關的文件夾內(nèi)新增對應功能模塊的文件即可毅弧。
- 業(yè)務邏輯清晰,與后端通信使用的是不同的接口当窗,公共模塊使用的接口按原來的不變够坐,數(shù)審獨有的接口在 url 前面增加了 audit 前綴,防火墻獨有的接口在 url 前面增加了 firewall 前綴崖面。
關鍵代碼
/**
* @Name: main.js
* @Author: cqfeng
* @Description: 項目入口 js 文件
* @MainFunction: 引入和注冊一些全局資源
**/
//...省略的代碼...
// 路由攔截元咙,使用全局導航守衛(wèi)beforeEach
router.beforeEach(async (to, from, next) => {
// 如果沒有產(chǎn)品模式,先獲取產(chǎn)品模式
if (!store.state.productMode.productMode) {
await store.dispatch('productMode/SET_PRODUCT_MODE');
}
//...省略的代碼...
/**
* @Name: product-mode.js
* @Author: cqfeng
* @Description: 產(chǎn)品模式相關邏輯處理文件
* @MainFunction: 保存當前產(chǎn)品模式巫员,根據(jù)不同產(chǎn)品模式配置 產(chǎn)品登錄頁庶香、http 請求 等資源
**/
import Vue from 'vue';
import portService from '@/assets/js/service/http/http'; // axios請求
import router from '@/router/index'; // 默認路由配置,動態(tài)路由配置
import httpAAS from '@/assets/js/service/http/http-aas'; // 數(shù)審獨有的 http 請求
import httpFW from '@/assets/js/service/http/http-fw'; // 防火墻獨有的 http 請求
import globalConstant from '@/assets/js/const/global-constant'; // 項目全局常量
export default {
namespaced: true,
state: {
productMode: '', // 產(chǎn)品模式简识,進入系統(tǒng)或刷新頁面時獲取
},
mutations: {
// 修改產(chǎn)品模式
changeProductMode: function (state, value) {
state.productMode = value;
},
},
actions: {
async SET_PRODUCT_MODE({ commit, state }) {
let res = await portService.getProductMode();
if (res.data.code === 0) {
commit('changeProductMode', res.data.data.productMode);
}
// 如果是數(shù)審產(chǎn)品
if (state.productMode === globalConstant.COMMON.AAS) {
// 設置產(chǎn)品登錄頁
router.addRoutes([
{
path: '/login',
name: 'login',
component: resolve => {
require(['@/views/login.vue'], resolve);
},
}
]);
// 合并 http 請求赶掖,掛載到 Vue 原型上
Vue.prototype.portService = Object.assign(portService, httpAAS);
}
// 如果是防火墻產(chǎn)品
else if (state.productMode === globalConstant.COMMON.DBSG) {
// 設置產(chǎn)品登錄頁
router.addRoutes([
{
path: '/login',
name: 'login',
component: resolve => {
require(['@/views/views-fw/login.vue'], resolve);
},
}
]);
// 合并 http 請求,掛載到 Vue 原型上
Vue.prototype.portService = Object.assign(portService, httpFW);
}
}
}
};
總結(jié)
經(jīng)過拆分七扰,數(shù)審和防火墻的代碼目錄已經(jīng)算是基本分開了奢赂,這個過程花費的力氣也很大,也引發(fā)了我的一些思考颈走,一套代碼多個項目的這種方案是否算好的方案膳灶,還有沒有其他更好的方案。如果項目一開始立由,就按照一套代碼多個項目的設計來開發(fā)袖瞻,會不會后期的維護成本會低一些?這些問題我也沒有答案拆吆,希望后來者能夠繼承歷史經(jīng)驗聋迎,更好地開發(fā)出優(yōu)秀的項目。
其他實現(xiàn)方式
起初設計拆分方案的時候枣耀,有兩種方案霉晕,一種是通過獲取產(chǎn)品模式動態(tài)改變當前產(chǎn)品功能庭再,一種是在打包時通過打包參數(shù)打包指定產(chǎn)品包。最終的方案是選擇第一種牺堰。但是拄轻,在這個過程中也參考了一些網(wǎng)上的實現(xiàn)方案,這里列出來方便以后需要用到進行參考伟葫。