我查看了几乎所有的介绍低代码的总结和分析报告，几乎…（低代码有哪些缺点）

我查看了几乎所有的介绍低代码的总结和分析报告，几乎都没有把低代码最底层的产品逻辑说清楚。今天我尝试不用复杂的技术名词，也不用代码，把这个事儿给大家说明白，低代码到底怎么回事儿！（人云亦云那些，我就统统省略了，我们直击最底层的逻辑，这种分析产品和技术的方式应该也是通用的。）

低代码给谁用的？

三类人群：

一、开发者/程序员：（或者更广义的开发者）核心开发应用或程序的逻辑和写代码并无差别。（程序逻辑就是程序逻辑，没有第二种逻辑可言了）

逻辑要求能力：强

开发的方式：鼠标点击、连线、拖拽、配置

（低代码和“代码的关系”最好是“代码都可以用，不用代码都可以做出来”）

二、业务编辑人员：就是设计各种工作流、各种表单、各种图表的人员，只需要知道业务逻辑，怎么操作就可以了，不太需要“程序逻辑”，而对业务本身理解较深。

逻辑要求能力：中

开发的方式：鼠标点击、连线、拖拽、配置

三、业务使用人员：（即业务最终的用户）例如需要填写表单、做审批/评价、填写记录…总之就是最终去使用“业务配置人员”配置好的界面及相关功能的用户。

逻辑要求能力：低

开发的方式：鼠标点击、连线、拖拽、配置

三种状态

一、开发态：（区别于“运行时”的状态）怎么去理解开发态呢？我举两个例子，例如操作系统Windows，开发Windows代码设计整个系统的时候，就是开发态，成千上万的工程师都在写代码和调试，然后编译成Windows系统软件，而最终你购买电脑之后，开机，进入Windows系统桌面，这个时候就是运行时了。例外一个例子，你身上的DNA可以理解为开发态，你的大脑可以理解为运行时…。开发态代表什么都可以修改，灵活性较高；而运行时，一些部分已经固化，就不太容易修改了。

二、运行时—业务编辑态：这种状态对应上面的“业务编辑人员”，即“业务编辑人员”使用“编辑器或设计器”的这个过程。

三、运行时—业务运行态：这种状态对应上面的“业务使用人员”，这个我就不再重复介绍了，几乎所有的低代码平台对这部分的使用都是一致的，从上面的图也可以看。

低代码平台之间核心差异

有了前面的“三类人群”和“三种状态（实际上低代码产品只能在前面两种状态里面产生）”，把现有的所有低代码平台往里面去放就可以了。（直接查看附图）

而且你会发现一些有趣的事情：

在“开发态”做产品，一个核心体现就是“生成代码”！这种方式通常是比较难的，通常需要“中间语言DDL/编辑器/解释器”等，需要“图形化逻辑表达”，研发的周期往往也比较长（短时间内做不出什么好东西的）。

把“开发者”和“业务编辑人员”放在一个产品下面（传统的Mendix Outsystems CodeWave等的做法），不管是放在“开发态”或者是“运行时—业务编辑态”，都是一个比较尴尬的事情，一方面要设计多个设计器给不同的人员去使用（也是多个设计存在的原因），另一方面把“两波完全不同的人”放在一个产品下，通常两边都不讨好。“开发者觉得不方便，操作麻烦”，“业务编辑人员觉得看不懂，太多代码相关背景知识”。（从上图可以看出，有一些产品，直接取消了“开发者”，就和SaaS类似。）

iVX并没有设计多套“编辑器”，而是一个“IDE”，更像是“图形化编程语言”的思路，也不用把“开发者”和“业务编辑人员”放在一套产品下面。

一些大平台，直接把“低代码”做成了自身生态的快速粘合剂或“快速开发工具/设计器”，例如宜搭、PowerPlatform等，也是一种思路，但是必须要平台足够大才行。

另外，我想说的是，一个工具是否好用，技术最多占一半，另外的一半是产品！而且最终是否为用户带来效率，是否用着爽，可能才是成功与否的关键。#编程经验# #低代码# #快速开发# #代码生成#