说明

本文记录了我是如何搭建后台管理系统的，以及我的一些反思和心得。

背景

我们公司希望做一个更符合业务需求的后台管理系统，因此需要我重新搭建一个新后台出来。以下是对我根据自己搭建新后台的一些记录。

搭建过程

首先，我确定了项目要使用的技术栈：vue+vuex+vue-router+elementUI。
然后我利用脚手架搭建了一个项目出来。
这个后台管理系统我是直接参考了后台前端解决方案，并最终在使用了该开发者提供的另外一个极简的 vue admin 管理后台。因为我们这个后台不需要那么多功能，我打算在这个模板的基础上按照需求添加功能。

但是，我也没有直接使用这个极简模板，主要原因是我觉得它的目录结构以及部分规范不符合我的希望，因此最终我是脚手架搭建了一个项目，并按照极简模板的实现按照新的目录规范移植了过来。

目录结构

以下是我刚开始时定义的目录结构：

├─mock                            # 项目mock 模拟数据
│  └─store
│      └─modules
├─public                          # 静态资源
├─src                             # 源代码
│  ├─api                          # 所有请求
│  ├─assets                       # 此文件夹是打算废弃的
│  │  └─404_images
│  ├─common                       # 公共资源
│  │  ├─js						  # 公共js
│  │  └─scss                      # 公共样式
│  ├─components                   # 通用组件
│  ├─configs                      # 项目配置文件
│  ├─icons						  # 项目所有 svg icons
│  ├─layout                       # 全局 layout
│  ├─plugins				      # 插件 目前用于按需引入ElementUI
│  ├─router                       # 路由
│  ├─store                        # 全局 store管理
│  ├─styles                       # 此文件夹是打算废弃的
│  └─views                        # views 所有页面
├─tests                           # 此文件夹是打算废弃的
│  └─unit
└─__tests__                       # 测试，还没配置好
    ├─common-js
    └─components

到这里，其实这后台的框架就大致搭建好了。

约定的风格

接着我制定了项目开发约定的风格
这里我是参考了单文件组件文件的大小写-强烈推荐

组件

组件可以存放在两个地方：/src/base /src/components 以及 views 内（仅限非公共的业务组件）

components文件夹内所有的Component文件夹都是以大写开头 (PascalCase)，同时组件以 index.vue 命名

部分视图使用的非公共组件，可以直接放在对应视图文件夹内，文件同样要以大写开头，以便与视图文件分开

视图文件

视图文件统一放在 views 中，所有视图文件统一使用横线连接 (kebab-case)，代表路由的文件夹也是使用同样的规则。某些情况下，命名允许使用数字。

视图是和路由对应的，为了避免 views 文件夹里视图文件过多，一个模块（或者说对应后台的一个一级菜单，对应路由的话就是一级路由）必须起一个文件夹，二级路由后可以视情况决定是否要保持和路由一致。

JS 文件

所有的.js文件都遵循横线连接 (kebab-case)。

例子：

• @/src/utils/open-window.js
• @/src/views/svg-icons/require-icons.js
• @/src/components/MarkdownEditor/default-options.js

API

API 需要和请求的使用位置的目录结构一一对应，如果已知请求被多个地方使用，可以在/src/api 文件夹内新建一个 public 文件夹放置这些通用的请求

继续调整

在大致定下了目录和风格后，我开始尝试结合业务与开发需求，调整一下webpack的配置。

使用环境变量

开始的时候，我想到了这后台可能要用于管理员后台、代理商后台等，这个是我们的项目主管要求的，理由是这样一个后台比较好维护。因此我一开始的思路是这3个项目整体结构是一样的，登录页面是不同的，每个后台的页面可能也是不同的，但是它的底层配置是同一套的，同时组件必须懒加载，因为显然管理员后台是不需要加载代理商后台的代码的。
有了这个大致的想法，我就想到我想到了一种实现：
利用环境变量，来区分不同的后台，使用VUE_APP_USER_TYPE来标识。
然后编译代码时要用命令行控制环境变量，使用类似npm run serve:admin来传入不同的环境变量。
利用这个办法，我也许可以控制代码打包时只打包对应后台相关的代码。但这个我没有最终实践，因为后面发现3个后台的权限等实现不尽相同，拆开开发的话效率更高，所以放弃了这种3合一的想法。事实上，后台框架搭建好后，底层的变动是很小的，没有必要非要将3个后台合并在一起。

但是环境变量这个我其实还是用到了，因为这套代码要同时应用到不同的项目中，二者的区别不大，因此我还是用了环境变量来区分不同的项目，不过这两个项目的代码是一模一样的，所以不需要根据不同项目打包不同的代码。当然，这两个项目的环境变量不同，会导致个别变量和逻辑有一点不大的区别。

调试优化

在原模版上进行开发，我发现进行代码调试异常痛苦，经过研究，发现是因为配置时，我采用的极简模版配置开发时的代码映射（SourceMaps）不是精确的行映射和列映射，这大概是该开发者希望提高速度而做的配置，但我觉得这反而影响了我开发定位问题调试的效率。我认为开发时调试是非常重要的，因此将其重新调整为’eval-source-map’，按照文档，它为开发提供了最优质的SourceMaps。

It yields the best quality SourceMaps for development.

相关的文档文档：Development

配置别名

这个又是一个提高开发效率的配置，特别的不仅仅可以配置js的别名，还可以配置预处理器引入文件夹的别名。
这样引入特定文件夹样式时就方便多了

@import "~scss/variables";

其他一些webpack配置

例如我希望打包后，生成的文件夹可以根据环境生成相应的文件夹，以下是例子

{
  // 我希望分文件夹生成build后的文件，分成buil/test 和 build/
  outputDir: `dist/${process.env.NODE_ENV}/${
    process.env.其他环境变量
  }`,
  lintOnSave: process.env.NODE_ENV === 'development',
  productionSourceMap: process.env.NODE_ENV === 'development',
}