低代码格局和来龙去脉
低代码产品来源主要有三个渠道，如果不算广义的CRM、ERP系产品（Wix、WordPress、Odoo…这些），这些产品构成了现在低代码的主要格局。
渠道一：从MADP/MXDP演进而来：
MADP代表“移动应用开发平台”，其实就是做原生APP可视化开发的平台；MXDP代表“混合多体验开发平台”，实际上就是在移动原生APP开发平台基础上增加了对Web App的支持。现在有了GPT，我直接把GPT4的描述写在下面，大家就很清楚了。
大家会发现最主要的厂商都在上面… Mendix Outsystems PowerApps 等。
这类低代码产品的特定也非常清晰：多数做企业服务（会有一套完整系统安装到企业内部），有相对复杂的IDE，功能上也相对比较完整，研发的周期也比较长，大部分都在10年以上。这类型产品，主要其实也是给研发人员使用的，或者他们叫“CitizenDeveloper”，但是真正的业务人员很难学会。
渠道二：之前做“SaaS”、“BPM”以及“Bi”为主的厂商
这里面比较有名的是 ZoHo Creator、Salesforce、Airtable、AppShee、Appian 、Tableau、PowerBi等，国内有很多厂商都是从这个领域介入低代码研发的。这类型演变过来的低代码产品，往往场景比较明确（主要是“BI场景”、“工作流BPM场景”、“在线表格场景”、“在线表单场景”这四种），通常是多个“引擎”和“模型”驱动的，基本都可以给业务人员直接使用，感觉上就像是很多SaaS 用户 权限管理，开发全新场景时，灵活性会受到一些限制。
渠道三：也是重点想介绍的——代码生成平台
这类平台国内比较少，而且主要专注于“通用程序开发”，是一种底层通用技术（上面提到的更倾向于“应用开发框架”），因此也不会限制只用于“企业服务”。
国外的代码生成平台主要包括以下这些：
前端代码生成平台：WebFlow Wappler PineGrow ReactStudio
后端代码生成平台：Backendless Firebase (by Google) Stapi
数据库代码生成平台：Prisma DbDesigner SQLDBM QuickDBD
具有统一的前后台代码生成能力的就比较少了，主要有： Bubble Appgyver (By SAP) Retool ，国内就只有 iVX 一家。
有了这些基础知识，那下面介绍起来就比较轻松了。接下来….
如何评价低代码平台？
我列出了最核心的三项，以及我觉得重要的评分项，供大家参考。
核心能力一：功能和性能 ？（详细见后面列表）
（大白话就是：不写代码能做什么？做得怎么样？）这个重要性不言而喻，有些低代码平台说自己“接代码”什么都能实现，这句话当没说。核心还是一句，不写代码能做什么！这个地方我觉得可以补充一下，就是“低代码编程”和“代码编程”的关系，我们觉得最佳实践就是“充分非必要！”，即“什么代码都可以用，但是不用也都行”。
核心能力二：是否锁定 ？
我先解释一下，什么叫不锁定？最佳状态就是“和手写代码一个样”，最好“调试方式和代码管理”都可以继承。这里面分几个层面：例如“低代码平台”生成的代码可以被现有的代码形式“直接接受”，意味着原有的开发项目直接可以以插入的方式使用。另外，以前端为例，可以直接在低代码平台中直接导入以前开发“组件或代码”那是更好。其实开发者不一定需要在“二开”的时候，直接修改“低代码平台”导出的源代码（如果可以导出），而是需要这种“修改的能力”！这是一种“安全感”，这一点其实非常重要，当然难度也是最大的。
坦率的讲，想在绝大多数的低代码平台都存在锁定用户的问题，即无法实现“应用代码导出和独立部署”，有些是可以打包导出一个加壳文件，最后还是要导入到特定环境中运行的。大概如下图所示：
情形一：所有应用都在框架内部，无法导出独立部署
情形二：应用可以导出，例如导出成 mpk或osp文件，但是只能导入到自身平台环境运行
核心能力三：产品整合能力 ？
我研究过很多低代码产品，很多产品从“开源”魔改而来，“功能堆叠和拼接感”严重，看上去吧好像这个也有，那个也支持，但是用起来完全不是那么一会事儿。说白了就是“其实开发一个应用有可能比写代码还费劲”。从一个侧面反映就是，窗口数量众多、操作层级特别深、逻辑和管理混乱，有些逻辑控制甚至有多个入口。道理其实也很简单，现在无论大厂小厂要开发一个产品时，先就找对应的开源产品和框架，然后开始组装和拼接，但是其实开源产品可能设计初衷并不是为了“低代码”，而且拼接越多，整个产品就越笨重，越难以驾驭。
以下是我总结的低代码产品的基本评分项，并以 iVX 为例进行了描述。有什么新的评分项，大家还可以补充，我们不整虚的，行就是行，不行就是不行，希望低代码生态可以越来越健康。
低代码能力评分项（详细版，附带iVX评价结果）
|
评价项 | 评价说明 | iVX产品评价结果 |
平台会锁定用户吗？ | 分几种情况：1. 直接生成外部环境可以运行源代码，无锁定；2. 生成只能在平台内部环境运行的应用，锁定；3. 平台生成应用，应用可以以某种平台特定格式导出，但是必须在平台环境才能导入，为部分锁定。例如mendix/outsystems 就输入部分锁定。Power Apps也只能在Azure中运行也是这种部分锁定。 | 可以完整导出前端、后台、数据库代码，可以在任何环境运行，无锁定 |
平台收费方式？ | 分几种情况或组合：1. 平台免费，使用使用云计算服务时，收取云计算费用；2. 根据最终应用的用户数量进行收费；例如一个应用最终是100人还是100万人，价格差距很大；这种往往是上面提到的“锁定”或“部分锁定”模式造成的；3. 根据开发者数量进行收费；4. 根据开发的应用数量和类型进行收费； | IDE和平台免费，如果使用到了云计算，云计算收费；如果不使用云计算，应用可以免费导出平台，自行部署； |
支持整个平台支持对外部署？ | 这里不是指平台内部应用导出部署，而是说整个平台在公网或局域网内部部署 | 支持 |
应用导出支持的部署方式？ | 例如包括：单机部署（Linux/Windows）、云端虚拟机部署、Docker K8S部署 | 都支持 |
是否支持导出应用一键部署？ | 例如会帮用户安装MySQL和redis如果用户服务器或虚拟设备上没有安装，然后一键完成部署，只需要填写一些IP 用户名和密码等 | 支持一键部署 |
对ARM或国产芯片/麒麟系统支持？ | 整个平台支持ARM环境？生成的应用支持ARM环境？整个平台支持在麒麟等国产系统中部署？生成应用支持在过程麒麟等系统中部署？ | 全部都支持 |
平台或工具/IDE的开发环境？ | 是Web环境的B/S架构，还是C/S架构的产品？ | B/S架构 |
平台使用者一定要会某种代码吗？ | 对于绝大多数应用来说，由于平台描述逻辑方式的限制，或者没有完备描述前后台逻辑的方法，因此，必须引入代码。或者由于组件不完备，必须引入代码。 | 无需懂代码 |
如果要懂代码，平台需要懂哪种代码？ | 一般包括SQL、JS（包括框架react/vue等一种）、Java、Python、Node.js、PHP、.net代码 | 一种都不是必须的 |
开发者使用平台能生成大概代码比例？ | 主要根据平台“无代码逻辑表达能力”以及“组件多少和架构”来确定，例如，如果前后台都需要大量代码的，工具或IDE只是辅助，那么生成代码量一般小于30%；如果需要输入代码不多，但是一定需要代码才能完成的，一般代码量在60～70%，如果完全不需要代码，大部分应用都可以完成的，自动生成代码量可以大于95%。 | 通常生成代码超过应用总代码量95%； iVX和代码关系为“充分非必要” |
平台能够支持的开发的应用类型？ | 包括其中一种或几种：WebApp、iOS/Android原生应用、Win/Mac/Linux原生应用、微信小程序、或Google或FB平台内的应用格式 | 支持WebApp、iOS/Android原生应用、Win/Mac/Linux原生应用、微信小程序 |
平台支持的应用的场景有哪些？ | 包括：1. 全场景，无论个人应用还是B端应用，无论游戏、电商、各种企业场景、iot、各类系统都可以开发；类似编程语言，本身没有什么限制；2. 主要支持BI场景（根据数据作图）、在线表单场景（用于快速填写，快速提交）、在线表格场景（类似在线的excel或Google sheet）、BPM（流程图、审批流场景），用户可以根据这些场景再延伸，以及做近似的二次开发，产生新的相似应用或场景；3. 主要支持BI场景（根据数据作图）、在线表单场景（用于快速填写，快速提交）、在线表格场景（类似在线的excel或Google sheet）、BPM（流程图、审批流场景），但是就是给业务人员使用的，操作和使用更简单，但是灵活性较差。 | 1. 全场景 |
支持应用或生成代码的范围？ | 1. 生成整个应用，以及全部代码；2. 生成整个应用，不生成代码；3. 生成整个应用，生成部分代码或生成代码不能脱离平台；4. 只生部分代码，例如只生成前端/后台/数据库中一部分，不能单独使用； | 1. 生成整个应用，以及全部代码 |
代码逻辑可视化的方式？ | 现阶段大体分5种：1. 流程图模式，类似mendix/outsystems这样的要化流程图的；2. Scratch模式，就像Scratch一样，一块块积木，拼接出来表达逻辑；3. iVX模式，事件面板模式，是一个面板，有一点像construct2/3，但是设计更好，全部都是数据点选，所有组件都面向对象设计，可以在事件面板中操作，也可以加“if” “for” “function” 等事件块，完成整个逻辑表达，且是图灵完备的；4. 公式表达式模式：例如Power Apps采用类似Excel的公式表达式来表达逻辑；5. 函数式模式，例如SAP的Appgyver，把函数的出参和入参用线连起来表达逻辑。 | 3. iVX的事件面板模式 |
组件的架构？ | 具体包括：组件一层架构还是多层架构？例如iVX就有3层组件架构，以平衡灵活和效率；是否区分了前台和后台组件？ | iVX三层组件架构：微组件（不可见）、基础组件（100 ）、小模块（1000 ）；前后台组件分离 |
组件是否支持自定义组件？ | 支持自定义前端组件？支持自定义后台或数据组件？ | 前后台都支持自定义组件 |
是否用word/excel/ppt兼容的组件？ | 主要是为了在企业办公中可以整合现有离线文档 | 全部都有 |
支持前后台的API组件或方法？ | API是一种基础的应用内部和系统直接提供服务的方法，对现有系统的整合至关重要 | 通过前后台API组件支持 |
支持Socket方法？ | 例如支持websocket | 通过Socket组件支持 |
组件中是否有变量组件？ | 变量作为组件可以充分保证逻辑实现的灵活性，有了变量组件可以跟接近编程语言体验 | 有 |
前端采用什么框架？ | vue、react、bootstrap、jquery、自研框架等，例如iVX使用自研框架类似vue结构效率和react相当；例如牛刀低代码使用WeX5框架； | 自研框架，类vue，很容易看懂生成代码 |
前端是否支持自定义CSS？自定义JS函数？ | 在IDE中，前端可以插入JS函数和自定义CSS样式 | 都支持 |
前端生成的代码可以在什么框架下重用？ | 前端生成的代码时候可以在老的系统中重用，作为其中一个部分。例如iVX可以生成支持vue和react的component，并嵌入到原有的vue/react项目中进行使用。 | 可以在vue/react中作为component使用 |
前端是否支持原有组件？ | 例如前端可以导出vue或react组件，包括AntD elementUI或自有组件 | 支持全部react组件导入 |
前端是否支持响应式布局？ | 拖拽之后，内容会跟随改变，例如可以同时支持手机和PC浏览，一次开发 | 支持 |
是否支持绝对定位和相对定位？ | 一般绝对定位在动画或游戏界面中常用，而相对定位在应用和网页设计中常用 | 都支持 |
所有后台资源直接使用云计算厂商服务？（即serverless支持？） | 即实现平台只生成后台代码本身，和运行时需要后台资源解耦，并发、数据、安全、存储由云计算产品来负责。 | 完全解耦，直接可以连云计算厂商产品； |
对接的云计算厂商产品是否有开源产品对应？ | 目的是：不要被云计算厂商锁定，如果所有产品都有开源产品对应的话。 | 所有产品都有对应的开源产品，可以在任何云或私有环境部署导出应用 |
后台支持哪些语言代码生成？ | 一般包括其中一种或几种：Java、C#、Node.js、PHP、Go、WASM等 | Java和Node.js |
支持哪些语言的SDK上传？ | 为了更好支持对原有代码的集成，最好能支持SDK上传 | 支持 Java/Node/Android/Javascript SDK 上传 |
支持微服务？ | 一切为了重用和管理，微服务是重要的手段 | 支持微服务 |
支持数据库情况？ | mysql/SQL server/PostgreSQL/Redis/ClickHouse/neo4j/Mongo DB/ES/MQ/国产数据库 | 全部支持 |
数据库支持能力如何？ | 是否支持数据库常见功能，例如：索引、join、事物、存储过程（存储过程基本都建议不用） | 支持索引、join、事物 |
支持RBAC进行用户访问和权限管理？ | RBAC是基于角色的访问控制，是一种访问控制方法，可根据最终用户在组织中的角色为其分配权限。RBAC提供了细粒度的控制，提供了一种简单、可管理的访问管理方法，与单独分配权限相比，这种方法更不容易出错。这可以降低网络安全风险，保护敏感数据，并确保员工只能访问信息并执行他们完成工作所需的操作。这被称为最小特权原则。RBAC的实现方法包括：定义角色、定义权限、将角色分配给用户、将权限分配给角色、将用户分配给角色。 | 支持 |
支持权限管理和控制？ | 通常包括以下部分一种或几种：1. 数据库字段用户访问权限和控制；2. 微服务用户访问权限和控制；3. 前端显示和操作的用户访问权限和控制；4. 对数据表行进行访问控制管理；（4这条好像只有活字格产品支持了，但是好像并没有必要，开销很大） | 支持1、2、3三种情况； |
支持各种数据传输加密？ | 加密方式为传输加密或提供加密组件（可以配置加密方法） | 默认传输加密和加密组件都提供 |
前端防注入和SQL防注入？ | 防止SQL注入：使用预编译语句、使用存储过程、使用参数化查询、对输入进行过滤和验证、限制用户输入长度、限制用户输入类型等。防止JS注入：对用户输入进行过滤和验证、使用转义字符、使用正则表达式等。 | 都严格检查 |
是否有详细的后台日志生成？ | 后台日志主要用来记录和Debug后台的程序和服务 | 有非常详细，而且是可视化的 |
支持多人开发和版本管理？ | 多人开发，例如Git类似的开发机制 | 支持多人同时开发，和各种形式的无限版本管理 |
整理撰写不易，希望对大家加深对低代码平台的理解，以及对开发低代码平台的同学有帮助。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。