開發遊戲陪玩系統原始碼後臺管理系統是大部分遊戲陪玩系統原始碼前端開發人員接觸過的專案，如何更好的進行專案的搭建、元件的開發、資料結構的設計等等，這些都是需要考慮的問題。以下是我結合一些專案的經歷和其他大佬的專案程式碼與技術分享，做出了對於後臺管理系統中前端專案的思考。

1. 瞭解需求，熟悉掌握需求

這一要求無論是對於遊戲陪玩系統原始碼前端開發人員或是其他端的開發人員，都是能夠順利開發專案的前提。在開發遊戲陪玩系統原始碼之前，需對 PM 的需求瞭然於胸，對原型設計能夠充分掌握。理解每一個操作邏輯的含義，並且擴散思維思考如何進行元件和資料結構的設計。
但是單獨只是對需求文件和原型進行閱讀是比較容易遺漏某些功能點的，最好能夠對專案重新設計一張思維導圖，從開發自己的角度進行設計，從專案整體的根節點出發，細分每一個模組，每個模組下設計好對應的需求，確保每一個功能不被遺漏。雖然多花了設計思維導圖的時間，但我覺得這是值得的，這樣不僅僅能夠增加對於整體專案的理解，也能更好的及時發現專案的難點和疑惑點。

2. 確定技術選型

遊戲陪玩系統原始碼後臺管理系統的主流技術選型為 Vue+ElemetUI，不過個人覺得在元件設計上 Ant Design Vue 的 UI 框架設計得好一些，更多的是採取資料驅動元件的設計模式，在遊戲陪玩系統原始碼開發中可以更方便的解耦邏輯函式。不過 UI 框架的選擇還是得結合開發人員團隊自身對於某一個的熟練程度和是否有對應的 UI 框架能更好的解決專案中存在的難點進行綜合比較。
全域性按需引入 element-ui 元件：

import Vue from "vue";···
import { Input } from "element-ui";Vue.use(Input);

元件使用：

<el-input
  v-model="user"
  clearable
  @keyup.enter.native="search"
  @clear="search"></el-input>

3. 設計專案結構

通過 Vue 腳手架工具搭建的前端專案在 src 資料夾下可分為以下幾部分：

路由層 router
靜態檔案層 assets
頁面結構層 views
元件結構層 components
全域性狀態管理層 store
功能邏輯處理層 util
常量管理層 constants

在遊戲陪玩系統原始碼中還可以引入更多的配置如混入層 mixins 、過濾層 filtters 等。
在遊戲陪玩系統原始碼開發中，需要區分開業務功能和非業務功能的邏輯設計，對於一些可以解耦出來的非業務功能函式，一般不直接在開發頁面的業務邏輯中直接定義此函式，而是需要抽離出來，可供多個業務功能函式進行呼叫。
元件結構層 components 中一般也只開發非業務功能相關的頁面元件或功能元件，以供多個頁面結構進行呼叫，若一個頁面需分成幾個元件開發，且此子元件屬於業務功能的，建議直接在頁面結構層 views 中定義，開發和維護同一個頁面也比較方便。
src 資料夾下結構如下：

├─assets
├─components
├─constants
├─mixins
├─request
├─router
├─store
├─utils
└─views

4. 資料請求 methods中 OR actions中

一般遊戲陪玩系統原始碼中對於資料請求的方式都是基於 methods 鉤子或其他生命週期鉤子中呼叫請求方法，也存在一些專案中是通過傳送一個 disptach 非同步請求方法在 actions 中呼叫請求函式。使用後者的說法是便於統一管理請求介面，並對請求返回的資料進行統一的管理。
綜合以上兩種做法，可以優化遊戲陪玩系統原始碼中的請求方式，若請求介面發出後返回的資料需要在多個頁面或多個不同的元件共享和使用，則推薦在需要發請求的函式中 dispath 觸發，在 actions 中傳送請求，返回的資料儲存在全域性狀態管理 state 中。
methods 中傳送請求方式：

getGraphicCode () {
  let vm = this;
  api.login.getCheckCode({
    type: '2'
  }).then(res => {
    if (res.code === '000') {
      vm.graphicCode = 'data:image/png;base64,' + res.data.img;
      vm.imgId = res.data.imgId;
    } else {
      vm.$message.error(res.msg);
    }
  })}

actions 中傳送請求方式：

findAllRoles({ commit }) {
  return new Promise((resolve, reject) => {
    api.systemAccount.findAllRoles().then(response => {
      if (response.code === "000" && response.success) {
        commit(MUTATIONS_TYPE.AllROLES, response.data)
        resolve(response);
      } else {
        reject(new Error(response.code, response.msg))
      }
    })
  })},

5. 登入與許可權管理

token 驗證是目前大部分前後端分離的遊戲陪玩系統原始碼做登入驗證比較常見的方法。前端通過傳送賬號和密碼或賬號和驗證碼給到後端後，後端驗證通過會返回一個唯一的 token 作為該使用者的登入憑證，在之後的每個請求當中，請求頭中都需帶上這個 token 作為後端的登入校驗。
token 有過期的機制，可以在請求攔截中做邏輯判斷處理，若當前時間接近了過期時間，則通過更新 token 的介面請求更新 token ，在之後的請求中帶上新的 token 。以此迴圈，若使用者過長時間無操作，則可認為使用者為離線狀態，在使用者之後的第一次請求時，由於 token 已經過期，訪問後端介面會發生錯誤，根據後端返回的錯誤狀態碼作為判斷，將系統定向至登入頁面。
通過帶有 token 請求頭的請求方法，遊戲陪玩系統原始碼後端可以判斷到是哪一個使用者，前端也可以通過獲取許可權介面獲得該使用者的許可權列表，根據遊戲陪玩系統原始碼許可權列表做一份路由對映表，如果後端返回的資料結構與前端的路由設定的資料結構不同，此時還需編寫此對映路由的業務功能函式。
如果該使用者擁有此路由許可權，則通過在全域性路由監控中 router.beforeEach 進行 router 中的 addRoutes 方法將有許可權的路由配置新增到路由當中，側邊欄也可根據路由列表中的 meta 欄位中關鍵字的判斷進行相應的渲染。如果許可權的顆粒度小到一個按鈕，則可根據遊戲陪玩系統原始碼後端返回的許可權列表對映出的許可權引數，通過 v-if 進行判斷該功能元件是否渲染。
在路由管理中通過 router.beforeEach 鉤子中判斷當前的路由許可權是否為空，是的話則可執行獲取許可權路由的介面：

store.dispatch("getUserInfoAndAuthorityInfo").then(res => {
  // 根據後端返回的路由許可權格式轉成前端路由配置格式
  const rolesRoute = setAsyncRouterMap(res.menuList, asyncRouterMap, mainChildrenAsyncRoutes)
  store.commit(Vue.VUEX_TYPES.ROLESROUTE, rolesRoute);
  // 新增路由
  router.addRoutes(rolesRoute);
  next({ ...to })}).catch(() => {
  Message.error("驗證失敗")
  next('/login')})

6. 常量列舉值管理

在遊戲陪玩系統原始碼當中對關鍵的常量列舉值進行管理是非常有必要的。比如在專案當中後端用某個狀態碼 1 代表賬號為啟用狀態，如果在遊戲陪玩系統原始碼當中多次使用 ===1 去判斷賬號是否為啟用狀態，當需要更改這個狀態碼的時候，對於前端來說是一件十分麻煩的事情，所以可以通過把 1 賦值給一個常量，在遊戲陪玩系統原始碼中引用這個常量，如果需要更改狀態碼的時候，則直接改變這個賦值給常量列舉值的狀態碼即可，常量的配置也可提醒開發人員此引數不可輕易修改，便於專案的維護和統一管理。一般常量列舉值的管理寫在 constants 層中，常量的變數名使用大寫字母編寫。
狀態列舉值得配置如下：

/**
 * 賬號狀態對照表
 * "0" 未啟用 NOTUSED_CODE
 * "1" 已啟用 ENABLE_CODE
 * "2" 已停用 DISABLE_CODE
 */const NOTUSED_CODE = "0";const ENABLE_CODE = "1";const DISABLE_CODE = "2";const ACCOUNT_TYPE = {
  [NOTUSED_CODE]: "未啟用",
  [ENABLE_CODE]: "已啟用",
  [DISABLE_CODE]: "已停用"};export default Object.freeze({
  NOTUSED_CODE,
  ENABLE_CODE,
  DISABLE_CODE,
  ACCOUNT_TYPE});

7. 元件設計

遊戲陪玩系統原始碼前端專案當中可以把展示元件分為兩部分，分別為頁面元件和功能元件。對於頁面元件，常用於展現頁面的整體內容，承擔著業務邏輯的正常執行，與業務比較有強的耦合性。功能元件是用於展現和處理某一單一或某一模組的功能，功能元件並不關心頁面的業務邏輯，充當著一個函式的作用，只要有輸入便有對應的輸出，並可在多個頁面元件或功能元件中被呼叫。
綜上，在設計遊戲陪玩系統原始碼頁面元件的時候，不僅應該考慮該元件能夠正常的完成業務的功能，還要考慮其是否能夠脫離業務成為一個功能元件，對於內容比較多的頁面元件，可以在其同級目錄下新建多個子頁面元件共同構建。在設計功能元件時，需考慮元件的佈局、邏輯、檢視，功能元件的設計難度在於其要考慮到滿足不斷更新的需求變化，可擴充套件性，靈活性是設計的一大挑戰。
頁面元件目錄格式如下：
在這裡插入圖片描述

8. 必要的開發文件或註釋

遊戲陪玩系統原始碼的開發文件可編寫為md檔案格式存放於專案的根目錄，一份好的開發文件能夠對專案的背景進行介紹，說明專案的結構和開發的步驟，更有利於其他開發人員參與或接手專案。
對於專案當中使用到的與業務功能耦合的邏輯函式，較為複雜的，編寫函式的介紹以及使用方法，做好邊界條件判斷，示範輸入資料以及對應的輸出結果，可在專案中新建 docs 資料夾存放開發過程中的使用文件。
對於遊戲陪玩系統原始碼非複雜功能的業務邏輯函式或非業務邏輯函式，可直接在定義函式之前編寫註釋，說明函式作用功能，以及對應的輸入和輸入引數的型別。
每次的開發過程都可當做是一個學習和總結經驗的過程，對比以往的程式碼，我們可以思考程式碼結構是否能設計得更加完善，邏輯函式是否清晰且考慮邊界條件，效能是否可以更加的優化。

本文轉載自網路，轉載僅為分享乾貨知識，如有侵權歡迎聯絡雲豹科技進行刪除處理
原文連結：

關於遊戲陪玩系統原始碼後臺管理系統，需要思考的二三事