前端低代码平台需求调研

一、背景

目前天画-codemaker已经经过多个迭代把Java后端代码生成的整体功能基本实现，经过慎重思考决定实现一个前端低代码平台以拉通天画-codemaker，同时也是整个天画产品线横向打通的一个小目标。在低代码领域希望让天画可以提供一个前后端一体化的代码生成方案。本篇文章将讲述前端低代码平台的需求分析和大概的调研方向，以及实现思路。

二、需求

2.1 构建API-plantUML文档并解析(实现API管理功能) 2.2 提供表结构帮助持久化 2.3 调研并选择支持至少2种市面上比较成熟的前端框架 2.4 支持生成增删改查等与API匹配的前端代码内容

三、调研方向

3.1 解析产品PRD

一开始的想法是比较美好的，比如产品将画好的原型图给到前端低代码平台，由平台解析PRD内容，但是解析需要一定的格式和内容识别，对于PRD的格式就要要求是HTML的。基于此判断进行一些调研，发现线上的一些PRD构建工具和一些其他的本地化工具都不满足，因为导出的内容要么是图片格式，要么就是HTML只是一个空壳内容还是由JavaScript进行控制的。另外找到了Axure软件，尝试简单构建了一些页面，但是结果也不太理想，内容之间没有太多关联，产品出的内容格式也不一样，无疑加大了解析的难度。

3.2 提供excel模版

在调研过程中发现百度的Amis低代码产品是一个不错的解决方案，当时想着可以制作一个excel工具模版来辅助构建一个页面，由前端低代码平台进行解析。但是工具可能强依赖Amis的方案，与Amis存在耦合关系。另外Amis本身支持众多组件，所以落地起来也有一定难度。

3.3 直接对接

在调研的过程中也想过直接对接指定的前端框架，每个框架对接一套代码，这样的想法可能比较激进，但是也不失为一个方案。在需求调研的时候我常常会想到前端会依赖后端做什么？前端依赖后端哪些元数据，而不是业务数据？想到二者的关系之后，就豁然开朗了，前端依赖后端的只是api和参数，其他的都没什么，比如校验，前端有前端的校验，后端有后端的校验。但是这不是最好的方案，毕竟成本太大，本身是希望该平台可以快速完成第一版的。

3.4 Amis web化

基于3.3的思路可以简单优化一下，就是先支持Amis的代码生成，这样的话可以先做出一些基本代码的生成功能，然后逐步扩展到其他框架，另外Amis对于后端人员也是非常友好的，本身就是低代码产品，所以对于后端人员来说开发一个简单的页面不再跟前端的具体技术细节对接是非常不错的。所以页面可视化的去管理接口，模块和参数等是基本能力。

四、Amis DSL思想

在调研一些前端低代码产品的时候，有些则是注重于拖拉拽，有些则注重于生态集成，或者框架体系集成。不同的前端低代码对于后端来说或者缺乏前端能力和资源的部门都需要一定的理解和上手成本，而且有些可视化的拖拽不仅仅是一次就搞定的，后期加字段改字段，仅仅靠拖拽改变可能也不太现实，另外一方面个人觉得拖拽式的前端低代码可能效率并不是很高。

说到Amis其本身的设计思想是比较不错的，JSON话，对于前端相关的组件，容器，元素等都进行了专门的设计，进行不同的组合和变化，可以很好的应对大多数B端场景，灵活性也不错。采用了DSL设计的话，其代码体系和产物，以及运行时相关的容器和组件职责都比较清晰，进行简单的配置即可达到想要的效果。另外也没有拘泥于具体框架，类似于屏蔽了具体前端框架的实现的作用。

五、方案思路

实现解析简单版的PlantUML代码，将API元模型构建出来
构建相关表结构
构建Amis组件和容器的映射框架
构建表单新增，单条详情展示，列表详情展示，修改的Amis JSON模版
构建SpringBoot Web服务，前端使用Amis单页应用。
构建解析PlantUML文档到API模型持久化到代码生成的全流程。
调试，增加新功能

六、总结

本文从需求分析和调研的方面来讲述了作为设计师来构建前端低代码的具体分析过程，在设计前期进行充分的需求调研则更能抓住核心需求，从其实现的动力和价值来看，它可以快速帮助后端设计一个相对完整的前端页面，同时根据后端提供的元数据可以让后端花更少的精力在前端代码上，另外一方面则可以帮助专业的前端人员更好的跟后端对接，拿到产品PRD之后可以快速的与后端一起构建前端页面，让专业的前端和后端只专注于每个页面或者交互个性化的地方，让前后端人员脱离仅仅是CURD和字段属性上，有更多的精力考虑技术设计，交互，和交付质量上。