1. 前言

过去的 2021 ，世界依然被 COVID-19 肆虐导致线上业务需求激增，低代码平台在此节点上进一步爆发，并在疫情防控及诸如医疗、餐饮、金融、制造的多个行业领域得到应用推广。

回想 2020 疫情暴发初期，为了更好地追踪人员流动、新冠病毒肺炎感染者与接触者的情况，阿里钉钉联动阿里云、支付宝、达摩院、政务钉钉、宜搭等团队，在短短一天时间内就搭建出浙江省新型肺炎公共服务与管理平台，并紧接着在湖北、湖南、贵州、河南等 28 省、自治区、直辖市协助搭建了 数字防疫系统 。在同一时间段，北京市海淀区也通过与致远互联合作，只用了一天时间即上线 海淀防疫上报管理平台 。

一款应用得以及时配合疫情防控情势实现快速上线，除了各方协力配合，低代码平台也在其中发挥了重要作用。简单来说，低代码指的是利用更少的手工编码来完成软件开发，主要是通过将普遍的、共性的代码能力封装为一个个可视化组件，搭建者可根据自己的需要进行选择，从而自主开发出相关应用。疫情防控应用之所以能短时间搭建完成，背后就是企业通过自身的应用定制平台来完成 组装 。

随后 低代码 便接力 中台 成为新的 IT 热点，引发了众多业内人士论战。其中有两种极端的观念，一种是 伪需求：通过 自降身价 、低端炒作 迎合资本，吸引更多的资本进入这个行业来满足资本逐利的需要；另一种是 颠覆行业 ：利用低代码平台快速、灵活的特点只能实现简单、基础功能的搭建，通过供给并不是用户真正的业务需求， 期间让更多非专业人士能够参与到开发当中。

2. 概念对比

低代码平台 （A low-code development platform） LCDP。于 1982 年，美国科罗拉多大学波德分校的教授 James Martin 出版了一本名为《没有程序员参与的应用开发》的著作，书中提及，每台电脑所匹配的程序员的数量在迅速减少，以至于未来大多数计算机需要在没有程序员的情况下投入工作。后来经过 Forrester 完善概念和定义，最终形成我们当下的理论基础。

Low-Code 给人感觉就是代码很丑而且还很 Low ，这里只能在 维基百科 中找到定义，具有四个特点：

• Low-Code 仍然是一种软件平台
• 提供可用于通过图形用户界面创建应用软件的开发环境，而不是传统的手工编码计算机编程
• 低编码平台可能会生成完全可操作的应用程序，看根据需要进行额外编码
• 低代码开发平台减少传统手工编码量、加速业务应用交付、降低软件设置、培训、部署和维护的初始成本

而且与 低代码 对应的是 专业代码/定制代码、零代码，其中 专业代码/定制代码 就是我们传统信息工程以代码为中心 Code-Centric 的开发模式。而 零代码 属于一种极端表现，彻底拥抱图形可视化编程。

2.1. 专业代码/定制代码 Pro-Code / Custom-Code

传统的以代码为中心 Code-Centric 的开发模式。

2.2. 零代码 Zero-Code / No-Code

从分类的完备性角度来看，有 纯代码 自然也应该有完全相反的 零代码 （也称为 无代码 ）。 零代码 就是完全不需要写代码的应用开发平台，但这并不代表 零代码 就比 专业代码/定制代码 更高级和先进，它只是做了一个更极端的选择而已：彻底拥抱简单的图形可视化，完全消灭复杂的文本代码。选择背后的原因是， 零代码 开发平台期望能尽可能降低应用开发门槛，让人人都能成为开发者（注意：开发 ≠ 写代码），包括完全不懂代码的业务分析师、用户运营，甚至是产品经理（不懂装懂可不算懂）。

3. 特点

通过上述的概念比对，我们认知到 低代码 ，主要面向设计编程，目标都是为了快速输出原型成果、快速部署测试，满足这一点就足够，他们都具有三类核心特点：

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

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

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

4. 分类

按照当前国内同行业对 低代码 的认知，习惯于按照设计思想的不同，将 低代码 又划分为 模型驱动 和 表单驱动 两种类型，这是 低代码 的两个技术方向，侧重点也不同。

4.1. 表单驱动

表单驱动 设计思路本质就是将页面的 表单 和 数据存储 结构合二为一，以 BPM 作为辅助在软件系统中运转业务流程，从而达到满足设定业务的需求。在当下主流业界的通行观点中 表单驱动 优势就是门槛低，所以不需要太专业的知识和技能背景，导致采用这类模型设计的产品很多，商业模式上都在 短 、平 、快 的基础上推进，主要面对的客户群就是从没实施过信息化的小微企业，能有一个应用系统提交数据就满足实际需要，都没有大规模业务且简单业务场景简单的需求，例如最常见的就是一些用于个人信息收集的轻量级应用。

表单驱动平台受制于自身设计缺陷，自带一个弊端就是触碰到信息化集成设计中一个非常敏感且忌讳的 "三孤"，即流程孤岛、系统孤岛、数据孤岛。

而且这块的产品都自带一个特性，非常明显的互联网思维，结合 SaaS + 低成本 的方式运作，这就导致此类的产品大家都长的差不多、功能相互借鉴、操作性无差别，总之各方面都趋同，这种 低代码 平台就已经等同 简单的数据表单录入与流转系统 ，特强调技术而缺乏对业务的理解，因此这类产品的应用都存在一个局限性更高，也就只能干点不带业务功能的应用，遇到一点复杂的业务没法落地，很难用在企业级应用的开发过程中。

4.2. 模型驱动

模型驱动 的设计则是用 可视化建模技术 来定义 数据关系、业务逻辑 、 构建人机交互 以及智能化集成，能够实现数据的同步交换和共享，使开发和业务都能够快速生成可交付的应用程序，而不需要代码。

这里只借用 OutSystems 作为案例说明，其他 模型驱动 类产品类似， 模型驱动 总结下来更像是集前端、逻辑和数据层分离设计的综合 IDE 型的产品，这类产品前端有专业的页面设计、事件触发，有专业的逻辑层可视化开发能力及内嵌专业代码片段的扩展能力，逻辑还可以区分前后端，数据层有专业的实体定义及操作能力。这样的设计令没有开发背景的业务人员望而却步，对没有技术支撑的企业使用上有一定的难度，但对开发来说确感觉比较熟悉，容易上手，也易于树立对平台能力的信心。

模型驱动平台一般系统架构清晰，表单和数据模型均可独立开发与维护；同时此类系统拓展性好，既可以内部横向扩展也可以对接外部系统容易，个别产品甚至能直连其他系统的数据库。

小结，上述主要为大家说明 表单驱动 、 模型驱动 的区别以及各自产品的特点，这些特点的差异都是基于不同的设计思路导致的，虽然这两类产品都有一定局限性，在取舍合理的情况下，也都能产生一定的商业价值，也希望这些总结可以为想涉足此类产品的公司或者个人提供一些片面的参考意见。

5. 机会与挑战

事实上， 低代码 图形化的开发模式存在至少已有 20 年历史了，最早的国外低代码平台 Mendix 、OutSystems 都已成为新兴的独角兽企业；当前国内大量传统软件厂商、新兴 SaaS 厂商也都在纷纷进驻该领地，大家都将目光指向那些没有 IT 能力的业务、行政、运营人员，希望通过将一些行业相对标准的应用模板化，直接满足业务团队 80% 的基本需求，再通过一些可配置、编辑工具辅助，让业务团队在标准基础上进行小幅定制，再解决 20% 特异化需求，最终达成业务需求直接落地成为在线工具的目的。还可以帮助小微企业省去高额的 SaaS 采购、管理软件外包及聘请 IT 人员的费用。

5.1. 机会

这类市场当具有 市场规模巨大 、 解决 业务复用 问题 以及 不寻求改变开发环境即可完成企业效率提升。

5.1.1. 市场规模巨大

国际权威机构认为全球低代码市场的潜力应该在 150 亿美元，未来将有 75% 的企业应用是通过低代码的方式搭建完成的。 而 Serverless 云原生技术的出现，为一站式应用开发提供了技术可能。另一方面， SaaS 市场伴随现代企业管理发展了几十年，无数场景从被新兴发掘，到商业模式与管理工具相互塑造，到现在逐渐标准化。将这部分标准化的部分提取出来进行多种形式的复用，是商业化市场发展的必然结果。从这个角度看，低代码的产品方向是蕴含巨大潜力的。

5.1.2. 业务复用

回归信息化的本质，就是企业需要标准化、自动化，反应到 IT 根据业务需求、编写应用，通过软件服务的形式，提高业务信息、数据流转的标准化和自动化，才会不断催生业务方提出新需求、产品分析需求、设计产品、开发编码、最终业务使用的完整链路。

这个链路的节点涉及多方，在协同、组织上很考验建设方本身的能力水平和统筹协调能力，此时再要提高运作效率上，一方面提升每一个节点自身的效率，这样整体效率也会跟着提升；再一方面就是对这个链路做减法，通过缩短或简化链路来达到既定目的，而 低代码 产品就是在链路上的实现是最短的，最终实现 低代码 产品的办公软件化的终极目标，这也是业务复用为 低代码 所打开的广阔市场。

5.1.3. 能效高

业界通行观点中，任何通过所谓在线 IDE 的形式，试图给程序员提供一个完整的在线开发环境，但效果都不很理想，主要受如下条件约束：

• 受制于浏览器的性能问题及渲染逻辑，很难替代本地 IDE 工具；
• IDE 软件开源生态是商业化产品所无法达到的，因此任何改变 IT 人员原有工作流的产品本身就存在很大的局限；
• IT 团队采购低代码产品一般来讲目标非常简单，就是降本，砍掉一些程序员，降低 IT 投入，而最有效的途径就是 不重复 编码。

小结，当下正好市场数智化转型的良好契机， 低代码 取代 SaaS 。自新冠疫情爆发以来，滋生大量需求， 低代码 提供大量标准化应用模板，相比以往的选择采购 SaaS ，可以让企业以最低成本接入应用，同时 低代码 的趋势将是办公软件化，直达实际需求，向用户屏蔽抽象的对象转化，自动完成业务模型构建，打造完整应用。

5.2. 挑战

• 市场孕育：经过这几年探索，国内 低代码 市场已度过创新阶段，开始覆盖业务。但是如何吸引市场上 SaaS 产品的用户群体转而关注能力更通用的低代码平台，是需要资本和从业者不得不考虑的问题。
• 挑战传统： 低代码 有一站式解决方案，提升效率、降低使用门槛，但是会对传统企业的流程及规范形成新的挑战，而且在内部采用低代码开发平台可能会导致影子 IT 构建不受支持的应用程序增加。
• 技术局限：当前的低代码平台产品形态基本以Web端产品为主，技术上受限于浏览器性能，交互上需要妥协于浏览器技术，增加了向用户屏蔽技术细节的难度。
• 升级改造困难：低代码平台是作为业务创新的起点，到应用全生命周期的托管，而对于一些技术栈老旧、设计思维老旧、经过多年迭代的存量系统的升级迭代问题显得有些力不从心。
• 职业角色缺失：低代码将会孵化出一个行业中的全新角色—— 业务信息官BIO ，立足于业务，有较高的抽象思维能力，能够将业务场景工具化。

6. 适用场景

上述着重介绍 低代码 的分类以及将市场应用，但是 低代码 也不是万金油，不可能覆盖现实世界所有业务，任何一个事情都有其存在的局限性和独特性，了解这个我们下面来介绍当前认知情况下还无法运用 低代码 的所能解决的应用：

• 算法和数据结构复杂且要求高：与之相比业务逻辑复杂反而会容易处理一点，无非利用可能在时间上做个取舍或者设计上做妥协，但是算法逻辑复杂才是真正的问题，无法通过 低代码 予以解决，如搜索引擎类。
• 高度复杂架构的应用：用户量巨大且性能要求非常高，如B2C类电商、门户网站等，他们的前后台技术架构非常复杂。
• OLAP/OLTP 及智能化应用：分析类应用自然应该用更专业的 BI 工具，智能化应用也应该用更专业的机器学习平台等工具。
• 视听交互行业：比如游戏或抖音、云音乐这样的社交娱乐型的应用。 低代码 平台可不擅长做专业媒体类文件的解析和酷炫的界面。
• 专业性很强软件：类似 Adobe Photoshop 、Auto CAD 等高度专业性软件 低代码 是替代不了的。

7. 结语

低代码 开发不仅仅是将一项枯燥的工作交由软件完成、降低程序开发难度，降低企业的投资成本，使其拥有真正的信息系统资本是一项技术支撑下的创变，而更重要的则是让熟知 现状与需求 的人直接参与进来，来加快科技赋能的实效性，提高企业解决问题的效率。关注企业在数字化演进过程中的真实需求，为其找到真正的价值，赋能于它们， 让其成长、发展、壮大，在过程中共臝，这才是今天科技企业的使命。我们反对销售技术“恐惧”，我希望技术“向善”，历史演进的长河不断在说明，只有真正把握住人类福祉的变革，才是真正伟大的变革。伟大的技术，不是破坏、颠覆一个行业，而是赋能一个行业。

同时在 低代码 模式选择的路上，需要注意是选择 模型驱动 还是 表单驱动 这会影响你将来的服务改造能力和业务拓展能力，一个卓越的低代码开发平台，一定是最懂代码开发的，只有这样才有可能把代码幵发过程中的复杂度降低，以更加简单的一面呈现给业务用户。