关于低代码:低代码平台实践系列一逻辑配置概述

背景

作为前端开发人员，大家可能曾经很相熟现有的前端框架和工具，然而随着数字化转型的推动，越来越多的企业须要更疾速、更高效地构建本人的应用程序。低代码平台能够成为咱们前端开发人员解放生产力的神器。

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

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

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 计划。其余内容就不赘述了，见上文。