低代码平台实践系列（一）：逻辑配置概述

背景

作为前端开发人员，大家可能已经很熟悉现有的前端框架和工具，但是随着数字化转型的推进，越来越多的企业需要更快速、更高效地构建自己的应用程序。低代码平台可以成为我们前端开发人员解放生产力的神器。

低代码平台为用户提供了可视化的界面、拖拽式的组件和自动生成的代码等功能，让用户能够更快速地创建应用程序，而无需编写大量的手动代码。

我在团队内负责的是社区、用户和品类等所有运营相关业务的前端研发工作，此类运营活动（业务）具有以下特点：

1. 时效短，变化快，频率高。运营活动的生命周期在1天到1个月不等，并且需要根据活动反馈实时调整部分内容，而且活动进行到不同阶段有不同的页面（如比赛类的运营活动），负责各个模块的运营们每周甚至每天都有自己的活动需要上线发布，需要投入大量的开发人力去满足运营需求。
2. 互动性强。通常运营为了提高用户活跃度，会上线许多互动性比较强的活动。比如拿抽奖类活动来举例，页面内会有很多区域去引导用户做任务，这些任务有些是页面内，有些是其他页面的，通过完成任务来换取抽奖次数，并引导用户去参与抽奖，消耗抽奖次数。从整个页面的流程来看，相比于那些偏展示型的页面，交互逻辑会复杂一些。

所以根据这些特点，我们可以确定以下目标：

1. 满足运营活动迭代频繁的场景
2. 解放开发人员的生产力
3. 需要支持交互逻辑较为复杂的场景。

基于此，我在团队内开发了一套低代码平台，服务于我们的运营团队。平台上线将近一年的时间，就已经产出有效页面超过500+个，按平均工时2天+/人来计算，至少节省了1000+天/人。

本系列会结合我在开发低代码平台时的思考和实践，详细介绍低代码平台涉及到的概念和技术。目前已经有很多低代码相关的文章会介绍UI配置（既如何生成页面UI）的实现，所以我想先介绍低代码的另一个核心模块：逻辑配置。（系列后续文章我也会写UI配置）

注：后文会以运营人员指代平台用户（非开发人员）

逻辑配置

在低代码平台中，逻辑配置是指通过可视化界面配置不同的业务逻辑，而无需编写大量代码。通过UI配置生成的是静态页面，可以理解为HTML+CSS，不存在任何交互逻辑。但目前几乎很难见到纯静态页面，通常会通过JavaScript代码给页面添加交互逻辑。

所以逻辑配置在整个低代码系统中起到的作用是，让用户能够在页面内进行交互，比如关注用户、跳转页面等。

历史版本

版本1：交互逻辑封装组件

前期为了快速上线和上手而研发的版本，将交互逻辑内置到组件，也就是说逻辑和UI是高度耦合的，所以这个版本是开发人员维护起来最难受的版本 ， 但也是运营人员认为最好用的版本。

优点：对于运营人员来说，心智负担低、上手容易；对于开发人员来说，实现难度低，能够快速支持上线

缺点：高度封装，扩展性差，难以支持稍微复杂的交互逻辑，更难以维护

版本2：线性流程表单

操作用表单UI，数据以流程图展示，属于DAG过渡的版本，此版本已经具备较高的可扩展性。

优点：触发和事件脱钩，支持触发、事件的排列组合，扩展性强。

缺点：不支持分支逻辑，无法进一步处理更复杂的场景，同时要求运营人员对业务流程足够熟悉、表单的交互体验不够友好。

版本3：DAG（Latest）

DAG，有向无环图，H5活动配置平台目前最新的逻辑配置解决方案。

为什么用DAG？

回到版本1 - 交互逻辑封装组件，那么运营人员为什么会认为这个版本是最好用的版本？因为几乎没有上手难度，只需要在指定的输入框填写业务参数。比如实现关注流程，只要在输入框填写被关注用户的uin和关注后的按钮文案就可以实现关注的交互。

可这样做的代价是开发人员要承担的，耦合于组件内难以维护的交互逻辑，组件库更新迭代带来的指数级增加的研发成本，以及为了实现复杂逻辑流程所产生的冗余的代码。所以，与UI配置不同，逻辑配置完全由开发人员主导，也必须由开发人员主导。

基于版本1的研发痛点，提出了版本2 - 线性流程表单。所有耦合于组件的交互逻辑，都将被解耦抽离，并进行逻辑拆解，独立成为事件（handler），事件为逻辑执行的最小单位。此时，逻辑配置与UI配置在研发层面上已经解耦，交互逻辑内部也被拆解成独立可执行的单位。 基于全新的逻辑配置的架构设计有以下优势：

1. 支持扩展任意事件，目前支持的事件中，包括用户关注、页面跳转等常规事件，还有抽奖、投票、游戏角色选择器等互动性更强的事件。逻辑配置会提供标准事件规范（Event Schema），通过对基于标准事件规范生成的数据进行解析，然后去编写相应的事件逻辑的JavaScript代码，就可以被逻辑配置模块识别并执行，所以只要基于规范去编写，任何你需要的事件都可以添加到逻辑配置中。从以往实践来看，开发业务逻辑（比如在做其他业务需求的时候，刚好要实现关注用户的方法）的时候，如果是基于标准事件规则去开发，既不影响在业务开发中被使用，又能直接被逻辑配置识别，提供给所有H5活动配置平台的用户使用，一举两得，可以说是最佳实践。

<!---->

2. 触发和事件脱钩，触发作为标识存在，用于识别用户的操作，当命中到触发行为时，会执行与之匹配的交互逻辑，需要注意的是，这里的交互逻辑不再是hardcode，而是遵循标准逻辑规范（Logic Schema）所创建的数据。基于此，就能实现触发与事件的排列组合，产生各种复杂的交互逻辑。

而如果运营人员想进一步实现基于不同情况的更复杂的交互逻辑，版本2的线性流程表单就无法支持，比如，判定用户是否关注某个作者，如果是，展示文案A，否则，展示文案B。此外，线性流程表单本质还是表单，虽然尽可能往流程可视化的方向靠拢，但本质还是表单，无论是使用体验还是视觉效果都算不上好。

基于版本2的业务和体验痛点，提出了版本3 - DAG。idea来自游戏开发领域的蓝图概念：Introduction to Blueprints | Unreal Engine 4.27 Documentation。我在思考和理解Unreal和Unity作为游戏引擎，是怎么通过Blueprint帮助不熟悉的C++或者C#的游戏设计师们实现游戏脚本；同样的，作为开发人员，又要怎么去帮助不熟悉编程的运营人员实现交互逻辑。

从研发成本来说，DAG是3个版本中最高的，版本3方案，融入了前2个版本一些核心的思想和实践，再去整体设计和研发新的逻辑配置架构。首先DAG的使用，体验上有了明显的提升，可交互的图形化界面能够更清晰和直观地展示交互逻辑内部的组成和关系。同时，逻辑分支的支持使得基于不同情况的复杂业务场景也可以通过配置完成，而不需要由开发人员去研发。

版本1是为了满足快速上线和上手的实际需要；版本2是为了提升研发效率；版本3则是基于业务场景和交互体验出发去解决问题。从版本1到版本3，每个版本的提出和研发都在循环渐进地优化和完善逻辑配置模块。

进行到版本3的时候，看起来从研发到业务，目前的逻辑配置已经挺完善了，但作为开发人员很容易忽略一个问题，就是从运营人员（非开发人员）的角度来说，使用这套工具会有多大的心智负担。

版本1是基于运营人员的角度出发去实现的，所以不存在这个问题，但对于开发人员来说，需要面对是难以维护的代码和可扩展性极差的模块。从版本2开始，基于开发人员的角度为了提升研发效率，对版本1做了大幅度地重构，把原先运营人员友好的业务流程重组，加重运营人员的心智负担。

所以，虽然版本2开始，在研发层面解决了一些问题，但对于运营人员来说，使用体验反而变差了，因为版本1的时候，业务流程对于运营来说是黑盒，完全由开发人员自行封装实现，对外仅保留关键字段的表单输入。而对于多数运营人员来说，虽然能够描述业务场景，但把业务场景抽象成具体的业务流程就比较困难了。

如何降低抽象业务流程带来的心智负担？

首先，这个问题不可以是技术问题 ，开发人员不能因为版本2+的新方案会对运营人员产生一定的心智负担，就否定这套方案，因为从整体来看，带来收益是明显比版本1要高的，而且，心智负担的问题也并非无法解决，只是不是从技术层面去解决，而是要从业务层面去思考。

从版本1->版本2来看，对业务流程抽象所产生的负担并没有消失，只是从开发人员转移到运营人员，而且这种转移会将负担放大，因为多数开发人员比运营人员更清楚如何把业务流程抽象，在一定程度上来说，这是开发人员在研发过程中的一环。所以，如何让开发人员在跳出版本1的情况下，也能完成业务流程抽象，并提供给运营人员使用是值得考虑的问题。

我提供的方案是模板化，即由开发人员把一些常见场景的业务流程抽象成模版共享给运营人员使用，运营人员只需要填指定业务参数，或基于模版任意扩展。这样既保留了版本2+的扩展性强、业务场景覆盖广等优势；又契合版本1的开发人员对业务流程抽象，运营人员只填业务参数的流程。

Blueprint Upload（模版上传）：

Blueprint Market（蓝图市场）：

所有工具都有学习成本，越是能覆盖更多场景，学习成本就越高，开发人员能做的是尽可能的降低这个成本。

逻辑配置UI方案对比

Blocky

Blocky是一种基于图形化编程语言的编程工具，它采用了拖拽式编程模式，使得编程变得简单易懂，适合初学者或儿童使用。目前有部分低代码平台会使用Blocky作为逻辑配置的UI，它的主要特点包括：

1. 图形化编程：Blocky通过拖动和连接图形块来构建程序，避免了手写代码的繁琐和复杂性，使得编程更加直观、易懂。
2. 可视化编程：Blocky采用了可视化编程的方式，使得编程变得更加有趣和生动，适合儿童和初学者进行学习。
3. 开放性：Blocky是一种开放式编程工具，可以方便地扩展和定制，用户可以根据自己的需求添加自定义块或扩展程序功能。
4. 跨平台支持：Blocky可以在多个平台上运行，包括PC、Mac、Linux、Chromebook等，支持多种编程语言。
5. 教育应用：Blocky是一种非常适合于教育应用的编程工具，可以帮助儿童和初学者理解编程的基本概念和原理，提高编程能力和逻辑思维能力。

虽然通过可视化的方式降低了难度，但本质还是编程工具。对于开发人员来说，都有一定的学习成本，更别说运营人员，而平台的主要用户是运营人员。如果是为了实现复杂逻辑，或者本身就是非业务面向开源（如Low-Code Engine）的平台，而需要生成源码的话，那让开发人员直接写源码还快一点，个人认为属于是两边不讨好的方案。

相关链接：

Blocky：https://blockly.games/

Scratch：https://scratch.mit.edu/

表单

这类UI由输入框+按钮等表单类组件组成。通过填写表单的方式去完成逻辑配置。也是目前实现逻辑配置比较常见的一种方式。

逻辑配置的常规UI方案，开发成本低，而且开源社区有很多表单解决方案（formily、form-render）库。

一般有线性表单和嵌套表单两种的形式，线性表单上文有介绍，就不赘述了；嵌套表单是线性表单为了处理分支场景而进一步实现的方案，本质还是表单，通过层层嵌套的方式处理分支的情况。

这样做确实解决线性表单无法处理分支场景的问题，但也引入了新的问题，复杂业务场景下层层嵌套的超复杂表单的视觉体验，可能得滴眼药水才能坚持看完整个配置逻辑（如上图，这还是在没有任何其他逻辑，只有分支的情况下）。

逻辑蓝图配置效果

相关链接：

AMIS：amis - 低代码前端框架

Low-Code Engine：阿里低代码引擎 Demo

DAG

Blocky的学习成本，线性表单无法支持分支，嵌套表单处理复杂场景不友好。基于游戏开发领域的蓝图概念，所以最后选择DAG作为逻辑配置的UI方案。其他内容就不赘述了，见上文。