低代码平台是什么?一文简述:低代码开发平台的分类、功能与构成

撰写这篇文章的原因在于，作为一名低代码的深度用户，笔者在日常工作中深度参与低代码相关的项目。因此，笔者希望能够清晰地阐述什么是低代码，以及低代码的组成，这不仅是对过去经验的总结，也是对未来低代码发展的畅想。

一、低代码的概念由来

低代码的由来可以追溯到软件开发的演变过程。随着信息技术的快速发展，企业对软件应用的需求不断增加，传统的手工编码方式逐渐显得效率低下，难以满足快速变化的市场需求。

如果有研究过计算机程序语言发展史的同学，应该有听闻第一代编程语言 （1GL）到最新的第六代编程语言（6GL）的蓝图，每一代升级都是生产力的提升，到了第四代其实初见“低代码”的端倪。但是还没有正真提出“低代码”这一概念。

1982 年，James Martin 在《无程序员的应用程序开发》⼀书中正式提出“低代码”。他在书中写道：“每台计算机可用的程序员数量正在迅速减少，以至于将来大多数计算机必须至少部分地在没有程序员的情况下工作“。极具前瞻性地预测了软件工程领域的发展趋势。

2014年。国际知名研究机构Forrester首先提出Low-Code (低代码)这一概念，自此低代码正式进入大众视野。

低代码概念需要借助低代码开发平台这一工具实现。维基百科将低代码平台定义为一种提供开发环境的软件，基于低代码平台开发者不需要使用传统的手写代码的方式进行编程，而是可以通过低代码平台图形化的用户界面和参数设置来创建应用软件。

低代码平台面向的用户群体是无需专业开发能力的企业业务人员和一部分专业开发人员。HR 、财务、销售等业务人员完全可以自己或者在技术 人员的指导下开发出更符合特定业务工作需求的应用程序，而专业技术人员则可通过可视化、流程化的开发方式，实现相比于纯代码模式更高效的开发。

单纯从这些公开的信息，其实也无法直观的了解啥是低代码，在笔者看来低代码不是一项具体的技术名称，它是一个技术领域的统称，是属于其中一种程序开发模式。

二、不同类型的“低代码”

2.1、按代码量的维度来分类

这个维度下，程序的开发模式可以分为三种：纯代码（Pro Code）、低代码（Low Code）、无代码（No Code）

纯代码（Pro Code）纯代码开发是指使用传统编程语言（如Java、Python、C#等）进行软件开发的方式。开发者需要具备编程技能，能够手动编写代码来实现功能。它的特点具有：灵活性 - 开发者可以完全控制代码的每一个细节，能够实现复杂的业务逻辑和功能；可扩展性 - 可以根据需求进行高度定制，适合大型和复杂的项目；学习曲线 - 需要较高的技术门槛，开发者需要掌握编程语言、框架和工具；维护性 - 代码的可读性和可维护性依赖于开发者的编码习惯和团队的规范。Pro Code 和 No Code 实际上都很好理解，一个是纯代码，一个是无代码。假设 Pro Code 的代码量是 100，那 No Code 就是 0，所以 Pro Code 和 No Code 是截然不同的，甚至你可以认为这两者毫无关系。No Code 的最典型形态莫过于 SaaS 类的产品了。

低代码跟无代码概念容易混淆，如果按照公式来表达的话:

C，Configuration in graphical，图形化配置，这是大家对低代码最直观的认知部分。通过各类常规的UI手段，如窗口、对话框、文本框、下拉框等编辑器等UI交互形式引导用户表达信息。

A，Arrangement in graphical，图形化编排，基于图元或其他形式的节点信息，通过连接、排布等方式表达流程、时序等信息。

T，Textual DSL，文本型的DSL，借助某种文本化形式的特定领域语言做描述表达，可能为表达式或其他计算机语言，一般谈“低代码”中的代码指的主要是这部分内容。

低代码的构成公式

Low-Code（低代码） = 50% C + 5% A + 45% T

无代码的构成公式

Low-Code（无代码） = 50% C + 45% A + 5% T

严格来说，把采用无代码模式生成程序的过程称为开发是不恰当的，因为它只是对已有原子业务能力进行二次组合，形成具有特定功能的新业务而已。因此从这个角度来说，低代码和无代码完全不是一种东西，切不可将这两者混为一谈。

但有一个情况非常容易混淆低代码和无代码。当低代码的成熟度到一定高度时，在某些细分场合下也可以实现零代码开发。在这个情况下，从程序开发过程的表现看，这二者差异微小，此时最容易将两者混淆。当然，我们也不排除一些低代码解决方案提供商为了夸大其低代码的效果，故意将二者混为一谈，把无代码当作一个噱头来宣传。实际上，低代码模式要将一个场景做到零代码，难度非常大，并且有诸多业务前提。

Low Code 是采用无逻辑的结构化数据来描述业务的，对于相同业务，Low Code 的描述能力要弱于有逻辑的 Pro Code。所以，Pro Code 都做不到的事情，Low Code 当然也做不到。如何有效解决强逻辑场合下的可视化配置方法，这是 Low Code 采用无逻辑的结构化数据描述业务常见的重要短板。

2.2、按适用范围的维度来分类

低代码平台可以分为专用型和通用型两种

所谓通用，指的是开发平台不事先假设自身只能应用在特定的场景、业务、行业，而是具有广泛的适用范围。具有这样特征的开发平台往往需要有一个通用的底座。这个底座是纯技术性的，它不依赖于特定的业务功能，而只与业界广泛使用的标准协议、技术标准产生耦合。不过，这个时候，我们只有深入平台架构实现的细节，才能判断平台到底是低代码还是无代码，这就导致平台的使用者难以甄别。

但是，通用是有代价的，越通用就往往意味着在特定业务场景下的效率越低，越通用就意味着默认配置里的个性化信息越少，为形成某个具体场景所需的配置量就越大，从这个具体场景的角度看，效率相应也就越低。

所以通用型的低代码平台往往伴生着这个特征：有相对完善的有插件（或类似）机制。这一点相对来说比较好识别，相对高通用性的技术底座来说，插件是廉价的，因此通用性低代码平台往往会有数量众多的插件。这些插件可以定制出各式各样具体的业务场景，通过插件的定制化和扩展性来解决效率问题。

2.3、按业务类型来分类

其实，在一个具有较高通用适用范围的低代码平台来说，按照业务类型分类几乎是没有意义的。之所以不得不按输出程序类型分类，是因为开发平台的通用性不足，而在有了足够高的通用适用性之后，支持开发各种类型 App 的问题，就不在于能不能了，而只是时间问题。

按照业务类型区分大概有流程驱动型、表单驱动型、模型驱动（ORM）型、BI 分析、组件驱动类型这几种，具体你可以看看这张表格（5 星为满分）：

这里，主要区分一下表单驱动型和模型驱动型这两个类型，因为它们比较容易混淆。

所谓模型驱动型 App，它的模型指的是数据模型，或是数据关系。而这里所说的关系，指的就是符合三范式的关系型数据库的关系，也就是你数据库中各个数据表之间的关系，比如表 1 的 a 字段和表 2 的 a 字段是相同的，但与表 3 中的 a 字段没有关系。在正确配置了各种数据关系之后（这个过程一般称为数据建模），页面上就可以很容易创建各种 CRUD（增删改查）类页面了。

表单类页面则是仅以数据为中心，创造各种表单来收集或呈现数据。这里的关键点在于，这类页面并不关注数据之间的关系。所以表单类的页面非常容易形成数据孤岛，并存在大量冗余数据，以及大量数据不一致性等问题。如果我们将表单类页面做得比较完善的话，实际上它就会逐渐转型成模型驱动类页面了。在完成数据建模之后，我们就分不清楚它到底是模型驱动还是表单驱动了，差异只是前端是用表单展示，还是表格展示而已。

2.4、按使用者的类型来分类

如果按照使用者的类型进行分类，我们可以将开发平台的使用者分为 3 类：专业技术人员，业务技术员，相关无专业技能人员。

这里所说的业务技术员是一种正在兴起的角色，它是指构建供内部和外部业务使用的技术或分析功能的非 IT 部门员工。他们担任着装备和赋能非 IT 资源以构建数字化能力的战略角色。

多数的无代码开发平台将业务技术员作为主要的用户群，为他们提供对已有业务的二次组合为主的基础开发能力，一般具有专业技能的开发人员是不会使用无代码开发平台的，因为专业技能者要面对的问题域已经大大超出了无代码平台的能力范围。

而低代码开发平台一般会将专业技术人员和业务技术员同时作为他们的客户群，并以专业技术人员为主要用户群，业务技术员为次要用户群。

随着低代码开发平台的成熟度上升，业务技术员用户群的占比会有所上升。因为成熟度高的低代码平台，不仅有各式各样的可视化工具来降低业务研发的难度和代码量，同时对业务研发生命周期各个环节的覆盖也会越来越完整。从开发到测试，从测试到上线，再到高容错运行时自动化部署 / 恢复、运行时自动化运维等各个环节的可视化、自动化完成，这为无 IT 技能的业务技术员独立开发提供了可能性。同时，越发完善的可视化自动化能力不仅会牢牢抓住已有的专业技能用户，还会吸引更多的专业技能用户的加入。

纯代码到无代码甚至自驱式的开发，对平台的成熟度要求越来越高，同时也能降低使用者的门槛。

总结以上分类，我们的大致脉络图如下：

总体而言，其实低代码没有定性的分类，除了这些分类，其实也可以按照其它维度进行分类，这样分类只是让读者能更加清楚低代码包含的领域，有些客观上的认知。

三、低代码的构成

讲这块内容的时候，我们通过三个典型的公开可接触到的平台进行举例，分别是：阿里低代码平台、织信低代码平台、魔方低代码平台。

3.1、阿里低代码平台

按照阿里低代码白皮书的描述，低代码的架构构成自下而上分别是协议 - 引擎 - 生态 - 平台

底层协议栈定义的是标准，标准的统一让上层产物的互通成为可能。

引擎是对协议的实现，同时通过能力的输出，向上支撑生态开放体系，提供各种生态扩展能力。

生态就好理解了，是基于引擎核心能力上扩展出来的，比如物料、设置器、插件等，还有工具链支撑开发体系。

最后，各个平台基于引擎内核以及生态中的产品组合、衔接形成满足其需求的低代码平台。

每一层都明确自身的定位，各司其职，协议不会去思考引擎如何实现，引擎也不会实现具体上层平台功能，上层平台的定制化均通过插件来实现。

官方也提供了核心编辑器的架构图：

3.2、织信低代码

走了另一条截然不同的道路，从数据源开始，做表单配置映射，再到可视化拖拽，由数据模型驱动。虽然没有从底层开始就定义协议，但是它由强大的数据基底作为架构基石，再迭代到更灵活的可视化拖拽，也很自然且平稳。而且由于数据源有足够沉淀的基底，所以它在数据模型这块能处理的事情会更多，除了简单的数据CRUD，链表查询，事务处理，自定义查询、复杂业务逻辑设计等能力在众多低代码平台的设计中也是比较靠前的。所以它能支撑的业务场景能更加复杂，且更加灵活。

但是作为偏科toB的平台，在交互动画方面相对就比较薄弱，且为了兼容大量的内置事件以及数据联动，它也牺牲了部分性能。所以回过头来，我们在看看C端活动平台的低代码架构设计。

3.3、MOKA低代码

Moka低码活动平台是基于魔方编辑器进行二次开发改造，而魔方编辑器官方提供的能力其实没有代码生成器这一说法，它的编辑产物是定义的DSL，再通过DSL生成页面配置描述文件，最后描述文件给到固定的runtime版本进行渲染。我们团队进行移植后，增加了独立的代码生成模块，能够将页面的整体体积进一步缩小，减少冗余的依赖。但其实做得还不够，如果按照理想中编辑器跟代码生成器的四个等级进行划分。

代码生成器与编辑器之间的关系，可以大致分为这几个层次：

Level 1：没有代码生成器的概念，或者极其粗糙；

Level 2：有相对独立的模块用于生成代码，但该模块与编辑器耦合严重；

Level 3：代码生成器与编辑器基本相互独立，具有同等地位；

Level 4：插件系统与生态，编译器必须再次抽象才能实现插件系统。

目前魔方处于Level1阶段，还有很大的进步空间。笔者所处团队通过结合织信与阿里低码的出码模块，已经对内部版本支持升级改造到Level2。但是距离Level3跟Level4依旧有不小的差距。

四、朴素的程序开发三步骤

看完以上这些在各个业务领域比较有典型的低代码组成架构，其实也不难发现，低代码平台的构成其实没有明确的定义，如果真的要确定必要构成的元素，可以回归到程序设计的最朴素的三大步奏：布局、交互、数据

4.1、布局

布局就是按照 UI 设计稿或需求说明书里的草图，把需要的组件逐个放到界面上，并按照要求排列整齐，形成程序雏形的过程。Pro Code 开发模式下的布局过程是极抽象的过程，开发人员需要把形象化的 UI 设计稿转换为一行行抽象的指令，同时在脑海里想象这些指令的渲染效果。而在低代码模式下，布局过程是非常形象的过程。我们可以利用低代码编辑器的布局器，通过画布上的拖拉拽，可视化地完成这一过程。而且，由于新手初次尝试低代码开发所做的事儿就是布局，所以拖拉拽往往成了大家对低代码模式的第一印象。我们知道，不同类型的 程序，布局方式迥异，即使相同的程序在不同开发阶段也有不同的布局需求。笔者认为布局器最主要需要满足两方面的诉求，一是通用性，二是效率。

通用性是我们在低代码编辑器研发早期主要关注的维度，随着低代码编辑器越发成熟，对效率的追求就逐渐超越了对通用性的追求。

流式布局器和绝对布局器都具有很好的通用性。但在布局初始阶段，显然采用流水的方式效率高，而在布局的后期，使用绝对布局器进行精细化布局的效率更高。那么，我们将这两种布局方式组合使用，就可以得到一个既高效又通用的布局器了。

组合听似简单，实际上非常依赖协议的实现。目前比较好的方式实现各种布局器的相互嵌套使用。可以将布局器包装成了一种容器。容器也是一种组件，它具有组件的任何特性，但具备一个普通组件没有的能力：它能装得下其他组件或容器。目前市面上绝大部分低代码其实都兼容该方式的做法。

4.2、交互

可视化编程解决的是应用开发三部曲（布局、交互、数据）中的交互环节，简单的交互可以理解为组件跟组件间的联动，组件跟业务逻辑的联动。常见的方式可以通过事件驱动，为UI组件设置事件（如点击、悬停、输入等），并定义在这些事件发生时要执行的操作。例如，点击按钮后可以触发数据提交或页面跳转。条件逻辑根据用户的输入或选择来决定后续的操作。例如，用户选择某个选项后，可以显示或隐藏特定的UI组件。这些都是基于组件级别的交互，那如果是逻辑层的交互如何做呢？

可视化逻辑编排，编码时的流程逻辑是通过一行行代码自上而下来体现，可视化逻辑编排需要对逻辑有不同的组织方式。一种比较常见的逻辑可视化组织方式是流程图，通过流程图的形式来表达一个逻辑过程是非常自然的想法。

下面这个流程图，描述了一个订单审批的过程，看上去逻辑是比较清晰的：

简单的流程图里包含了代码逻辑的三种基本控制结构：循环结构、选择结构、顺序结构，并且这三种结构在图中的呈现和融合都非常自然。关键是，BOHM & Jacopini 早在 1966 年就从理论上证明了，只要能同时支持这 3 种结构的流程，就可以表达任何复杂的程序逻辑。

通过可视化逻辑编排，实际上生成的代码可能如下所示：

function f() {

// ...
if (xxx) {
    return 1;
}
// ...
if (yyy) {
    return 2;
}
// ...
if (zzz) {
    return 3;
}
// ...
return 4;

}

4.3、数据

程序开发中还有一个重要的环节，组件如何获取和渲染数据。信息采集，就是要定义一个收集开发者配置信息的视图。获取数据的各个动作，需要采集的信息都大不相同，不同的个性化数据需要采集的信息也各不一样。因此，在基础动作中，这部分是抽象的，我们无法知晓具体该绘制啥样的 UI，但可以约束具体动作采用什么方法来绘制 UI。

子类可以将处理 UI 的所有逻辑，都封装到动态渲染器中。信息保存是可以在基础动作中直接实现的，只需要在基类中提供读写数据的 API 给子类使用即可。

五、更好的低代码平台

最后讲讲如何做一个好的低代码平台，兜底能力也是很重要的。低代码平台不可能面面俱到，它总有能力边界，但这个能力边界不能束缚业务团队的探索。业务需要紧随市场甚至引领市场，而市场是千变万化的，任何公司都无法决定，所以要把“业务提出低代码平台能力之外的需求”当做一种常态。此时，低代码平台需要有一种策略帮助应用快速实现需求，哪怕直接上手编码乃至 Hack。这样的策略就是兜底策略。

即使在低代码平台成熟之后，使用纯代码作为一种兜底策略，依然是一种非常好的选择。因为任何事情都逃脱不了二八原则，低代码的可视化模式再好，也只能适用于 80% 的场景。剩余的那 20% 边边角角的场景，如果硬上可视化模式，反而可能吃力不讨好，所以我们把那剩下的 20% 的场景留给纯代码来兜底，是一种很明智的选择。

此外还有一些增值功能，包括 UI 设计规范自动对齐、提供 UI 设计稿转代码（D2C）能力、页面的可维护性、页面的埋点 & 数据采集、程序的开源合规治理、程序的安全漏洞治理、程序的性能等等。简单来说，这些都是低代码平台的亮点能力，并且是拉开与 Pro Code 差距的重要能力。

最后总结，所有的平台也好，技术也好，其实都是服务于人，没有完美的工具，也没有解决不了的问题。

如果大家觉得文章还不错，欢迎点赞、转发、收藏、关注，这是对小编的最大支持和鼓励，鼓励我们持续产出优质内容。