“ The future of coding is no coding at all.” —— Chris Wanstrath (Former CEO of GitHub)

第一部分：基本概念

no-code、low-code 和 pro-code

基本概念：

• Pro Code：纯代码
• Low Code：低代码
• No Code：无代码
• LCAP：Low-Code Application Platform，低代码应用平台
• LCDP：Low-Code Development Platform，低代码开发平台
• HPAPaaS：High-Productivity Application Platform as a Service，高生产力PaaS平台

在低代码概念引入之前，我们先看看纯代码（Pro Code）。

在日常的开发过程中，绝大多数的编程都是手写全部的代码，也就是大家常说的“纯代码”（Pro Code），要实现某一个功能，需要写全部的代码。有没有一种方法可以避免如 程序员门槛高、文档链路长、研发效率不够高 等问题呢？

于是，可视化编程开始发光发热。可视化编程，就是可视化程序设计，通过少写代码，或者不写代码通过拖拽的方式生成。可视化编程的特点就是所见即所得、一站式研发、技术收敛，而且专业门槛低，对程序员小白相对友好。

关于可视化编程，主要分为两类，一是无代码，另外一个是低代码。

Low Code 与 No Code的关系区分

网上一搜索“低代码”相关的定义特别多，维基百科定义：低代码开发平台（LCAP）本身也是一种软件，它为开发者提供了一个创建应用软件的开发环境；与传统编写代码的 IDE 不同，低代码开发平台提供更简单易用的可视化 IDE。

在2019年的Gartner的Low-Code报告「《Magic Quadrant for Enterprise Low-Code Application Platforms》」中，低代码平台被称为企业级低代码应用平台（Enterprise Low-Code Application Platform，Enterprise LCAP），是支持快速应用开发，使用陈述性、高级的编程抽象（如基于模型驱动和元数据编程语言）实现一站式应用部署、执行和管理的应用平台，不同于传统的应用平台，它支持用户界面、业务逻辑和数据服务的开发，并以牺牲跨平台的可移植性、应用开放性为代价来提高生产效率。

简单来讲，低代码（Low Code）就是一种可视化搭建系统，从字面意思来讲，一是可视化，二是少写代码。无代码（No Code）同样从字面上来理解，一是可视化，二是不写代码。

No Code 和 Low Code 这两种的区别是，No Code 的是完全不需要写代码，而 Low Code 是需要写部分代码，整体通过拖拽的方式生成。

既然Low Code、No Code 这么方便，我是不是直接用它就好了，还写什么代码？

其实，不是这样的。虽然 Pro Code 有前文提到的缺点，但是它也有 Low Code、No Code 暂时无法取代的优点。Pro Code 的优势在于表达更精准、在封装的基础上更好的实现提效、更好的满足平台间的兼容性、更快的版本迭代；另外一方面，可视化搭建的场景只能覆盖解决一部分的对代码能力要求不是那么高的业务研发场景，有一些能力是配置不出来的，并不能完全取代Pro Code。总之，Pro Code、Low Code、No Code 之间不是替代消灭关系，⽽是互补加强关系。

同样的在Gartner的报告中，也对Low-Code和No-Code的关系进行了相对准确的解读：

Gartner has covered low-code development for mobile apps used in the workplace under rapid mobile app development (RMAD) tools (see “Market Guide for Rapid Mobile App Development Tools”). We have also observed that no-code development tools are being marketed toward lines of business as a way for them to own their data applications. The idea is to “democratize” application development by enabling and facilitating citizen development (see “Citizen Development Success Depends on an Equal Partnership Between Business and IT Leaders”).However, the no-code tools targeted at minimally skilled citizen developers often end up requiring trained IT staff for certain use cases. Therefore, we consider no-code tooling as a subset of the larger low-code tool market, especially as enterprise-class low-code platforms increasingly strive to address both citizen and professional developers.

根据Gartner报告的定义，实际上No-Code的理念与Low-Code并不冲突。两者的关系可以认为是从属关系，即：No-Code（零代码）从属于Low-Code（低代码）的范畴，如果进行解释，可以认为：

• “所谓的”零代码产品，并未脱离低代码产品族群，而是低代码领域的子集；

• 低代码产品的前端UI构建方案中，重要的实现方式，就是通过零代码的理念或组件来完成UI的构建。

  发展历史

  

  LCAP的特性

  回到Gartner的报告，其中提到了一份低代码领域的分支报告——《Low-Code Development Technologies Evaluation Guide》，这其中有一段对于Low-Code平台的横向对比标准的描述，也就是不同的供应商的产品，其在Low-Code能力方面，可以横向比对哪些因素。实际上，关于低代码平台的特性，也可以借由这些因素窥探一二。
  
  如上图可见，Gartner列示了9个不同的比较因素，并在之后进行了归纳，说明了目前主流的Low-Code产品具备的能力，分为两个部分：
  1）通用技术能力：

• 以模型/元数据为驱动的UI实现方式，最好是通过零代码的方案实现

• 能够在线进行基本的数据结构（底层为数据库）的数据结构定义
• 支持以SOAP、REST或其他类型的API的方式实现对外部接口的调用
• 支持以API的方式，对外提供平台自身的数据/服务
• 支持模型、可视化的代码或业务流程的开发实现
• 高性能和低时延

2）作为企业级平台的进阶能力：

• 高扩展性，例如：用户数、交易量、数据量等
• 高可用性与灾难恢复「容灾」、自动扩缩容
• 应用访问、API、数据存储的安全性
• 部署SLA或支持运行时部署（PaaS类产品）

我们可以借由此进行约定，符合上述的大部分能力要求的，可认为是Low-Code（低代码）平台。而在企业级应用解决方案中，会发现有不少传统IT人熟知的产品也是符合上述能力要求的，例如：BPM平台、iPaaS平台、国内的某些OA产品等。因此，在具体应用时，需根据组织自身的情况进行合理的选择。

简而言之，低代码（Low-Code）是指通过图形用户界面和配置，来代替传统的手工编码计算机程序来创建应用程序软件的平台。低码平台能够实现业务应用的快速交付，降低业务应用的开发成本。

HpaPaaS（高生产力应用PaaS）又是个啥

上图可以看到，“Low-Code”一词是拜Forrester所赐。作为同样是国际知名调研机构（a.k.a 造词小能手）的Gartner，显然不会轻易在这场可能决定低代码领域江湖地位的新概念作词大赛中认输，于是也于2017年发明了“HpaPaaS”（High-productivity application Platform as a Service）这个听上去更高大上的缩写词。

按照Gartner的定义，HpaPaaS是一种支持声明式、模型驱动设计和一键部署的平台，提供了云上的快速应用开发（RAD）、部署和运行特性；这显然与低代码的定义如出一辙。但事实证明，名字起得太专业并不见得是好事，“HpaPaas”最终还是败给了起源更早、更接地气也更顺口的“Low-Code”：从2019年开始，Gartner在其相关调研报告中也开始全面采用“Low-Code”一词（如LCAP），亲手为“HpaPaaS”打上了 @deprecated 印记。

图源：https://blog.kintone.com/business-with-heart/difference-saas-iaas-paas-apaas-hpapaas
一个图表来总结下三者的区别：

直观感受

据研究机构 Forrester 估计，低代码开发平台有着极其广阔的市场，可细分为数据库、请求处理、移动端、流程和通用低代码平台

奥哲·氚云

面向数字化管理员的开发工具

宜搭

低代码的企业应用搭建SAAS平台-阿里巴巴旗下产品

其他

实际上，low-code 平台的发展不局限于前端领域，移动 Native 客户端、服务端也有众多 low-code 探索。
Xcode SwiftUI：

VS Server Explorer：

以及阿里云逻辑编排：

第二部分：为什么需要/不需要低代码

话题比较大，部分内容参考自：什么是低代码（Low-Code）？

1、为什么「市场」需要低代码？

一些基本调研数据：

• IDC预测，未来5年需开发5亿个新应用，这比过去40年开发的所有应用都多。
• Gartner预测，到2021年应用开发需求的市场增⻓将至少超过企业IT交付能力的5倍。
• 据2019年统计，全球IT技术开发者一共有2400万，其中中国的开发者数量是760万，远满足不了市场所需。
• 有实际数据表明：企业创建应用程序的需求非常庞大，约86%的组织，难以找到所需的开发人员。

在这个大爷大妈都满嘴“互联网+”和“数字化转型”的时代，企业越来越需要通过应用（App）来改善企业内部的信息流转、强化与客户之间的触点连接。然而，诞生还不太久的IT信息时代，也正面临着与我国社会主义初级阶段类似的供需关系矛盾：落后的软件开发生产力跟不上人民日益增长的业务需求。

Gartner预测，到2021年应用开发需求的市场增长将至少超过企业IT交付能力的5倍。面对如此巨大的IT缺口，如果没有一种革命性的“新生产力”体系，很难想象仅凭现有传统技术体系的发展延续就能彻底解决问题。而低代码技术正是带着这样的使命而降临，期望通过以下几个方面彻底革新应用开发生产力，拯救差一点就要迈入水深火热的IT世界：

提效降本 & 质量保障

虽然软件行业一直在高速发展，新的语言、框架和工具层出不穷，但作为从业者我们不得不承认：软件开发仍处于手工作坊阶段，效率低、人力成本高、质量不可控：

• 项目延期交付已成为行业常态，而瓶颈几乎总是开发人员（对机器能解决的问题都不是问题）；
• 优秀的开发人才永远是稀缺资源，还贼贵；
• 软件质量缺陷始终无法收敛，线上故障频发资损不断。

而低代码正在将应用软件开发过程工业化：每个低代码开发平台都是一个技术密集型的应用工厂，所有项目相关人员都在同一条产线内紧密协作。开发主力不再是熟知for循环一百种写法的技术Geek，而是一群心怀想法业务sense十足的应用Maker。借助应用工厂中各种成熟的基础设施、现成的标准零件、自动化的装配流水线，开发者只需要专注于最核心的业务价值即可。即便是碰到非标需求，也可以随时自己动手，用最灵活的手工定制（代码）方式来解决各种边角问题。

扩大应用开发劳动力

通过让大部分开发工作可以仅通过简单的拖拽与配置完成，低代码（包括零代码）显著降低了使用者门槛，让企业能够充分利用前面所提到的平民开发者资源。部分纯零代码需求场景下，低代码还能让业务人员实现自助式（self-service）应用交付，既解决了传统IT交付模式下的任务堆积（backlog）问题，避免稀缺的专业开发资源被大量简单、重复性的应用开发需求所侵占，也能让业务人员真正按自己的想法去实现应用，摆脱交由他人开发时不可避免的桎梏。

至此，应用开发能力不再是少数专业开发者的专利和特权，且今后所需要的技能门槛与拥有成本也会越来越低，真正实现所谓的“技术民主化”（democratization of technology）。

加强开发过程的沟通协作

多方调查结果显示，软件项目失败的最主要原因之一就是缺乏沟通（poor communication）。传统开发模式下，业务、产品、设计、开发、测试与运维人员各司其职，且各有一套领域内的工具和语言，长久以来很容易形成一个个“竖井”（silos），让跨职能的沟通变得困难而低效。这也是为什么当前热门的敏捷开发和DevOps都在强调沟通（前者是协同Biz与Dev，而后者是协同Dev和Ops），而经典的DDD领域驱动设计也主张通过“统一语言”来减少业务与技术人员之间的沟通不一致。

有了低代码后，这一状况将得到根本改善：上述各角色都可以在同一个低代码开发平台上紧密协作（甚至可以是同一个人），这种全新的协作模式不仅打破了职能竖井，还能通过统一的可视化语言和单一的应用表示（页面/数据/逻辑），轻松对齐项目各方对应用形态和项目进度的理解，实现更终极的敏捷开发模式，以及在传统DevOps基础之上更进一步的BizDevOps。

统一开发平台下的聚合效应

低代码尝试将所有与应用开发相关活动都收敛到同一个平台（one platform）上后，将会产生更多方面的聚合效应与规模收益：

• 人员聚合：除了上一点所提到的各职能角色紧密协作以外，人员聚合到统一的低代码开发平台进行作业后，还能促进整个项目流程的标准化、规范化和统一化。
• 应用聚合：一方面，新应用的架构设计、资产复用、相互调用变得更容易；另一方面，各应用的数据都天然互通，同时平台外数据也能通过集成能力进行打通，彻底消除企业的数据孤岛问题。
• 生态聚合：当低代码开发平台聚合了足够多的开发者和应用后，将形成一个巨大的、连接一切、有无限想象力的生态体系，彻底放飞低代码的价值。

  2、为什么「专业开发者」也需要低代码？

  虽然零代码确实是设计给非专业开发者用的，但其所能支撑的业务场景确实有限，无法真正革新传统开发模式，替代那些仍需专业开发者参与的复杂业务场景。而狭义上的低代码却有潜力做到这一点，因为它天生就是为专业开发者而量身定制的。Gartner最近的一项调研报告显示，“66%的低代码开发平台用户都是企业IT部门的专业开发者”。这充分说明了，专业开发者比平民开发者更需要低代码。

屏幕前一批穿格子衬衫的同学要发问了：“低代码都不怎么写代码了，怎么能算是为我们程序员服务呢？”。虽然程序员讨厌重复自己，但重要的事情还是得多说一遍：开发 ≠ 写代码。1万年前蹲在洞穴里的原始人，在用小石子画远古图腾；100年前坐在书桌前的徐志摩，在用钢笔给林徽因写情书；而今天趴在屏幕前的很多人，相信都已经开始用上手写板或iPad涂涂写写了。千百年来，人类使用的工具一直在演进，但所从事活动的本质并没有多大改变。无论是用小石子还是小鼠标，写作绘画的本质都是创造与表达，最终作品的好坏并不取决于当时你手中拿着什么；同样地，应用开发的本质是想法和逻辑，最终价值的高低也不取决你实现时是用的纯代码还是低代码。

而相比纯代码而言，低代码极有可能成为更好的下一代生产力工具：

减少不必要的工作量

可视化拖拽与参数配置的极简开发模式，结合模型驱动的代码自动生成机制，可以消灭绝大部分繁琐和重复的boilerplate代码；一站式的部署和运维管理平台，无需自己搭建CI/CD流水线、申请环境资源、配置监控报警；一次搭建同时生成、构建和发布多端应用，免去人工同步维护多个功能重复的端应用；开箱即用的组件库、模板库、主题库、连接器等，让最大化软件复用成为可能。总而言之，低代码能够让专业开发者更专注于创新性、有价值、有区分度的工作，而不是把宝贵开发时间都耗费在上面那些不必要的非业务核心工作上。

强大的平台能力支撑

虽然上面列的技术支撑性工作并不直接产生业务价值，但却会直接影响业务的性能、成本、稳定性、安全性、可持续发展能力等。有远见的企业，绝不允许牺牲这些重要指标，来换取短暂的业务加速。低代码开发平台深知这一点，因此在简化和屏蔽底层技术细节的同时，也会尽可能把自己所cover的部分做到最好（至少能和纯代码开发方式一样好），包括但不限于：

• 现代化的技术架构和实现：现代化的低代码开发平台，在支撑用户应用时所选择的技术架构与实现方案，也会是现代化且符合业界最佳实践的，例如，前端基于主流的HTML5/CSS3标准和React框架，后端基于成熟的Java语言、SpringBoot框架和MySQL数据库，部署环境基于云原生的Docker镜像、CI/CD流水线、K8s集群和Service Mesh技术。
• 零成本的技术升级和维护：低代码的高维抽象开发方式，让应用的核心业务逻辑与底层技术细节彻底解耦。开发者在大部分情况下都不需要关心底层技术选型，同时也无需亲自跟进这些技术的版本升级与漏洞修复，免费享受与时俱进的技术红利和应用安全性提升。即便遇到某些底层技术或工具需要进行彻底更换（比如不再维护的开源项目），开发者也完全不必感知；技术迁移再费劲再难搞，平台自己努力就行，对开发者来说只要服务一直在线，岁月就依然静好；事后可能还会惊喜地发现，应用访问突然就变得更快了，仿佛冥冥中自有天助，感激上苍和低代码。

  一体化生态能力复用

  复用（Reuse）是提升软件开发效率和工程质量的最有效途径。传统的代码开发模式下，开发者可以通过提取公共类/函数、引用共享库、调用外部API服务、沉淀代码片段和模板等方式实现复用。在低代码的世界里，平台也可以提供对应的多层次多粒度复用手段，比如页面组件库、逻辑函数库、应用模板库等。

但更重要的是，低代码平台还可以充分发挥其一体化的生态优势，提供强大易用的可复用能力（资产）的发现、集成与共享体系：以页面组件为例，你可以直接用系统组件，也可以在平台自带的组件市场上搜索和引用更合适的组件，还可以自己用代码开发一个自定义组件并发布到市场中。平台的生态体系越大，积累的可复用能力就越多，应用的开发成本也会越低。

相比而言，虽然传统代码世界整体生态更庞大和深厚，但由于各类技术不互通、缺乏统一平台与市场、代码集成成本高等原因，一直以来都没有形成有类似规模潜力的生态能力复用体系，导致重复造轮子和低水平重复建设的现象司空见惯，还美名为“新基建”。

说到这里，另一批裹着冲锋衣头顶锃亮的同学也忍不住了：“万一低代码真的发展起来了，是不是就不需要那么多程序员了啊？上有老下有小的，同是码农身，相煎何太急！”。低代码虽然是一场应用开发生产力革命，但并不会革掉程序员的饭碗。它去掉的只是难懂的编程语法、繁琐的技术细节和一切可自动化的重复性工作，并没有也无法去掉应用开发最核心的东西：严谨的业务逻辑、巧妙的算法设计、良好的工程风格等。对于真正的程序员，即使剥去他一层又一层的编程语言和工具熟练度技能外壳，最终剩下的仍然是一个有价值的硬核开发者。

当然，如果你坚持要用纯粹的写代码方式来改变世界，也不至于失业。要么，你可以选择那些低代码暂时不太适用的领域，比如底层系统驱动、3D游戏引擎、火箭发射程序；或者，你也可以选择去写低代码中那一部分不可或缺的自定义代码扩展，为平民开发者提供高质量的积木。最后，你也完全可以选择为低代码平台本身的底层代码添砖加瓦。

3、前端为什么需要 low-code？

近几年 low-code 理念在前端领域逐渐流行起来，主要有这些原因：

• 被资源化的前端开发者：工作量大，但技术要求大多不高，生产效率成为了必须要解决的问题
• 开放的前端技术体系：low-code 类代码生成工具很容易与前端技术体系结合起来

• 趋于成熟的前端工程化体系：成熟稳定的前提下，才会转而追求变革式的生产效率突破

  被资源化的前端开发者

  面对大量低技术含量的需求，前端开发者就变成了极易替代的资源（就像低值易耗资产一样），前端人力进而成为产品需求迭代的瓶颈。此时，最好的解决办法是通过工具化、自动化的方式提高生产效率，突破前端资源瓶颈，自然就有了 low-code 方向的探索和实践，诸如 jQuery 时代的表单生成器、移动时代的 H5 页面制作工具

  开放的前端技术体系

  与移动 Native 客户端、服务端等技术相比，前端技术体系最为开放（甚至所有源码都是公开的），体现在：

• 第三方模块引入成本极低：无论布局容器、样式主题、逻辑模块、甚至整站，一行标签直接引进来就能用，甚至能够随时动态引入

• 拥有基于 Web 标准的开放生态：整个前端生态都建立在统一的标准层之上，任何一点创新都很容易累积起来，也总能站在巨人的肩膀上进一步创新

因此，low-code 平台得以站在巨人肩上前行，在组件库、构建工具、甚至可视化设计、代码自动生成的基础上进一步探索。另一方面，前端 low-code 产物都能应用到现有的任何前端应用程序中，无论生成的是 React/Vue 组件、jQuery 表单，还是SPA（Single Page App）、MPA（Multiple Page App）

趋于成熟的前端工程化体系

既不在十几年前，也不在更远的将来，而是现在，为什么？最重要的一点，low-code 平台的发展是在前端工程化体系趋于成熟的背景之下，毕竟只有温饱问题都解决得差不多了，才能转而追求更高的生产效率。

从技术演进的角度来看，前端 low-code 探索与前端工程化的发展历程息息相关：

前端工程化历经了这样几个阶段：

• CLI 工具：脚手架、构建工具、调试服务等等
• GUI 客户端：GUI 化的 CLI 工具，除交互方式外区别不大
• 定制化端 IDE：基于 IDE 扩展脚手架、构建、调试、发布、监控等工程链路能力
• 云 IDE：基于 Web IDE 扩展一系列工程链路能力，进入云研发时代

（摘自定制化 IDE 的核心价值）

在 CLI/GUI 工具时代，编码层面的效率提升主要体现在通过脚手架自动生成模板代码，减少了样板代码的编写，让开发者码得更少；在接下来的端/云 IDE 时代，API 提示、自动补全、代码片段（Snippets）等实用功能也通通集成进来了，让开发者码得飞快；IDE 时代之后，编码层面的效率提升已经达到极致，更进一步的生产效率提升需要变革式的突破。于是，迎来了 low-code 时代，让非专业开发者也能“码”得又好又快。

从前端工程化的角度来看，low-code 是工程效率提升的重要方向（也是必经之路），不难发现其中的 low-code 演进痕迹：

• 模型驱动设计：从直接操作 DOM 到数据驱动视图，提升代码可预测性
• 代码自动生成：从模板到代码片段到搭建，不断减少人工代码量

• 可视化编程：从组件拼装到拖拽生成，减少低效的重复工作

  low-code 模式下新的可能性

• 可视化研发模式：复杂度转移到工具中，专业性要求降低

• low-code 与智能化结合：素材/组件智能批量生成、结合端智能、个性化推荐等技术，让用户根本停不下来
• low-code 打入专业开发工具：在面向专业开发者的 IDE 中提供部分可视化辅助工具，如支付宝小程序 IDE
• 前后端一体的 low-code 方案：在端云一体化开发的基础上更进一步，自动生成、部署相应的BFF/SFF代码

像云计算产品将专业的运维工作转移到了云供应商一样，low-code 模式将专业的组件开发工作、甚至 BFF 接口开发工作都转移到了可视化研发工具侧，把专业的前端技术以普惠的方式赋能给了更多的非专业开发者，同时可视化辅助工具与专业 IDE 相结合，也让专业的开发者更加高效。

另一方面，前端生产力和生产效率提上来、专业性要求降下去之后，之前受限于开发成本而无法实现的事情都可以开始探索了，比如面向海量细分用户群体的个性化 UI（所谓千人千面）、自媒体时代的个人建站（再小的个体也可以有自己的平台）、高时效性的百变运营（而不只是发条push消息）。

4、低代码平台的难题和局限性

技术没有银弹。Low-Code平台虽然有偌大的市场空间、极好的发展前景、诸多的平台优势，但依旧脱离不了其自身形态所带来的应用难题及适用场景的局限性。

• 业务适配：低代码平台在面向模型设计时模型和业务匹配度往往决定其上限。
• 平台的易用性和业务灵活性难以调和：过于简单的设计虽然方便使用遇到复杂场景时又会束手无策，而过于灵活的设计看起来功能强大又难免会让业务专家难上手。
• 各种低代码平台很难形成统一的标准去开发和运营，导致用户接入不同低代平台都需要学习成本。
• 通用性受限：对于复杂度极高的业务场景低代码平台实现起来有些力不从心。

  5、为什么「我不」需要低代码

  即使所有人都认同上述“为什么要用低代码”的理由，但仍不时会有试水者跳出来，给大家细数“为什么我不需要低代码”。实践出真知没错，而且大部分质疑背后也都有一定道理；但在我看来，更多的可能是主观或无意识的偏见。这里我列了一些对低代码的常见质疑和我个人的看法，期望能帮助大家看到一个更全面和客观的低代码。

  质疑1：低代码平台不好用

  “试用过一些所谓的低代码开发平台，要么能力很弱，要么体验太差，只能开发点玩具应用。”

很多人调研过国内外多款低代码产品的深度体验用户，得到的观点是：不能以偏概全。低代码市场在国内正处于爆发初期，所以许多与低代码只沾一点边的产品也都在蹭热点；但它们并不能代表低代码目前的业界水平和发展方向。市面上真正成熟的企业级低代码开发平台，完全有能力以高效的开发方式满足大部分复杂场景的功能需求，以及企业级应用所需要的安全、性能、可伸缩等非功能需求，这一点在国外市场已得到充分验证（不然也不会这么被寄予厚望）。

当然，国内市场尚处于鱼龙混杂的混战阶段，遇到真龙的概率很低，但碰上金鱼鲤鱼甚至木头假鱼都在所难免。相信随着时间推移，真正有实力和口碑的产品都能脱颖而出，为大家展现低代码该有的样子。

质疑2：低代码开发不可控

黑盒：“平台上的各种可视化组件、逻辑动作和部署环境都是黑盒，如果内部出问题无法排查和解决。”

作为同样不搞清楚底层原理不舒服斯基的程序员，我更愿意相信：问题只是暂时的。虽然这确实是目前使用低代码平台时绕不开的一个痛点，但并不属于低代码技术本身的固有缺陷。计算机领域有一句至理名言：任何问题都可以通过增加一个间接的中间层来解决。低代码的思路亦是如此：与当年的操作系统和现在的云平台一样，都是想通过建立一个黑盒化的中间层抽象来降低开发者的工作量与心智负担。

当然，所有额外增加的中间层都不是完全免费的，低代码也不例外。作为一个尚未成熟稳定的新的中间层，低代码必然会出现各种让使用者束手无措的问题，就跟当年的操作系统内核bug、如今的云主机磁盘I/O hang一样。但历史规律也告诉我们，所有伟大的技术最终都会走向成熟；只要低代码领域一直健康发展，问题总会越来越少，最终降到一个绝大部分人感知不到的范围内。过去萦绕在Windows用户心中挥之不去的“蓝屏”问题，对如今的新用户来说早已不知为何物；今天低代码开发者所遇到的种种“蓝瘦”问题，未来也终将成为被遗忘的历史（谁还没段黑历史呢）。

质疑3：低代码应用难维护

“应用一旦复杂起来，各种复杂逻辑流穿插着自定义代码，看不懂也改不动，还不如全用代码呢。”

用低代码开发，也是要讲基本法的。一般来说，无论是使用低代码开发还是纯代码开发，造成应用可维护性低的根本原因往往不在于开发工具，而是开发者自身没有去遵循一些软件开发的普适原则，比如工程规范性、命名可读性、DRY/KISS/SOLID原则等。

好的低代码平台绝不会阻碍开发者去改善应用的可维护性；恰恰相反，还会尽可能提供引导和帮助。以Mendix为例，除了支持基本的模型分析与重构（e.g. 无用模型、对象重命名、子逻辑流提取）以外，甚至还提供了基于ISO/IEC 25010标准的应用质量监控（AQM）能力。另一方面，让应用变得难以维护的一个客观原因也是应用本身过于复杂，而低代码作为高度抽象和自动化的开发模式，在降低应用复杂度方面是专业的。

综合来看，低代码虽然不是能解决一切问题的银弹，但更不是会带来更多问题的炸弹：在提高应用可维护性方面的上限，一定比传统开发模式更高；但决定应用可维护性下限的，依然还是开发者自己。

第三部分：行业发展现状

对于一个行业而言，判断它当前的表现是否够好，或者未来是否有潜力做到更好，可以从以下这三个方面进行衡量：市场规模（蛋糕够不够大）、适用场景（是否可落地）、竞品状况（有没有被验证过）。

市场规模

• Forrester在2015年曾预测过，低代码的市场将从2015年的17亿美元增长至2020年的150亿美元。
• Marketsandmarkets在今年四月份的分析报告中预测，低代码的市场将从2020年的130亿美元（估算值，可以看出来与Forrester当年的预测是接近的）增长到2025年的450亿美元（年复合增长率：28.1%）。
• PS Inteligence在2018年的分析报告中预测，全球的低代码开发平台市场中，亚太地区将在今后五年（2019-2024年）中保持最高的增长速度。

总结一下就是两点：

• 低代码的市场规模足够大，且一直都在高速增长。
• 作为亚太地区的经济大国与IT强国，中国的低代码市场将会迎来一个爆发期，未来几年内的增速都会超过全球平均水平。

  适用场景

  理论上来说，低代码是完全对标传统纯代码的通用开发模式，应该有能力支撑所有可能的业务场景。但理论也只是理论，低代码一统江湖的梦想尚未照进现实，也不可能完全取代现实。前文中提到过，低代码与纯代码方式是互补关系，未来也将长期共存，各自在其所适合的业务场景中发光发热。同时还需要指出的是，当前阶段的低代码技术、产品和市场都尚未完全成熟，因此部分本来可能很适合用低代码来开发的场景，目前也只能先用纯代码来替代。

Gartner在2019年的低代码调研报告中，曾经绘制过一张用来阐述低代码适用场景的“应用金字塔”：

• 应用级别划分：从下往上，分别为工作组级（Workgroup Class）、部门级（Departmental Class）、企业级（Enterprise Class）、可扩展需求极强的企业级（Extreme-Scale Enterprise Class）。容易看出来，它主要的划分维度就是应用所面向的用户基数（基数越大，可扩展需求也越高），如：营销活动⻚面搭建、中后台系统⻚面搭建、小程序/跨端App的搭建
• 任务关键性：从下往上，各级别应用的任务关键性（Mission Criticality）逐级递增。例如一个只在工作组内使用的后台管理应用，一般都不会涉及到影响整个企业的关键任务。脱离企业这个视角来看，整个软件产业中也有很多通用的任务关键型应用，比如：实时操作系统、航空调度系统、银行对账系统。
• 实现复杂度：从下往上，各级别应用的复杂度（Complexity）也逐级递增。例如最上层的企业级应用，除了功能覆盖面大导致业务复杂以外，往往还需要满足更多苛刻的非功能需求，包括但不限于：用户体验、性能、可靠性、安全性、可伸缩性、可维护性、兼容性。其他一些复杂软件的案例包括：3D游戏界面（交互复杂）极其底层的游戏引擎（逻辑复杂）、超大型CRM系统（一方面是实现很复杂，另一方面，这种成熟软件的标准化程度较高，大部分情况下可以直接用现成的SaaS软件）、少儿编程/学生编程。
• 应用需求量：从上往下，各级别应用的需求体量（Volume）逐级递增，呈现一个金字塔形状。这个特征可以用万能的2/8原则来理解：20%的“全民”应用，由于需求的通用性和普适性，可以覆盖至少80%的用户群体（例如企业大部分人都要用的考勤系统）；而剩下那80%的“小众”应用，由于需求的定制化和特殊性（例如未上市公司的期权系统…），就只能覆盖各自小圈子里那20%的用户了。

• 与低代码的契合关系：从上往下，各级别应用与低代码越来越契合（Relevant）。也就是说：越简单的应用，越契合低代码；越不太关键的任务，也越契合低代码。同时，由于契合低代码的应用更偏金字塔底层，而这些应用的需求量都更大，所以可以得出如下判断：低代码能够适用于大部分业务场景（而且这个比例会一直上升，逐步往金字塔的更上层应用逼近），例如：B2E类应用（表单、审批流、ERP系统）、B2B类应用（企业商城、工业控制台）、B2C类应用（企业展示、营销页、店铺装修）。

  竞品情况

  下面是全球范围内做的比较靠前的几个竞品：

• Microsoft PowerApps：微软全家桶服务集成的非常好，比如 Excel，全站写代码的地方都统一为 Excel 相似的概念 Formula/Fx，另外 PowerBI/PowerFlow 十分强大，定位 hpaPaaS (low-code)；

• Google AppMaker：谷歌产，谷歌全家桶服务集成的非常好，谷歌工程师文化在 SCRIPTS 体现得比较极致，无论是后端、前端都使用开发生态的 JS 语法，代码提示十分友好，定位 hpaPaaS (low-code)；
• Salesforce SaaS：平台领头羊，集 IaaS、PaaS、SaaS 与一体的云平台，目前市值 1255 亿美元；
• Sap：集 IaaS、PaaS、SaaS 与一体的云平台，相比 salesforce，使用的技术要新一些，体验上要好一些，目前市值 1577 亿美元；
• OutSystems：提供桌面 IDE，最近提供的 OutSystems AI 能够辅助模型设计，定位 hpaPaaS (low-code)，作为后起之秀，表现不俗，已获得多轮融资，在 2018 年估值 10+ 亿美元，俨然成为下一个独角兽。

应用研发能力对比如下：

几点产品体验感受：

• Google 和 Microsoft 老牌玩家玩 hpaPaaS 这一套相当得心应手，体验相当讲究，把自家的服务包括三方常用服务整合的非常好。
• OutSystems 类似微软，提供多种流式编排，很多时候不需要写代码，同时也整合了非常多数据服务，比如 Swagger 的 OpenAPI。
• Salesforce 和 SAP 类似，从单一的应用程序，到一套应用程序，到一个快速应用开发平台，企业协作工具，再到一个应用程序容器和数据库提供，提供了一套完整的生态链，以 SaaS、PaaS、IaaS 的分层方式对外输出。

几点参考：

• 高效整合才能降低成本，这是所有玩家的心智，不容质疑。
• 视角要放大，要能够覆盖 90% 场景，必须要构建一套完整的生态链，从 no-code 到 low-code 再到 pro-code 都要有对应的解决方案，且要做到互相之间能够打通，这是 Salesforce 和 SAP 给到的经验，目前 AppMaker 和 PowerApps 主要针对表单、表格垂直领域，还不能够玩大，单一领域视角解决的问题有限。
• 可视化的流式编排针对特定场景提效明显，应对稍微复杂一点的场景，一点也不好玩，比如 AppMaker 就粗暴一点，直接使用 SCRIPTS，书写表达式更舒服，不知道使用 OutSystems 的用户是什么感受。

国内的几个经典案例：

国内低代码平台

类型	代表产品	说明
业务复用型：根据产品形态常见的有：应用开发平台、智能表格、SaaS聚合。
应用开发平台	宜搭、简道云、明道云等	宜搭：目标是为中小企业降低企业应用搭建成本。作为钉钉生态产品提供大量行业标准的应用模板，例如：CRM、财务管理、日常信息收集等，业务人员可以直接发布到自己的钉钉工作台快速投产；由于这些应用模板本事是基于丰富的标准化前端组件，业务人员经过简单文档学习，通过宜搭提供的可视化拖拉拽工具可以完成一定程度的业务定制。宜搭也试图突破边界，提供更深度的应用定制能力，虽然提供了JS编辑面板等代码编辑工具，但受限于原本产品定位，显得十分鸡肋。
智能表格	维格表、Treelab、轻流等	维格表：定位与主要产品目标与上面一条赛道基本相同，主要针对内部协作、项目管理信息收集一类的基础企业管理场景。而在产品形态上略有不同，这类智能表格型产品，延续了Excel经典的功能及交互逻辑，只要你用过Office里的Excel，这类产品上手就没有什么门槛。我个人是非常喜欢这条赛道的，定位极其精准。你可能想象不到中国有多少小微企业是依托一个Excel文件管理公司日常运营的，智能表格产品提供了无缝衔接的操作体验以及本地Excel所无法比拟的多人协作、高可用能力，很受小微团队欢迎。由于技术门槛相对较低，是很多小型创业团队的首选方向，但同样带来的是这个赛道竞争激烈，运营和渠道能力反而成为这个赛道的必考题。
SaaS聚合	Odoo、OpenERP	Odoo：CRM、ERP领域的SaaS起家，在海外市场风靡一时。Odoo瞄准的是应用级的开箱即用，依托于多年的SaaS交付和生态社区发展，Odoo积累了一大批围绕企业管理场景的SaaS应用。在应用市场中，用户可以选择所需的管理软件，如财务、库存、人事、设备管理、园区巡检等，直接添加到自己的工作台。相比于购买不同厂家saas产品，企业获得了统一的工作台、数据接口、底层协议，无论是自己依照odoo开源框架还是增加其他应用都有很好的拓展性
开发工具型：顾名思义，主要针对的用户是IT开发人员，这类低代码产品的主要目标就是作为一个编码开发工具，提升IT人员开发效率。不同于业务复用型产品瞄准通用化需求，开发工具型产品对垂直领域的深度要求更高，顺应现在技术发展，也就分为了前端提效、后端提效，但都围绕一个核心，帮助开发人员减少重复、通用代码的编码工作，让开发人员更专注于业务逻辑代码的开发。 开发工具型的产品形成就相对更丰富一些：在线IDE、DSL开发框架、组件代码库。
IDE+DevOps	Mendix、AppCube、iVX	iVX：iVX官方给出的定义是“0代码开发语言”，目标用户是开发人员。iVX提供了一套完整的DevOps解决方案：通过iVX的在线IDE可以完成前端页面的可视化构建，iVX提供了常用的前端组件如按钮、图片、输入框等；也可以完成后端应用逻辑的编排，通过将逻辑代码模块化，定义了循环、动作、条件、回调等事件模块，通过可视化“拼装”+配置的方式完成传统意义上的逻辑代码编码；iVX直接打包了底层的IaaS资源，用户可以按需直接部署上线。通过iVX相对封闭的一套技术体系，用户可以通过可视化方式完成前端、后端代码编码、上线部署的完成软件生命周期。由于产品整体自成体系，学习成本非常高，就像iVX官方讲的那样，他们目标是培养一个新的工作岗位——iVX工程师。
DSL开发框架	Uni-app、双链AI软件云引擎等	Uni-app: 是DCloud一个基于Vue封装的前端开发框架，可以达到一次编码，多端适配。用户只需要编写一套预定的标记语言，框架即可生成可以适配各个用户端的前端代码，是一个典型的DSL产品。这类产品的优势是交付效率非常高，如果你熟悉了这套标记语言，可以以较高的效率交付一套相对标准或模板化的成熟应用代码，对交付型团队，这里的提效就意味着利润的增加。但同时，交付型团队普遍人员流动性高，这又与DSL需要学习成本的特性相矛盾。因此，很多DSL产品源自于团队自身提效，最终也止步于此。
组件代码库	BrickNext、Vant、ICE等	BrickNext：优维科技旗下低代码开发工具，提供超过300个前端组件库，只需要配置yaml文件即可完成前端搭建。不同于element这类的开源前端组件，BrickNext基于前端原生开发方式，可以提供原子级的自定义能力，同时相较于element的通用型前端组件，BrickNext同时提供优维多年交付积累下来的业务前端组件。支持原子级修改是该产品的最大优势，但同时也是最大的问题，目前前端行业普遍采用Vue或React开发框架+element或其他前端组件的方式进行开发，基于原生的开发方式越来越少。

国内在大力投入Low Code的企业：

跟云☁️的结合

我们都知道，云计算主要分为三大类服务：软件即服务 (SaaS)、平台即服务 (PaaS) 和基础架构即服务 (IaaS)。

• 软件即服务 (SaaS)： 是一种通过互联网交付应用的模式。客户能够通过 Web 浏览器访问 SaaS 应用，这意味着，客户无需购买、安装、维护和更新硬件或软件。SaaS 提供商负责确保一切顺利进行，而且客户通常能够使用最新版本的应用。
• 平台即服务 (PaaS) ：能够提供云平台和各种工具，帮助开发人员构建和部署云应用。用户可以通过 Web 浏览器访问 PaaS，所以企业无需购买和维护基础硬件和软件。借助 PaaS，开发人员还能采用租用的方式挑选所需的功能。
• 采用基础架构即服务 (IaaS)，企业可以通过按使用付费的方式，“租用”服务器、网络、存储器和操作系统等计算资源。IaaS 提供商负责托管基础架构和处理系统维护及备份等任务，这样，客户就无需购买硬件或雇佣内部专家对其进行管理。

在 PaaS 层有专门用来支持应用在云上开发、部署、运行的平台，称之为 aPaaS (Application platform as a service)，在 aPaaS 基础上，提供 no-code & low-code 方式开发应用的平台称之为 hpaPaaS (High-productivity aPaaS)，提供快速应用研发能力，比如业务编排、逻辑编排、模型驱动、页面编排等。

以腾讯的云开发CloudBase为例，是一个很好地结合云的能力的典型case。其打造的理念是：「云开发低码平台」，是由云开发团队打造的拖拽式低代码开发平台，整合了腾讯云海量云服务和微信端生态能力，助力政务、工业、教育、金融等垂直行业直通上云。

云开发低码 LowCode通过「后端服务 Serverless 化，免鉴权调用微信开放能力」等方式，为企业和开发者提供低开发门槛、快速构建多端应用的服务，帮助企业在前后台营销场景和移动办公应用等方向构建业务应用；同时，云开发低码平台开放自定义组件和第三方数据源接入，企业和开发者可以无缝对接集成旧有系统数据接口，无需改造，快速上云。

具体来讲，云开发低码 LowCode 将繁琐的底层架构和基础设施抽象化为图形界面，通过行业化模板、拖放式组件和可视化配置快速构建多端应用（小程序、H5应用、Web 应用等）。与传统手工编码模式相比，一方面免去了重复性的编码工作，另一方面进一步降低应用开发门槛，让企业和开发者快速开发出满足需求的应用。

有几个好处：
1、降低开发门槛

• 开箱即用：提供开箱即用的组件、模板和工具，多纬度支持持续性开发；
• 多端发布：拖拽一份页面可快速发布多端应用，支持小程序、H5、PC（支持“PC端”预计2月上线）等应用，多端数据自动同步。

2、云原生支持

• 构建上云：低码应用的构建过程和 Coding 深度集成，云端持续构建；
• 部署上云：低码应用的部署过程和 CloudBase Framework 深度集成，一键部署上云。

3、数据源服务

• 数据源和云上资源（云数据库、云函数）深度集成，可无缝对接用户现有的后台系统数据，并基于数据快速生成业务表单/业务列表/组件；

• 天然集成云开发内容管理（CMS），方便应用的运营使用。

  第四部分：Low Code结合智能化的新探索

  在实际落地可视化搭建产品的过程中，逐步的也暴露出了非常多的问题：比如在使用层面上，

• 物料的缺失会导致一个页面可能难以搭建出来，针对于需要精准还原设计稿的场景只能通过原子化组件来一点点的搭建，效率就极为低下

• 可视化搭建画板的搭建效率、易用性等问题，这可能是可视化搭建落地过程中遇到的最痛的问题
• 复杂的可视化搭建画板的上手成本问题，不止是画板本身，也包括周边的各种配置等等

在研发层面，基于前端组件的物料开发可能是整个活动生产过程中遇到的成本最高的一个问题。 于是，基于「智能化搭建」探索的方式，尝试来一次性的解决上面遇到的所有问题。

可以看出：

• 上传设计稿并基于平台的能力生成对应的页面结构后，运营or研发都可以在页面上对要进行成组or组件化的部分进行圈选，给到研发同学之后，研发就拿到了该组件的「语义化」的UI结构代码及样式代码，只需要添加逻辑代码「后续也会尝试自动生成，至少部分的自动生成」即可快速完成组件的研发生产；而且整个过程都可以是在线完成的，平台也会提供对应的在线WebIDE + 在线调试「支持Lynx」的能力，组件开发好后运营同学就可以把rd开发的组件拿到页面里进行替换了
• 基于设计稿可以自动的生成页面，而且期间会对页面的结构进行切割，基于图片分类算法模型自动的对既有的组件进行推荐，运营可以选择既有的组件进行替换，以及后续可以基于画板进行一些样式的微调及玩法等的配置，整个过程简单高效，成本极低

• 因为代码都是自动化生成的，而且生成的是贴近于研发的语义化代码，我们会直接提供对应搭建活动的在线预览地址，运营同学测试没问题后就可以直接发布上线了，无需关心周边的其他配置，而且搭建生成的是工程级别的应用，线上运行效率无折损

  参考

• 一文看懂低代码的现状、打法、机会和挑战该文中有详细的case调研、解析

• 万字长文讲透低代码-InfoQ
• 深入看透低代码:阿里、腾讯等巨头火拼的下个风口-钛媒体官方网站
• 2021年 中国低代码行业短报告
• 钛媒体独家对话张建锋:钉钉的低代码革命-钛媒体官方网站
• 低代码平台浅析:钉钉宜搭 | 人人都是产品经理
• 钉钉用户超4亿，张建峰希望，未来三年长出1000万钉应用过去3年，阿里巴巴集团已通过宜搭构建了12700个应用，其中绝大部分是由HR、财务等不具备开发经验的岗位员工搭建，这些应用通过钉钉集成后，形成了支撑阿里巴巴十几万人的工作平台。
• 什么是低代码（Low-Code）？
• 阿里云2.0来了 张建锋：让不懂代码的人也能用云的能力
• 终于来了！云开发低码 LowCode 平台正式开启公测
• 探索低代码的未来
• 2021年中国低代码行业报告
• 2B领域下低代码的探索之路
• Low-code: Panacea or Revisited Hype?「Low-Code：灵丹妙药还是重温炒作？」