低代码平台鸡肋（跟一般软件有什么区别）

与传统代码IDE不同的是，低代码开发平台提供的是更高维和易用的可视化IDE。而且我们有理由相信，随着低代码技术、产品和行业的不断成熟，这个提升倍数还能继续上涨。结合Gartner报告总结几个核心的要点：1、开发完整性提供一个低代码的IDE，来完成设计、开发、数据和部署的过程；也就是可以对应用进行“全生命周期管理”。但严格意义来讲这些产品确实不算是低代码产品，至少Gartner是进不去的。

基于经典的可视化和模型驱动理念，结合最新的云原生与多端体验技术，低代码能够在合适的业务场景下实现大幅度的提效降本，为专业开发者提供了一种全新的高生产力开发范式（Paradigm Shift）。另一方面，低代码还能让不懂代码的业务人员成为所谓的平民开发者（Citizen Developer），弥补日益扩大的专业人才缺口，同时促成业务与技术深度协作的终极敏捷形态（BizDevOps）。那什么是低代码呢？

Wikipedia定义

从Wiki的这段定义中，我们可以提炼出几个关键信息：

低代码开发平台（LCDP）本身也是一种软件，它为开发者提供了一个创建应用软件的开发环境。看到“开发环境”几个字是不是很亲切？对于程序员而言，低代码开发平台的性质与IDEA、VS等代码IDE（集成开发环境）几乎一样，都是服务于开发者的生产力工具。

与传统代码IDE不同的是，低代码开发平台提供的是更高维和易用的可视化IDE。大多数情况下，开发者并不需要使用传统的手写代码方式进行编程，而是可以通过图形化拖拽、参数配置等更高效的方式完成开发工作。

Forrester定义

顺着Wiki的描述还能发现，原来“Low-Code”一词早在2014年就由Forrester提出了，它对低代码开发平台的始祖级定义是这样的：

相比Wiki的版本，这个定义更偏向于阐明低代码所带来的核心价值：

低代码开发平台能够实现业务应用的快速交付。也就是说，不只是像传统开发平台一样“能”开发应用而已，低代码开发平台的重点是开发应用更“快”。更重要的是，这个快的程度是颠覆性的：根据Forrester在2016年的调研，大部分公司反馈低代码平台帮助他们把开发效率提升了5-10倍。而且我们有理由相信，随着低代码技术、产品和行业的不断成熟，这个提升倍数还能继续上涨。

低代码开发平台能够降低业务应用的开发成本。一方面，低代码开发在软件全生命周期流程上的投入都要更低（代码编写更少、环境设置和部署成本也更简单）；另一方面，低代码开发还显著降低了开发人员的使用门槛，非专业开发者经过简单的IT基础培训就能快速上岗，既能充分调动和利用企业现有的各方面人力资源，也能大幅降低对昂贵专业开发者资源的依赖。

低代码核心能力

基于上述的定义和分析，不难总结出如下这3条低代码开发平台的核心能力：

全栈可视化编程：可视化包含两层含义，一个是编辑时支持的点选、拖拽和配置操作，另一个是编辑完成后所及即所得（WYSIWYG）的预览效果。传统代码IDE也支持部分可视化能力（如早年Visual Studio的MFC/WPF），但低代码更强调的是全栈、端到端的可视化编程，覆盖一个完整应用开发所涉及的各个技术层面（界面/数据/逻辑）。

全生命周期管理：作为一站式的应用开发平台，低代码支持应用的完整生命周期管理，即从设计阶段开始（有些平台还支持更前置的项目与需求管理），历经开发、构建、测试和部署，一直到上线后的各种运维（e.g. 监控报警、应用上下线）和运营（e.g. 数据报表、用户反馈）。

低代码扩展能力：使用低代码开发时，大部分情况下仍离不开代码，因此平台必须能支持在必要时通过少量的代码对应用各层次进行灵活扩展，比如添加自定义组件、修改主题CSS样式、定制逻辑流动作等。一些可能的需求场景包括：UI样式定制、遗留代码复用、专用的加密算法、非标系统集成。

不只是少写代码

回到最初那个直击心灵的小白问题：Low-Code中的“Low”，到底是啥意思？答案已经显而易见：既不是指抽象程度很低（相反，低代码开发方式的抽象程度要比传统编程语言高一个level），也不是指代码很low（也相反，低代码所生成的代码一般都经过精心维护和反复测试，整体质量强于大部分手写代码），而是单纯的“少写代码” —— 只在少数需要的情况下才手写代码，其他大部分时候都能用可视化等非代码方式解决。

再往深一点儿看，低代码不只是少写代码而已：代码写得少，bug也就越少（正所谓“少做少错”），因此开发环节的两大支柱性工作“赶需求”和“修bug”就都少了；要测的代码少了，那么测试用例也可以少写不少；除了开发阶段以外，平台还覆盖了后续的应用构建、部署和管理，因此运维操作也更少了（Low-Code → Low-Ops）。

然而，少并不是最终目的：如果单纯只是想达到少的效果，砍需求减人力、降低质量要求也是一样的。低代码背后的哲学，是少即是多（Less is More），或者更准确说是多快好省（Do More with Less） —— 能力更多、上线更快、质量更好，成本还更省，深刻践行了阿里“既要，又要，还要”的价值观精髓。

国内的低代码概念，主要集中在“快速开发”和“降低门槛”上，这样很多企业软件产品基本上都能套上“低代码”的光环！

区别到底在哪儿呢？结合Gartner报告总结几个核心的要点：

1、开发完整性

提供一个低代码的IDE，来完成设计、开发、数据和部署的过程；也就是可以对应用进行“全生命周期管理”。

国内现状：提供多个SaaS产品，没有统一的IDE界面；数据开发能力相对缺乏，很多只是“表格”，甚至没有数据库的能力。

2、应用独立性（按这条多数国内产品都是“伪低代码”）

所开发出来的应用，可以不依赖原系统独立运行；（就看开发出来应用是否可以导出，单独运行？）

国内现状：多数平台所开发出来的应用，只能在平台内运行，是没有办法脱离平台，也就是说并不是可以“独立的应用”。例如：明道开发的应用无法在氚云上运行，宜搭、轻流、简道、红圈等也是如此；这些应用其实都是走的CRM和CMS“内部应用”的路子，在国外Zoho、Salesforce（Salesforce是另一款lightning App Builder被Gartner低代码收录）一开始也是这么做的。但严格意义来讲这些产品确实不算是低代码产品，至少Gartner是进不去的。

3、逻辑完备性

支持设计应用的前后台的数据逻辑和业务逻辑；（包括存储，不依赖第三方工具或平台）

国内现状：多数是支持表格逻辑，类似Excel的在线版本（其实功能赶不上Excel），而非数据库逻辑，一些后台甚至都不是采用数据库来支持。做的比较好的，支持数据库的连接和查看（取回数据），能支持控制数据库，生成SQL语句的那就凤毛麟角了。对于业务逻辑，除了两三家，几乎都是通过Blocks的方式来配置解决的，不能够直接控制编写业务逻辑，或直接生成业务逻辑代码。

4、可接入：对API支持良好，可以接入外部API，也可以提供服务API供外部接入；可接入外部多种数据库，可以显示、管理、命令控制；

国内现状：国内多数产品，都支持API的连接，这个大多数都可以支持。

5、可集成：可以集成现有前端后端的各种库、框架、SDK，能共同编译或直接使用；（例如Element UI，Echart，JDK...等）

国内现状：这个要求比较高，能够支持引入外部库的系统就不多，也基本是前端JS库为主，支持动态引入JDK好像还没有。

6、可重用：低代码本身的组件化和模块化能力，抽象再抽象，封装再封装，重用再重用。

国内现状：基本都有自身的组件系统，但是用户可以自己开发组件插入的不多；通过现有低代码开发平台，生产可重用的模块的就更少了。

特别重要——付费方式

另外，大家可以关注一下付费的方式，如果是按最终用户数来进行收费的，从模式上讲都没有摆脱SaaS的影子，也说明应用是无法完全“独立运行”的！只有按“开发者数量”收费，或“开发应用数量”收费，或云资源进行收费，才具有PaaS特征，我觉得才算是开发平台！（否则就是一个SaaS）

如果按以上能力要求，做了一个表格，大家自己看（把重点的抽象出来了）：

	IDE功能	应用完整	逻辑完备	云部署	可集成API	付费模式
Mendix	★★★★	★★★★★	★★★★	★★★★	★★★★★	按应用最终用户
iVX	★★★★★	★★★★★	★★★★★	★★★★★	★★★★	按开发者人数云资源
Power platforms	★★★	★★★	★★★★	★★★★★	★★★★	按最终用户应用数
活字格	★★★★	★★★	★★	★★★	★★★★	按最终用户并发
无远	★★★★	★★★	★★★★	无	★★★★	按组件数量
牛刀	★★★	★★★	★★	★★★	★★★★	按应用数量托管
氚云	★★★	无	★★★★	云部署无法导出	★★★	最终用户数
宜搭云	★★★	无	★★★	云部署无法导出	★★★	最终用户数
明道	★★★★	无	★★★	云部署无法导出	★★★	最终用户数
云表	★★	无	★★★★	云部署无法导出	★★★	并发模板数月数*单价
引迈信息	★★	★★★★	★★★★	无	★★★★	传统软件授权