管理后台提效利器Alkaid介绍

[shen1992]

目录

• 前言
• 提效技术方案对比
• 架构设计
• Alkaid功能介绍
• 更多开发场景
• 拓展能力
• 提效数据
• 展望未来

前言

Alkaid是一个vscode插件，它提效的核心是提供常用的物料，可以满足多数管理后台开发场景，借助vscode的能力将物料插入工程项目中，以提高开发效率，它具有良好的拓展性，用户可以自主开发物料达到业务功能复用的目的

提效技术方案对比

我们做技术方案之前一般都需要对现有的技术做对比，一方面是开拓视野，一方面是比较它们的优势与劣势，才能够更好的挑选出符合自身业务的技术，并且针对自身的业务需求，对技术进行优化与改进，使其更适合我们的业务开发

可视化编辑器方案

如何快速生成一个页面，有些同学可能会想到利用可视化编辑器，配置一下就能够快速创建一个页面，管理后台的实现一般也比较固定，也许是一个可行的方案，仔细思考了一下，可视化编辑器生成页面优点与缺点如下

==优点==

• 新建与编辑页面比较友好，在编辑区进行一些配置就可以快速创建与修改页面
• 页面元素可拖动，能够实现灵活布局

==缺点==

• 生成的代码一般都是一些json，可读性较差，基本无法对生成的代码进行二次修改
• 如果需要生成的页面有某个功能可视化编辑器无法支持，需要对可视化编辑进行功能迭代，灵活性较差
• 随着版本的迭代，支持的能力越来越多，配置项也会变得繁琐，可能会有冗余的配置项

总结：

可视化编辑器更适合非技术人员使用（产品，运营），降低人力投入成本，适合一些功能较为固定的页面开发

我们元气事业部的管理后台相当多

不同的管理后台，功能实现上有差异，比如流量分发管理后台，数据来源很多，有些数据存储在后端数据库中，有些从数据组那边通过es方式获取，还有些则从算法推荐组获取，对于后端来说，他们要做的就是把这些数据收集，做成一个接口返回，让前端处理成自己想要的数据结构

比如表格的树形数据

需要处理成以下结构

data = [
 {
     xxx,
     children: [
        {
            xxxx,
            children: []
        }
     ]
 }
]

这些一般都得前端自己处理，这么多管理后台，它们或多或少都有自己独特的开发需求，可视化编辑器灵活性不足，显然无法适用

插入模板代码方案

初学前端时，我挺喜欢开发管理后台的需求，因为可以使用antd提供的UI组件，学习大佬们如何进行组件封装，直到我接了一个需求，开发一个管理后台，里面七八个页面功能都差不多，开发好一个页面之后剩下的就是复制粘贴，对表格列，表单项，接口实现等进行修改，相当繁琐。

开发管理后台的需求，这些很少涉及逻辑的模板代码占比较大，个别后台数据很多，可能会有10 ~ 20列表格，7 ~ 10个搜索条件，以及新建弹窗里面的表单项数量也很多，还会带有一些表单联动的功能，于是我萌生了往工程项目当中插入模板代码的想法

我还想到可以通过接口文档生成模板代码，一般接口文档的response就是表格的每一列，request就是表格的查询条件

听起来很不错吧，经过实践，我总结了插入模板代码方案的一些优缺点

==优点==

• 生成的代码可以进行二次编辑，灵活性很好
• 可以沉淀一些物料，功能最佳实现，提供组内成员进行开发参考
• 适用功能丰富的场景，拓展性很好

==缺点==

• 逻辑方面的实现需要自己动手开发
• 比较适合新增的场景，老代码维护作用有限

总结：

往工程中插入模板代码面向的人群是开发，目的是为了提高开发效率，灵活性与拓展性是其最大的优势，适用于开发过程中需要编写大量模板代码的场景，比如管理后台的需求。

逻辑的处理需要自己实现，当然对于开发来说实现逻辑功能最简单的办法就是自己动手，这也是编程的乐趣所在

经过对比，Alkaid选择了插入模板代码方案，因为其灵活性和拓展性更好，能够满足多种管理后台开发场景

架构设计

Alkaid的架构设计如下：

简单介绍一下各层级的作用：

存储层

• 物料仓库用于开发各种物料
• bit.dev对开发好的物料进行远端存储，它具备物料版本管理能力以及成员权限管理能力，当然，使用npm也可以达到同样的效果

服务层

• node server 每隔5分钟从bit.dev轮询物料信息，同步物料的更新
• 从bit.dev同步的物料，代码都经过压缩，node server需要将它们解压为可读的源码
• nei server 分析接口文档的字段，比如字段名称，字段类型，字段描述，是否可选等

使用层

• Alkaid插件调用node server的list接口显示物料列表，调用detail接口显示物料源码
• 在Alkaid的配置页面调用nei server接口快速生成配置项，用户可以对生成好的配置项进行二次修改
• 将配置好的模板代码插入工程目录中
• 提供工程函数，组件文档，svg图标展示等拓展能力

总结：

分层的目的是为了解耦，新增或者修改物料，只需使用cli将最新的代码上传到bit.dev，node server 5分钟轮询，Alkaid插件可以使用新版本的物料了

Alkaid功能介绍

vscode 插件

上面介绍了往工程插入模板代码缺点之一就是逻辑实现需要动手开发，vscode插件可以稍微减弱这个缺点，在开发的时候，打开Alkaid插件，选择你想要的物料，配置好以后将代码插入到工程目录，或者光标位置，接着编写一些逻辑，插件的使用与编码是一体的，体验较好

带搜索表格提效

物料配置

物料的源码是一些ejs代码，需要配置的地方用占位符占位，结合接口文档的response就可以把表格的每一列配置好了

搜索项也是利用接口文档的request生成配置，这里就不赘述了，通过接口文档生成的配置项，在Alkaid的配置页面都可以进行二次修改

效果展示

快速生成带搜索表格

表单提效

开发管理后台的需求表单是必不可少的功能，antd表单的写法比较繁琐，特别是弹窗表单会经常使用，有时候还带有表单联动以及表单动态增减功能，开发起来难度增加了不少，需要想办法提高效率

我想到的办法是使用json schema提高表单的开发效率，举例：

表单的联动

例子中切换'物料类型'与'安装依赖'，都有表单项对其联动

使用antd form实现表单联动

使用json schema实现表单联动

对比这两种写法，使用json schema实现，代码确实简洁了不少（大约减少40%左右的代码），json schema方式实现表单联动，只需要增加hidden属性，判断某个表单项的值即可

hidden: '{{formData.type === "block"}}'

总结：

• antd form写法学习成本较低，但是需要编写很多模板代码，较为繁琐
• json schema写法简洁很多，但是有一些学习的成本

可能有同学会问：jsonschema代码看不懂，不好维护怎么办？

这个就是我说的学习成本了，其实要读懂json schema代码也很简单，观察几个比较典型的比如Input，Select，Radio，其生成的json schema，对比一下就能找到规律，掌握规律之后读懂并不难，毕竟其本质就是用一个对象的属性描述表单而已

维护方面其实也不用担心，一般json schema都与可视化编辑器配套使用，将json schema导入，即可看到渲染结果

当然，我觉得最好用的还是导出功能，在可视化编辑器里面拖动ui组件，点击按钮就可以导出jsonschema，不需要自己动手编写

Alkaid通过接口文档生成json schema简直不要太开心呢，表单项基本就是接口文档的request，Alkaid内置的可视化编辑可以对生成好的表单项进行二次修改，比如文档定义的imgUrl是string类型，会生成一个Input框，但是后端实际想要的是一个图片的nos地址，这个时候就可以通过可视化编辑器将Input框组件修改成图片上传组件

可以看一下使用的效果

快速生成表单

json schema需要一个render才能将其渲染成表单，我选择的是 form-render ，原因是它的概念很少，用法也很简单，我们团队大部分的同学都没接触过json schema，使用一套简单的方案可以降低大家的学习成本，毕竟提效的目的是为了减轻开发负担，并且我仔细阅读了form-render的源码，确定它的实现能够满足我们的业务开发需求才决定使用，并且作为提效方案的主负责人，组内其他成员开发过程中肯定会遇到各种问题，了解其源码实现我才能快速定位并且解决问题

如果有更高的要求，可以尝试 formily，它的性能更好，当然学习成本也相应增加了

更多开发场景

以上介绍了带搜索表格，弹窗表单两种场景，但实际开发当中，需求肯定远不止这些，在开发过程当中觉得这个功能有复用的价值都可以在物料仓库封装一个物料，Alkaid提供了配套的工具，alk-cli可以创建物料开发模板，内置的命令可以将物料上传至bit.dev

拓展能力

我们有一个前端工程，其常量，通用方法，业务组件越来越多，大家对于比人封装的功能不熟悉，所以复用率很低，Alkaid内置的jsdoc功能，按照约定的格式书写文档，可以生成文档展示

工程内也有一些svg图标，编辑器无法直接查看，导致同样的图片重复添加

Alkaid还可以方便的查看工程内的所有SVG图片，开发之前先看看工程已有的图片，防止重复添加

它们的用法很简单，只需要在工程的根目录下新建一个配置文件，指定目录即可

alkaid-config.js

[
    {
        "type": "shared",
        "items": [
            {
                "docPath": "./shared/utils/common/*",
            }
        ],
    },
    {
   
        "type": "images",
        "dirPath": "./shared/icons/svg-icons"
    }
]

提效数据

最后展示一下大家关心的提效数据，我们团队，已经有6名成员使用过Alkaid，在5个管理后台使用Alkaid开发过需求，具体的提效数据与使用者的熟练度有一定的关系，比如我作为Alkaid的作者，提效还是比较明显的

• 同样一个达人申请后台，我与另外一个同学相比，开发工时缩短了50%
• 同样一个推集主题管理后台，我使用Alkaid开发效率可以提升30%
• 对于一些已经掌握Alkaid基本用法的同学，能够提升他们20% ~ 30%的开发效率，我就已经十分满意了

展望未来

最开始我们也只是想开发一个管理后台提效工具，后来发现利用vscode plugin的能力，可以解决工程开发痛点，于是开发了一些拓展能力，我们前端组内工程还有很多，她们或多或少都会遇到这样那样的问题，Alkaid可以尝试解决

管理后台提效方面，可以做的事情其实还有很多，比如物料的丰富，逻辑编写能否有更好的解决方案，以及工具成熟完善之后可以考虑开源等。