作者:marsboyding(丁涛)  腾讯IEG高级工程师 低代码OTeam负责人

导语| 近年来,低代码/无代码开发热潮又一次袭来,业界对“降本、增效、提质”的声音越来越强。国外有西门子Mendix,微软PowerPlatform等大厂的相关低代码产品,国内有阿里的易搭,Ivx,腾讯的微搭等低代码产品,甚至公司内的低代码产品和平台就有数十种以上。我们在建设低代码产品平台的同时,能否将低代码领域公共、核心的这些能力沉淀和抽离出来,统一提供给业务团队使用呢?我们又该从哪些方面入手去建设这样的公共能力?本文将针对这些问题从公司低代码OTeam的建设层面做简单阐述。

●背景●

什么是低代码/无代码?

近年来低代码概念越来越火,各个领域各家公司都有建设和推出相关的产品,但是低代码概念绝对不是全新的概念。早在上世纪,低代码的概念就已经有了,我们使用的Microsoft的Access数据库进行图形化交互操作,我们使用Visual Basic 进行可视化界面的程序开发,我们使用Dreamweaver进行前端页面可视化开发等,都体现了低代码开发的理念。

理解低代码/无代码的概念,我们必须要从广义去理解他们:低代码/无代码是指所有能够降低编码量甚至无需编码而达到研制开发出相关服务/产品的能力的一种实现方式、工具或者平台。其实我们常见的低代码开发平台大多数都是可视化的拖拽方式实现的,但是这只是一种常见的,狭义的低代码实现方式,其实我们还可以使用表单配置、模板配置、人工智能解析RP稿/设计稿、积木交互等各种人机交互的形式来实现低代码的能力。

低代码的价值降本增效

降本增效其实可以理解为字面意思,就是为企业降低研发成本、人力成本,提升研发效率,缩短产品交付周期。

为何能降本增效?低代码产品所具备的能力有哪些?

公共代码组件化——这个能力和中台化、SDK的概念有相似之处,就是将重复的公共的能力沉淀出来,封装起来,让开发人员可以在低代码平台上,直接拿出来作为工具嵌到产品中,这样开发者就不用再关心这个功能/组件的内部实现。

开发流程可视化——可视化交互是低代码平台所具备的一种必备能力,不再面对冷冰冰的传统文本IDE编辑器,转而和可视化的编辑器进行交互,不管是UI界面,交互事件、后端接口、数据库/Redis调用,都能通过优雅而简单的可视化交互完成配置和编辑。

多端发布——对于前端研发人员,我们经常需要多端发布同一个项目/页面,在H5/小程序/IOS/Android我们经常需要不同技术栈的研发人员,而对于低代码,我们屏蔽了具体的代码选型,内部编辑的是一个DSL的语言(Schema的结构化数据),最后发布上线,我们可以将其发布成多种终端适用的产物(产品),而且能尽量保证其UI、交互、功能一致。

进一步降本增效

如果说低代码平台是为了一线研发的降本增效,那么低代码平台OTeam就是给研发低代码平台“降本增效”。目前,低代码平台/产品的功能、形式大同小异,大多低代码产品/平台都是和具体的行业/业务场景挂钩绑定,都是为了解决一些特定场景下的产物。比如腾讯IEG增值服务部的星图低代码平台,最初就是为了游戏营销活动开发而设计的,我们的微信支付、腾讯广告相关的部门也有相关的低代码产品,也都是为了提升各自业务场景下的研发效能而建设的。

低代码平台OTeam如何发力

经过了近半年的讨论和筹备,我们低代码平台OTeam,已经基本组建完毕。我们将致力于提供统一、高效的低代码核心引擎和底层库以及标准建设。具体包括以下模块:

1.建设一套统一的UI可视化开发规范和引擎

2.建设一套统一的逻辑可视化开发规范和引擎

3.建设一套统一的DSL语言和IDE

4.建设一套生产与运行解决方案(解析、编译引擎,一码多端引擎)

5.建设一套低代码质量保证解决方案(调试、测试、监控)

●建设内容●

低代码平台OTeam作为一个OTeam,将主要从产品(核心引擎)建设、标准建设、运营建设三个方面做简要概述。

核心引擎和底层库建设

如下图1,低代码产品结构从下而上,可以分为三层:引擎层、平台层、产品(产物)层,其中每一层,都是基于下一层的能力建设而来。我们低代码平台OTeam的责任就落在了最底层的5大模块建设上!

图1 低代码平台OTeam结构图

UI可视化建设

UI可视化建设主要针对前端开发领域而言。一款产品的前端展示,页面UI,交互等都是UI可视化要管的事情。在这里我们主要划分了3件事情:

  1. UI Schema规范建设。UI-Schema是核心,它是用来描述和定义UI界面所有内容的一个规范,包括页面、布局、组件的表现形式、属性范围、属性格式、值类型、样式、事件等内容。根据UI-Schema规范,我们在UI可视化模块实际维护的是一个UI-Data数据。

  2. 预览/交互引擎建设。预览引擎主要负责预览区渲染能力,交互引擎负责预览区部分UI交互能力(比如位置,布局、选中等)它接收和操作UI-Data数据,并依据UI-Data的数据进行预览区的渲染,也会依据交互动态更改UI-Data的数据。

  3. 编辑引擎/SDK建设。编辑区,是操作UI-Data的交互区域,我们可以通过它对UI-Data的各项属性和内容进行编辑,新增组件等等。

图2 UI可视化建设模块描述

逻辑可视化建设

逻辑可视化建设,顾名思义就是对逻辑层的建设。低代码平台中,最重要的就是如何将平时需要用if-else,赋值、while等代码才能表述的逻辑用可视化的方式表述出来。和UI可视化建设类似,逻辑的可视化也同样需要编辑器的建设,那么同样就少不了相关的规范、编辑器、预览区等能力建设:

1.Logic Schema规范建设。逻辑可视化建设中,Logic-Schema是核心,他是用来描述和定义一段逻辑的规范,包括各种控制语言、赋值语句、运算操作、I/O操作、网络操作、页面UI操作、组件调用等。

2.预览/交互引擎建设。预览引擎主要负责逻辑的可视化展现,我们可以展现为流程图形式、也可以展现成积木形式等等。我们不限制交互形式,我们的工作是建设一套交互预览引擎的描述和动作集。

3.编辑引擎/SDK建设。这里实现的预览引擎中各个节点的编辑能力,我们将封装对Logic-Data的各类操作到SDK中。

图3 [例子]星图逻辑可视化编辑界面

如上图3所示,为IEG星图低代码平台的逻辑编辑器的可视化编辑界面,从图中我们很清晰的看到我们的编辑区域(左侧和右侧)和预览界面(中间的流程图),所有的编辑内容都是基于Logic-Schema规范的,之间关系可以简单整理为下图4。

图4 逻辑可视化建设模块描述

代码语言建设

代码语言建设就是建设一套可以不通过可视化,而是通过少量描述语言就能实现开发能力的DSL语言规范和解析引擎,以及一些IDE工具。我们的主要建设内容为:

1.DSL规范与制定。制定一套领域专用描述语言,可以用来描述低代码逻辑和表现。

2.DSl转换引擎。建设一套Schema <-> DSL的转换引擎。让开发者通过编写DSL,能够得到同样的逻辑和UI效果。

3.IDE建设。建设一套对应DSL的IDE工具,具备识别、高亮的相关能力。

关于DSL,它是一种特定环境/领域下的专用语言,这种语言一般可以用少量的文字就可以描述一些特定的大量的固定格式的信息和动作,markdown语言就是一种DSL语言,它通过一些特定的标记比如"> # * " 等就可以描述各种段落格式,样式等,大大缩短了文本编辑人员写文章,控制格式相关的时间投入。
关于这一块的建设逻辑,我们简要通过图5来描述:

图5 DSL语言所处的位置

生产与运行建设

生产与运行建设阶段,我们需要研究如何将开发者编辑的内容数据让它实际运行起来,能够真正以产物的形式出现。我们需要对Schema Data进行处理,整合UI相关的数据和逻辑调用相关的数据,要么生成目标语言的源代码执行,要么通过解析引擎解析执行。在这个模块,我们需要做以下三件事:

1.解析引擎。制定一套Schema Data的解析器,在运行阶段能够运行解析器对Schema Data进行解析执行。

2.编译转换引擎。建设一套Schema Data的编译器,在运行之前就将Schema Data编译转换为最终能直接执行的高级语言代码(比如前的js,html,css,后端的php,go等)

3.一码多端引擎。对页面开发的产物进行多端适配和生成(web,h5,小程序,ios,android等)。

图6简要描述了此阶段要做的事情:

图6 生产运行模块需要做的事情

质量保证建设

低代码不同于传统的开发流程,在整个开发流程中,开发人员可能都不会编写一行代码,那么测试、调试、以及监控该如何去做?出了问题该如何入手呢?为此,我们必须建设一套适用于低代码的质量保证解决方案:

1.调试/测试。研发一套低代码的调试/测试相关引擎/工具

2.监控告警。研发一套低代码的监控告警相关的体系,包括上报机制、监控机制、告警机制。

标准建设

除了常规的开发工作,OTeam还致力于联合公司标准组的同事打造低代码的企业标准建设,前期我们将针对UI可视化建设展开标准的草案制定相关工作。后续我们将全面围绕,UI、逻辑、数据、DSL、生产运行、质量保证等多个模块将相关的标准写入低代码企业标准中。

运营建设

作为OTeam,除了常规的产品研发相关的工作之外,我们还需要做相关的运营建设。包括KM建设、码客平台建设、公司内外宣传分享建设等。

●近期热文●

对数据库要求最苛刻的金融行业,这套架构凭什么异军突起?

如何在一个领域保持专注

文章来源于腾讯云开发者社区,点击查看原文