如何做好一个管理人员演讲（如何做好一款管理后台框架）
序
2020 年 10 月 17 日 ，我正式发布了 Fantastic-admin 这款基于 Vue 的中后台管理系统框架 。在这两年多的时间里 ，我陆续写了几篇我在开发这套框架中的一些心得和技术总结：
2020 年《我是如何设计后台框架里那些锦上添花的动画效果》 2020 年《一劳永逸 ，解决基于 keep-alive 的后台多级路由缓存问题》 2021 年《在后台框架同质化的今天 ，我是如何思考并做出差异化的》 2022 年《神奇！这款 Vue 后台框架居然不用手动配置路由》但是今年 ，有大半年的时间我几乎销声匿迹 ，没有产出一篇文章 。除了一直在维护和迭代框架外 ，我也在思考一个问题 ，那就是：
如何才能做好一款管理系统框架？
有手就行？
这是“VUE后台管理系统模板 ”网站上整理的一些相对做得比较出色 ，或者说有一定知名度的框架 。当然这也只是冰山一角 ，如果去 Gitee 或者 Github 搜索 “后台 ” “admin ” 等关键词 ，你还能发现更多 。似乎写一个后台框架对前端开发来说 ，有手就行？
确实 ，一个标准的后台管理系统 ，大部分基础功能是相对统一的 ，因为它不像C端产品需要高度定制化 。一个侧边或者头部导航栏 ，通过配置自动生成；再预设几套主题 ，方便切换；然后写几个通用模块 ，比如用户管理 、角色管理 、字典管理；最后再加个登录页 ，完善下权限控制 ，基本就大功告成了 。
要实现这些难么？不难 ，对前端来说 ，确实有手就行 。这也促使很多开发者选择自己写 ，写完有兴致的还会推广宣传一番 ，反馈好就继续维护 ，没啥反馈可能就逐渐变成了一个自用框架或者弃坑了 。
这也是为什么网上有如此多后台框架的原因 ，因为一直有新的框架出现 ，也有大量框架已经几个月 ，甚至超过半年时间未更新 ，颇有一种「你方唱罢我登场」感觉 。
给谁服务？
回归到主题 ，既然要做好一款管理系统框架 ，那谁来定义这个“好 ”呢 ，是客户吗？是 ，但又不全是 。
任何一款技术框架或产品 ，最终一定是服务于客户 、服务于业务的 ，但做为一款管理系统框架 ，我认为更多还是服务于开发者 ，让开发者用更少的时间 ，完成客户或业务需求 ，那就是一款好的管理系统框架 。
但是一个有手就能写的框架 ，要让开发者选择使用你的 ，而不是自己去写 ，想必肯定不是实现上面那些功能那么简单 ，那要如何服务好开发者呢？
如何服务？
既然确定是给开发者服务 ，那就需要确定开发者的痛点 。好在我本身也是开发者 ，在公司内部业务开发中就有实际在使用 ，所以开发中的痛点还是比较好找的 ，无非以下几点：
通用业务组件少 相似业务模块需要频繁拷贝代码或文件 特殊场景缺少统一解决方案 框架本身提供API少 ，扩展性差针对以上整理的几点 ，下面我会用几个实际的例子来介绍下我是怎么为开发者提供服务的 ，或者说我是怎么服务自己的 。
毕竟只要我自己觉得用得爽了 ，其他开发者的使用体验也肯定不会太差 ，当然前提是拔高自我要求 ，以“人无我有 ，人有我优 ”做为目标 。
通用业务组件少
这个痛点是相对比较容易解决的 ，因为市面上各种 UI 库已经能满足大部分的业务使用需求了 ，我只是做了一些二次封装或补充 。
比如在 Element Plus 的 Cascader 组件基础上 ，封装了省市区街道联动组件 ，方便实现二级 、三级和四级的选择联动：
再比如在 Element Plus 的 Upload 组件基础上 ，封装了图片上传组件 ，提供了多图排序 、多图预览 、文件类型和数量限制等特性：
除了对 Element Plus 进行一些二次封装外 ，我还补充了一些组件 ，比如趋势标记组件：
还有搜索面板组件：
当然不仅仅是上面介绍的这些 ，更多可以访问 演示站 进行查看 。
我想说的就是 ，通用业务组件 ，是框架比较容易解决的一个痛点 ，因为它肉眼可见 ，通过原型图或设计稿 ，找出一些频繁在多个业务模块中出现的功能 ，就可以考虑是否可以封装成组件 ，从而减少开发者自己去实现的时间 。
相似业务模块需要频繁拷贝代码或文件
后台系统里 ，一定有一些模块在界面 、操作逻辑上是高度相似的 ，比如各个模块里的列表页 ，它们都有搜索功能 、数据展示 、分页功能 。但又不完全一样 ，比如数据源 、搜索项 、列表展示字段都不一样 。
对于这种场景 ，我的做法是通过框架预设的目标 ，搭配交互式的指令去生成对应的文件 。小到组件和单页面的模板 ，大到整个模块（包含列表页 、详情页 、新增 、编辑 、删除功能一应俱全） ，都可以通过几个指令快速生成 ，如下图：
当然开发者也可以根据具体业务场景 ，自行扩展需要生成的模板 。
特殊场景缺少统一解决方案
这一块的痛点 ，更多体现在框架自身的能力上 ，也是我认为决定框架是否好用中最大的因素 。
因为上面提到了两个痛点 ，即使框架做得不到位 ，开发者也能自己想办法去解决 。业务组件少可以自己写 ，或者找三方别人写好的组件；频繁拷贝代码也不是多大的问题 ，开发者可以借助编辑器的代码片段功能 ，或者其他方式去提高效率 。
但一些稍微特殊的场景下 ，如果框架本身没有考虑到 ，那需求只能向框架妥协 ，毕竟不是所有开发者都有能力去完整阅读框架源码 ，并进行二次开发定制功能 。
说了这么多 ，可能大家还不清楚到底有哪些特殊场景 ，这里我举几个我遇到的：
大家可以对比下现在正在使用的框架是否能满足这些场景下使用 ，也可以留言分享一些其他业务场景
1 、导航栏按需隐藏
导航栏是个必备的功能 ，尤其是这种分栏布局的导航（主导航+次导航） ，既然有分栏导航 ，那就会有次导航能否隐藏的场景 ，效果如下：
我的做法是通过两个独立的配置项组合使用 ，实现了这一场景 ，分别是 切换主导航时自动跳转到次导航里第一个栏目路由 和 次导航只有一个栏目时自动隐藏 。
2 、标签页合并
标签页的实现是通过路由切换来实现的 ，每访问一个路由就会增加一个标签页 。
但有的场景需要对标签页进行合并 ，比如反复从列表页打开不同条目的编辑页 ，因为每个编辑页的路由不同 ，所以对应也会生成多个标签页 ，这时候就希望能将所有编辑页的标签页合并成一个 ，效果如下：
既然有编辑页合并的场景 ，那也会有列表页和编辑页合并的场景 ，比如同个模块下 ，不管是列表页 ，还是编辑页 ，或者其他同属于该模块下的页面 ，都希望能合并成一个标签页 ，效果如下：
这块我的做法是提供了一个合并规则的配置项 ，默认不合并 ，同时支持 根据路由name进行合并 和 根据activeMenu进行合并 两条合并规则 ，分别对应了上面两个场景 ，具体配置可参考文档介绍 。
3 、页面按需缓存
在了解这个场景前 ，我们先要知道什么是页面缓存 ，就是当用户离开当前页面后 ，再返回该页面 ，需要复原离开时的所有状态 ，这就是页面缓存 。
页面缓存是一个比较常见的场景 ，部分框架也提供了支持 ，但按需缓存 ，也就是根据离开并访问的目标页面 ，判断是否需要对当前页进行缓存 ，举个例子：
假设 A 页面的缓存规则是 ，如果离开并访问 B 页面则进行缓存 ，访问其他页面则不缓存；或者只有离开并访问 B 页面不缓存 ，访问其他页面则都需要缓存 。
如果是上面假设的这两个场景 ，按照大部分框架提供的能力（即在路由配置里提供一个页面是否开启缓存的设置项） ，可能就不一定能满足了 ，因为页面缓存只提供了两种状态 ，即始终缓存和始终不缓存 。
而我的做法是分别提供了 cache 和 noCache 两个设置项 ，开发者可以对 cache 设置 true/false 值以满足页面始终缓存或始终不缓存的场景 ，也可以设置路由的name ，实现精细化缓存控制 ，还是拿上面两个场景举例 ，就可以轻松配置成：
// A 页面离开并访问 B 页面则进行缓存 ，访问其他页面则不缓存 cache: b-route-name // B页面路由name // A 页面只有离开并访问 B 页面不缓存 ，访问其他页面则都需要缓存 cache: true, noCache: b-route-name // B页面路由name更多细节可参考文档介绍 。
框架本身提供API少 ，扩展性差
这一痛点的根本原因其实是上一个痛点造成的 ，因为能力少 ，所以能暴露出的内部方法就不多 ，所以能提供的 API 自然也就少了 。
这里我就介绍几个简单的 API ，大家可以点预览链接看实际效果：
1 、主导航切换
import useMenu from @/utils/composables/useMenu const { switchTo } = useMenu() switchTo(index)预览
2 、主页面刷新
import useMainPage from @/utils/composables/useMainPage const { reload } = useMainPage() reload()预览
3 、主页面最大化
import useMainPage from @/utils/composables/useMainPage const { maximize } = useMainPage() // status: true / false maximize(status)预览
4 、动态标题
有时候 ，我们需要在某个页面显示自定义的标题 ，而不是 meta.title 字段 ，比如在编辑用户的页面 ，显示当前用户的名称 。
import useSettingsStore from @/store/modules/settings const settingsStore = useSettingsStore() onMounted(() => { settingsStore.setTitle(测试标题) })预览
5 、标签页相关
提供了打开 、关闭 、检验等 API 。
预览
结尾
写到这里 ，想扯点题外话 。
今年的某个时间 ，我突然对“程序员转行 ，最适合转产品经理 ”这句话有了更多认同感 。而在程序员这个大类里 ，我认为前端开发是其中尤为适合转产品经理的 。
因为大部分客户不在乎你用什么技术 ，他们只看中“外表 ” ，像界面是否好看 ，操作是否合理 ，动效是否流畅 ，而前端开发大部分日常工作内容就是在和这些打交道 。当接触了足够多的业务需求 ，就越了解客户想要的是什么 ，就能在下个业务需求里快速找出其中的痛点或者不合理的地方 ，并提供一个相对成熟的解决方案 ，这同时也是一个产品经理所应该具备的能力和经验 。
就像我写的这款管理系统框架 ，这一年我不满足于堆砌新特性 ，而是在此基础上思考怎么更好的去服务使用我这套框架的开发者 ，不仅满足他们的需求 ，还要让他们用得舒适 ，正如 Fantastic-admin 官网首页的标语——“开箱即用 ，提供舒适开发体验 ” 。
感谢大家阅读到这里 ，希望文中我的拙见能给大家带来一些启发 。
创心域SEO版权声明：以上内容作者已申请原创保护，未经允许不得转载，侵权必究！授权事宜、对本内容有异议或投诉，敬请联系网站管理员，我们将尽快回复您，谢谢合作！