低代码的定义与发展历程
低代码是一种软件开发技术，可以大幅提升软件开发效率，缩短软件项目的交付周期。和许多软件开发技术一样，低代码也不是“凭空产生”的，而是软件开发技术发展的必然产物。在软件技术发展史的尺度下观察低代码的诞生过程，能够帮我们更深入地理解低代码的定义。
一、低代码的前序技术
低代码技术是一种软件开发技术，在高级语言的基础上发展而来，集中体现了软件开发技术的发展趋势。从高级语言诞生到2010年代，软件开发技术尤其是企业软件开发技术呈现出组件化、框架化和可视化的发展趋势，这些趋势以及后续的“声明式开发”、“程序合成”、“可视化编程”会对软件开发带来哪些改变？
1.1 高级语言开发的新探索
编程语言是每一位专业开发者最熟悉的概念，也是软件技术发展史的重要见证者。
计算机诞生于1946年，计算机的核心部件是中央处理器（CPU）。计算机之所以能够工作，是因为我们给CPU输送工作指令。这里的工作指令就是机器语言，是由0和1组成的二进制串。机器语言可以被机器直接识别，但对人很不友好，非常繁琐也容易出错。在计算机诞生后不久，人们就发明了汇编语言。汇编语言参考了人类语言的符号，用助记符号代替二进制串。程序在执行前需通过编译程序将汇编语言还原成机器语言，再输送给CPU执行。汇编语言比机器语言更容易理解和编写，但是它仍然高度依赖于机器语言，与CPU体系架构一一对应，不同的CPU都需要不同的汇编语言和指令集（CPU能够识别的操作，如SSE指令集中用于比较字符串的pcmpistr，无法运行在不支持SSE的CPU上）。
随后，语言发展到第三个阶段：高级语言。在1957年，计算机专家发明了第一个高级编程语言Fortran语言，随后陆续发明了BASIC、C语言、C++语言、Java语言等。高级语言是指面向用户的语言，它与人类的语言规则更接近，比如，C语言当中有If … then … else …；Basic语言中的While … do等。这样的语法和人类的语言表达方式基本相同。直到今天，新的语言仍然层出不穷，全球已经累计有几千种高级编程语言。
从机器语言到高级语言，编程语言越来越接近人类的语言，学习和理解的难度逐渐降低，随之而来的，还有编程工作效率的显著提升。可以说，高级语言的生产力已今非昔比。在高级语言的基础上，为了进一步提升软件开发的效率，软件开发行业做了很多有益的尝试与探索，其中最成功的，当属可视化、组件化和框架化三个方向。
1.1.1 组件化
组件（Components）伴随着高级语言产生，它的本质是可重复使用的代码。
当一段代码可以在一个软件中使用，也能成为另外一个软件的一部分时，就可以被抽象成一个组件。组件的价值不仅仅在于提高代码的复用性、提高开发效率，还通过组件化的设计，也降低了整个系统的耦合度，提高了系统的可维护性。
目前组件化的开发方式非常成熟，覆盖面从文字输入等基础功能、统计函数等数据处理到报表等复杂应用场景。组件中涉及用户交互的最为常见，也被称作“控件”（Controls）。比如，开发者在前端页面中开发类似Excel交互体验的表格时，可以直接使用葡萄城提供的SpreadJS表格控件，而无需从零开始编码处理表格绘制、公式计算、格式化等。
1.1.2 框架化
组件让开发者可以复用代码，而框架（Framework）则通过提升软件的规范性来复用最佳实践。
框架是指可被应用开发者定制的应用骨架。就类似人类的骨骼系统一样，框架规定了应用的体系结构，阐明了整体设计、协作构件之间的依赖关系、责任分配和控制流程。
对于开发团队，框架化的价值在于提供软件的总体架构，简化了设计工作，降低对软件架构师的能力依赖，使得开发团队即使没有高水平的架构师，也可以让软件有一个很好的架构。同时，框架通过抽出非功能需求，让开发者能更加专注于业务逻辑的实现，提升了开发效率。总之，框架本身就是最佳实践的一个提炼和综合，基于专业的框架进行开发可以有效保障大型软件的处理能力、扩展性和可维护性。
1.1.3 可视化
“可视化开发”是上个世纪90年代软件界最大的热点之一，基于组件化和框架化发展而来。
最初的可视化专注于用户界面开发领域，可以让开发者通过拖拽的方式快速构建出用户界面，一些成熟的产品甚至可以做到“所见即所得”。即便与最先进的高级语言对比，使用可视化设计开发图形界面的生产率也能高出许多。
在品尝到可视化的“甜头”后，可视化开发的技术和工具迎来了大发展，其应用场景早已不仅仅应用于用户界面设计。如今的可视化开发已经涵盖了数据库设计、工作流设计、业务逻辑设计等各个领域。
全局来看，可视化开发在提高开发效率的同时，还降低了开发的技术门槛，这就让软件开发团队的构成有了更多的优化空间，如让美工参与构建用户界面，让业务人员设计业务流程等。新的团队构成除了能降低总体开发成本，还能通过减少沟通环节，提升软件团队的协同能力，加快软件交付速度。
1.2 声明式开发
上述三个探索方向的背后，是企业软件开发技术的发展趋势，即接受一定的性能开销，换取软件开发全生命周期的效率提升。如果将这些技术上的探索提升到工程层面，我们会发现其背后展现出的趋势可以清晰地概括为一条：面向结果而不是过程。这一变化深刻地重构了软件开发的模式，优化了从业务到计算机程序之间的“翻译路径”。
早期的高级语言编程以接近人类自然语言为设计目标，但实际执行中却依然存在较大偏差。以“从一个名为list的数组中查询name属性为ping的元素，并将符合条件元素的value属性添加到result数组中”这种范围明确、逻辑简单的场景为例，高级语言（Javascript）是这样开发的：
for (var i= 0; i < list.length ; i++) { if(list[i].name=="ping"){ result.push(list[i].value); } }
上面的代码是那些从后端编程语言转行过来的开发者中常见的写法，还有一些熟练的前端开发人员会这么写：
list.forEach((d)=>{if(d.name=="ping") result.push(d.value)})
以上两种做法，都可以在JavaScript的运行时中实现这个简单需求。但这种做法“简单粗暴”地定义了这一过程的每一步，包括与需求描述本身无关的临时变量i，以及想result数组中添加元素的push、forEach方法以及Lamada风格的函数表达式。所以，我们将这种开发方式称为“命令式开发”，覆盖了从C到C++、C#、Java和Python等几乎所有的高级编程语言。
但是，在需要长期维护的中大型企业软件开发中，这种开发方式会遭遇如下挑战，亟待新的开发方式来应对：
学习门槛：开发人员需要学习和理解更多的计算机原理知识，如循环、变量等和大量的语法、类库和机制
平台相关：这些技术细节与平台高度相关，需要开发人员学习和掌握平台的特性才能开发出更高效的代码
规范性：不同开发人员对于计算机原理知识和平台特性的理解不同、逻辑思维能力也存在差异，导致不同的开发人员为相同需求编写出的代码差异很大，规范性不强，人事风险高
可移植性：当平台需要升级或更换时，大量的代码无法直接复用，带来更高的成本投入和项目风险
1970年代，随着数据库技术的提出和逐步成熟，一种全新的编程语言带来的新开发方式受到企业软件开发者的关注：结构化查询语言（SQL）。以刚才的查询为例，使用SQL的开发者中99%都是这样写的：
SELECT value FROM list WHERE name='ping';
相比于命令式开发，SQL语言屏蔽了除了需求之外的大量细节，仅需要描述出我们需要数据库需要实现的“效果”即可驱动计算机完成这项工作。这种面向结果而不是过程的开发方式，被称为“声明式开发”。与命令式开发相比，声明式开发最大的技术优势是通过隔离技术细节，在降低开发者学习门槛的同时，实现了更广泛的跨平台，包括同一平台的升级和兼容平台间的切换。此外，在管理层面，声明式开发还通过提升规范性来管控开发者间编码习惯的差异，降低维护成本和人事变动带来的风险。
1.3 程序合成
声明式开发除了在技术层面提升了软件全生命周期的开发与维护效率，更重要的是为企业软件开发技术领域开启了新的方向：程序合成（Program Synthesis）。
中国第一批软件专业博士生导师徐家福教授为软件开发技术的发展方向指出了明确的发展方向，即“软件自动化是提升软件生产率的根本途径”。而软件自动化的本质是程序合成，即从根据特定的规约自动生成可运行的程序。
从这张图片中我们不难看出，程序合成存在三个重大课题：（1）规约：以某种形式规约表达的用户意图。（2）程序：以某种程序语言表达的程序空间。（3）合成器：在程序空间中运用某种搜索技术找到符合用户意图的程序，整个程序合成领域就是围绕着这三个维度展开研究。具体落地时，我们发现其中最关键的挑战是规约很可能是模糊的、不完备的，质量难保障。
1.3.1 演绎合成
在程序合成的早期，我们为了确保“规约”的质量，采用了演绎合成（Deductive Synthesis）的方式，即要求开发者用一种完整的逻辑形式规约的方式编写用户意图，然后转换为程序。这里的规约可以是“命令式开发”中的逻辑语言，这种做法可以类比于翻译工作，即将一种编程语言转义为另一种语言最终生成程序，就像开发者使用Visual Studio编写C#代码，然后将其编译成IL最终组装成运行在.NET运行时上的程序，给最终用户使用；也可以是“声明式开发”中的描述语言，就像上文中介绍到的SQL一样，开发者编写SQL语言（即数据查询的规约），由数据库承担合成器的职责将SQL解析并执行，最终形成一个程序，给最终用户提供数据查询的能力。
不论是哪种规约，这种做法让我们获得了更高层的封装和复用，相比于针对特定平台的C++编码，效率有所改善，但这种做法的自动化程度偏低，有很大的提升空间。
1.3.2 归纳合成
2000年后的程序合成开启了归纳合成（Inductive Synthesis）的方式。输入不再是完整表达逻辑的形式规约，替代为用户友好的输入输出示例（I/O examples）、非完整的逻辑规约（仅表达输入输出之间关系，不表达内部逻辑）等。从演绎合成到归纳合成，代表用户意图的规约从完整、清晰变得模糊，因此演绎推导的合成方法不再适用，我们需要使用搜索技术在有限程序空间中合成一个满足规约的程序。然而通用的高级程序语言（GPL）非常复杂，近乎是一个无限大的程序空间，这大大降低了搜索的效率。为了缩小程序空间，程序合成领域进行了大量尝试，最终，领域专用语言（DSL）方案胜出。
DSL方案中，我们首先需要针对不同的领域设计差异化的DSL，DSL中仅包含有当前领域的内容，在具体形式上，大部分DSL充分借鉴了声明式开发的设计思想，比如网页呈现领域的HTML还有上文中提到的数据查询领域的SQL都是如此。在基于DSL的归纳生成方案中，我们需要做的事情是基于DSL的特性设计出更简化的规约，并为之匹配合成器，完成从规约到DSL的转换。最终DSL将作为元数据，被程序加载和运行，实现程序合成的最终目标。
截止2020年代，归纳合成主要应用在DSL相对成熟的数据分析和界面原型构建中，而在业务逻辑和动态策略等领域依然处在研究阶段。在研的技术路线中，AIGC更值得行业关注。部分学者认为，AIGC在业务逻辑和工作流等领域，即将具备DSL方案的落地能力，甚至在GPL方案中也有一些可喜的成果。
1.4 可视化编程语言（VPL）
程序合成技术的落地需要新一代的人机交互方式，充分利用声明式开发的优势，帮助开发者用更高的效率完成规约的编写工作。可视化编程语言（VPL）应运而生。但是针对不同的细分场景，可视化编程的实现方式也各有不同，但大部分都采用了“演绎合成”的范式，即开发者在可视化开发环境中用VPL完整描述规约，合成器根据这些规约将其转义为GPL或DSL，最终生成可运行的程序。
1.4.1 通用性业务逻辑的可视化开发
通用性业务逻辑包含了页面交互的响应、数据校验、数据生成、数据交换、统计计算等场景。从原理上讲，基于高级语言的可视化开发本质上是代码生成器，即将用户可视化设计的规约直接“翻译”成通用高级语言（GPL），采用的是程序合成中的“演绎合成”范式。在DSL并不够成熟、或通用性较强的领域内，这种技术方案无可厚非。即便采用演绎合成，相比于传统的编码开发，可视化开发也能展现出足够的易读性、规范性等优势。
考虑到企业软件中业务逻辑本身对正确性、完整性、可读性、可维护性的高要求，演绎合成范式更值得开发者信赖，虽然这种可视化开发方式依然需要受过编程训练的专业人员来操作。
1.4.2 工作流的可视化开发
在企业软件中，最典型的业务逻辑是单据流转、审批生单等工作流。针对这种广泛的需求，面向工作流领域的DSL：BPMN诞生并沉淀成为行业标准。很快，这种DSL被引入到可视化编程中，并成为了VPL中影响最广的类型之一。
值得一提的是，BPMN采用了“声明式”的设计思想，与自然语言更贴近，学习门槛也显著低于高级语言（这也是大部分DSL相较于GPL的重要优势）。目前，BPMN通常由IT专业人员或受过培训的非IT人员使用可视化开发工具，以拖拽的方式完成开发。另一方面，行业正在积极尝试引入AIGC，以自然语言对话的方式完成程序生成过程，即从“演绎生成”升级为“归纳生成”，取得了一些成果但距离落地还有诸多挑战。
1.4.3 用户界面的可视化开发
用户页面的可视化开发是可视化开发的“传统领域”，我们在高级语言开发的技术探索中重点介绍了可视化开发的应用成果。这里不再赘述。
用户界面的可视化开发通常基于特定终端或跨终端的DSL，如Web浏览器的HTML、Windows桌面应用的xaml等。这些DSL均为声明式设计思想的产物，在设计时优先考虑页面设计人员而不是开发人员的使用习惯，如将页面划分为行、列，并通过各种排列规则来完成页面元素的整体布局。这种设计对“所见即所得”式开发非常友好，学习门槛比上文中的BPMN更低，相比于高级语言开发所呈现出的效率优势也更明显。
1.4.4 其他细分领域的可视化开发
截止目前，可视化编程语言已经覆盖了企业软件的全部模块，除了上述三种，还有以下类型值得关注：
数据流：可视化定义数据处理管道中各环节的操作逻辑，通常用于数据治理
状态机：定义某一个状态到下一个状态的转换策略，通常用于自动控制
时间线：定义关键帧和关键帧之间的转换效率，通常用于界面动画
1.5 小节
在高级语言诞生后的数十年里，采用“声明式开发”的“可视化编程语言”，正在逐步将“程序合成”的理念，从学术变成现实，大幅提升了软件的开发生产力。
这一切都在孕育着软件开发技术领域的一次重大变革。
二、低代码的定义演化
低代码的概念提出于2014年，但是从技术层面上看，这并不是一项全新的软件开发技术；同样冠以“低代码”，开发技术的实现路径与应用场景也不相同。
2.1 低代码是一个商业概念
与“程序合成”这种学术概念、“可视化编程语言”这种技术概念不同，“低代码”是一个商业概念，是对若干软件开发技术的总结与归纳。低代码概念最早出现与Forrester Research发表于2014年6月的一篇行业研究报告《New Development Platforms Emerge For Customer-Facing Applications》，作者在报告中将通过显著降低手工编码来提升应用交付效率的新平台称为“低代码”。回到2014年，低代码对应的技术概念是可视化编程语言（降低手工编码）和程序合成，均为相对成熟的技术和明确的发展方向。将成熟的技术冠以一个全新的商业概念，吸引投资界的关注和公众的目光，最终达成推动该技术成熟和普及的目标，低代码无疑是有一个成功案例。
2018年，葡萄牙的低代码厂商Outsystems获得了KKR和高盛3.6亿美元的投资并将估值推高到10亿美元后，低代码这个企业软件下软件开发技术细分领域的的“黑马”终于走到了台前，可以和互联网领域的新秀同场竞技。2018年也被称为低代码的“奇点”，从这一年起，低代码概念下出现了大量的高估值、大投资新闻，吸引海量厂商进入，堪称软件开发技术甚至企业软件的高光时刻。
2020年，在互联网投资的推动下，国内的低代码开始井喷。除了传统的软件开发工具厂商和新创建低代码厂商外，ERP、OA、BI甚至云服务商都推出了自己的低代码产品，开始跑马圈地。
2021年底，低代码概念的提出者Forrester Research甚至在其官网“Low-Code Platform”词条下加入买家警示：低代码行业存在严重炒作的描述，并且基于对中国低代码市场的调研提出了两种路线、九大厂商类型的赛道细分，对买家选型提供指导和帮助。
本文重点关注低代码技术领域，仅针对两种技术路线做展开介绍，两者的主要差异是可视化编程语言的覆盖度。
2.2 低代码：模型驱动路线
模型驱动的低代码又称面向业务开发者的低代码开发平台，数据与逻辑完全分离、各自独立，是可视化开发技术发展的产物，体验上承袭了传统软件开发的生命周期，也被称为“狭义的低代码”。
模型驱动的低代码专注于构建完整的企业软件，与高级语言开发形成一定的替代关系。在技术上，可视化编程语言覆盖了数据库、工作流、业务逻辑、用户交互、系统集成等全部类型，尤其是在复杂业务逻辑的可视化构建上有显著优势。
典型代表有西门子（Mendix）、Outsystems、葡萄城（活字格）、ClickPaaS。本赛道的产品研发门槛较高，商业模式对知识产权付费环境的要求高，目前以国外厂商为主，国内厂商数量较少。
2.3 无代码：表单驱动路线
将数据与业务逻辑合一的表单驱动低代码，衍生于ERP、OA中广泛使用的可配置化技术，使用体验类似于成品软件的实施。从市场宣传角度看，大部分表单驱动的低代码开发平台采用了“无代码”的宣传口号（本站部分页面以“无代码”代指“表单驱动的低代码平台”）。
无代码专注于构建简单的企业软件，填补高成本软件的空白。在技术上，可视化编程语言主要覆盖表单、工作流两种类型，应用场景以OA审批、数据填报等轻应用为主。如果需要构建复杂的业务逻辑和用户交互，则需要通过高级语言编码开发来实现。
典型代表调有捷德（Joget DX）、轻流。本赛道与“互联网思维”贴合度高，深受国内互联网投资机构欢迎，厂商和数量占优势，但经营持续性风险较高。
2.4 小节
低代码最初定位于可视化编程语言、程序合成等技术概念的商业化封装。这种商业化运作为低代码乃至整个企业软件开发技术领域带来了海量的投资和资源，很大程度上推动了该技术的快速发展。随着互联网投资的进入，低代码行业分化明显，形成低代码和无代码两条主要技术路线。低代码和无代码面向不同的应用场景，不存在演化关系，也没有绝对的优劣可言。
但因为低代码与无代码的差异性较大，国际主要的研究机构在研究和评估低代码与无代码技术时采取了不同的方法。中国信通院针对这两种技术分别设定了行业标准，强调了它们之间的差异。在低代码开发平台方面，模型驱动被视为基础要求。此外，针对低代码平台，区分了面向业务开发者的表单驱动平台和面向专业开发者的模型驱动平台。
三、低代码的技术能力现状
经过数十年的发展，低代码的技术能力已逐步清晰，主流的低代码产品在产品能力和设计体验上也有趋同的倾向。
3.1 系统组成
低代码开发平台通常由4部分构成：
可视化设计器：具备可视化定义UI，工作流和数据模型的设计器，且在必要时可以支持手写代码。
服务器程序：承载可视化设计器构建的应用，供最终用户通过多终端访问，具体形式如私有化部署的服务程序、运行在云端的容器或服务等。
各种后端或服务的连接器：能够自动处理数据结构，存储和检索。有些低代码开发平台将其集成到了可视化设计器中。
应用程序生命周期管理器：用于在测试、暂存、构建、调试、部署和维护应用程序的自动化工具。
3.2 核心能力
经过多年的发展，超百家厂商推出了大量的低代码开发平台产品。纵观这些低代码平台，除了都具有这些基本要素以外，没有两个产品是完全相同的。有些工具作用非常有限，更类似于与数据库配套的前端界面，如90年代的FoxPro；有些工具则仅专注于小众的业务需求，如客户档案管理；甚至有一些专用工具只是用低代码的术语来描述，但与实际的应用程序开发几乎没有关系。为了与其他软件开发技术进行区分，避免对IT决策者带来误导，Gartner将低代码的概念具体化，提出了低代码开发应用范围（构建包含有用户界面、业务逻辑、工作流和数据服务的完整软件应用）。针对企业级软件开发，Gartner还提出了低代码开发平台所需的必备功能。
Not be used only or mainly for building specific industry applications, and it must not be only a product bundled within some other solution or platform. 不能仅用于或主要应用构建特定行业的应用，不能仅限于在依赖其他解决方案或平台上运行
Support development and deployment of applications by professional developers in both central IT and line of business — not just for citizen developers. 需要能提供给IT技术人员使用，不能只给平民开发者使用
Develop, version, test, deploy, execute, administer, monitor and manage the applications and their relevant artifacts. 全生命周期：覆盖应用和相关资源的开发、版本管理、测试、部署、执行、管制、监控和管理的全生命周期
Embed data storage features without relying on additional procured services (i.e., includes a database). 内建数据存储：内建数据存储机制，不能依赖其他的数据库等存储服务
Support the design of data schema and application logic. 数据与逻辑设计：支持用来设计数据结构和应用逻辑
Create rich application UIs (i.e., not only a forms builder or building an administration UI). 完整的界面设计：支持创建完整的应用界面，不能仅支持创建表单或管理界面
Enable the invocation of external third-party services via APIs or event topics. 第三方集成：支持引入第三方API或事件驱动机制
Support some automation of platform patching and versioning. 自动运维：提供自动化的应用升级和版本管理机制
Provide single-step deployment across environments (development, test, staging, production). 多环境部署：支持针对多环境的一键部署，包括开发环境、测试环境、验证环境和生产环境
Access a platform repository or marketplace for sharing components, modules, connectors and templates 社区共享：提供可供访问的应用市场，用来共享组件、模块、连接器和模板