面向敏捷应用的低代码开发技术及平台建设

传统软件开发交付链中，需求经过3次传递，用户→业务→架构师→开发，每一层传递都可能使需求失真，导致最终交付的功能返工。业务的变化促使软件开发过程不断更新、迭代和演进，而低代码开发即是软件开发衍生的其中一条分支。低代码是传统软件的进一步演变，以其高效、灵活和稳定的特点应用到企业的业务场景。低代码开发降低了应用搭建门槛，减轻对专业工程师的依赖，使得业务人员用拖拽的方式即可自行搭建应用平台，满足业务部门的个性化需求，降低人力成本，缩短项目整体开发周期。在后期运维上，低代码平台的迭代速度快，灵活性更高。低代码开发的核心价值是敏捷响应用户需求，增加应对复杂应用场景的能力。

1 国内外低代码开发研究现状

IBM在1980年首次提出低代码开发，在随后的近30年内发展缓慢，随着技术的沉淀和应用软件的深度应用，低代码迅速发展，主要经历4个阶段。

1）萌芽阶段：1980—2000年，IBM的快速应用程序开发工具（RAD）被命名为低代码。美国公司和实验室开始研究可视化编程，推出第四代编程语言（4GL），后来衍生为可视化编程语言（VPL）。

2）缓慢发展阶段：2000—2015年，企业逐渐涉足低代码开发领域，如1999年成立的Salesforce，2001年成立的OutSystem。

3）升温阶段：2015—2018年，AWS、google、Microsoft和Oracle等软件行业巨头的加入，使低代码领域的发展逐步升温。

4）快速发展阶段：2018—2021年，低代码领域进入快速发展阶段，根据Gartner研究报告，国外共有18家供应商进入低代码应用平台领域。2018年，西门子以6亿欧元收购低代码应用开发领域的领导者Mendix，快速应用开发的低代码平台OutSystems获得3.6亿美元的投资。

国外对低代码平台的重视程度和研究投入在2018年以来显著增加，美国仍是技术的先驱者和领导者，随着云计算技术的发展，传统平台向PaaS平台转移。多数厂商的产品能够支持私有云和本地部署，个别产品如LightningPlatform、PowerApps仅支持自身的云平台。这种捆绑销售模式虽然在一定程度上有利于自身云平台的推广，但由于云平台和低代码平台的竞品都较多，对低代码平台的推广非常不利。

国内涉足低代码领域比国外晚近20年，自2000年之后才开始研究探索低代码技术，主要经历了2个阶段。

1）早期探索阶段：2000—2015年，少数公司开始尝试对低代码进行研究，如较早的炎黄盈动。

2）快速发展阶段：2015—2021年，国内低代码开发平台进入爆发期，各厂商纷纷推出商用产品。2019年开始，互联网大厂阿里、腾讯和字节的加入，使低代码进入快速发展阶段。传统软件厂商也基于自身产品构建低代码开发平台，如ERP厂商金蝶、用友、明源云和黑帕云，OA厂商致远、蓝凌、泛微，CRM厂商销售易、纷享销客，财税厂商先胜业财，音频厂商声网、容联云、即构科技和融云等。

国内低代码平台起步晚于国外，成熟度与国外主流供应商存在较大差距，但自2018年以来人力和资金投入加大，创业型公司、互联网生态型公司、传统企业管理软件公司开始转型和孵化自己的产品，出现百家争鸣的局面，与国外平台的差距也在逐步缩小。

根据海比研究院、中国软件行业协会联合发布的《2021年中国低代码/无代码市场研究报告》显示，我国低代码厂商约有120家，整体市场规模已达19亿元，未来五年复合增长率将达到49.5%，第三方使用人员规模达到42.6万人。拥有足够竞争力的低代码开发平台通常具备3个核心能力。

1）aPaaS。应用程序平台即服务，用来快速构建后端逻辑。2）MADP。支持移动应用的开发平台，用来快速构建各种场景化应用。3）BPM。业务流程管理，以图形方式设计业务逻辑，然后由事务流程引擎执行模型。国内大部分低代码产品主要提供BPM功能，还需要继续向aPaaS和MADP拓展。

2 低代码开发适用性分析

2.1 低代码适用系统

低代码工具的推广广告对于具有高交付压力的企业非常具有诱惑性“只需拖拽鼠标，非编码人员也可以很快完成一个简单的应用程序”。凡事都有两面性，对于投入过热的领域，我们应当更多的理性判断，看清利与弊，而不是盲目跟从。低代码开发能在一定程度上为企业降本增效、减负增产，但也存在其局限性。

1）多数低代码应用平台仅提供公有云部署，应用和数据运行在供应商的PaaS服务器，数据安全和隐私难以得到保障，尤其是商机商业秘密的数据。

2）数据模型、元数据等底层都是平台专有，应用程序和数据的缺乏移植性，对低代码平台厂商形成依赖。

3）可靠性和安全性存在风险。如果低代码开发平台的组件存在质量问题或安全漏洞，开发出的应用程序的稳定性和安全性也会受到影响，而且难以控制。

4）标准化的UI设计限制了个性化的前端交互需求。

5）固化的指令式执行模式难以处理复杂、特殊的业务场景，业务流程只能适应平台提供的组件，组件的功能和类型限制了应用程序的开发。即使技术足够成熟，能够处理特殊规则和流程，也需要将规则转换为计算机能够识别的逻辑。不能一个工具没有或使仅有少量编码经验的人员变成高级开发人员。

6）平台的易用性和业务的灵活性难以调和，过于简单的设计虽然方便使用但难以应对复杂的业务场景。过于灵活的设计看似功能强大，但又难免会让业务专家难以上手。

7）低代码平台上的功能代码由工具自动生成，数据结构和算法不透明，组件封装，当出现缺陷和故障时，排查处理会异常困难。大量的使用问题、各种平台的报错都堆积到低代码平台的运维团队，运维团队会很快成为整个系统的效率瓶颈。

选择低代码应用平台应当扬长避短，符合以下特征的应用可以考虑使用低代码平台构建：1）业务变化快，且规则相对简单；2）开发重复性高；3）管理模式标准化程度高；4）需求不成熟，快速搭建原型；5）对数据的安全性和隐私性安全要求不高；6）对UI个性化要求不高。

2.2 低代码适用群体

从市场需求角度，低代码平台可以划分为4大类型。

1）场景应用型，以满足业务场景应用开发为主，开发的应用主要用于企业自用。目前用户量占比最高的低代码平台类型，约为45.7%。

2）产品研发型，以满足复杂的软件产品或解决方案开发为主，主要为其他企业提供应用开发。

3）平台生态型，提供开发标准和交易平台，以打造开发生态为主，为客户提供一站式的应用开发或产品服务。平台厂商通常开发标准和交易规则，为平台上的SaaS企业、专业开发者、软件开发商和ISV等众多合作伙伴提供技术、渠道等支持。

4）技术赋能型，以提供人工智能算法、区块链等先进技术插件为主，降低先进技术的应用门槛，目前使用者占比最少，仅1.7%。

从使用者角度，低代码平台可以分为5类。

1）软件产品提供商。将低代码开发平台作为一种工具提供给独立软件开发商ISV、系统集成商SI、SaaS企业、渠道代理商和咨询公司等，以实现其各自的目的。如软件企业通过购买低代码开发工具拓展自身的底层开发能力，以占领更多的市场；渠道商和咨询公司把低代码开发作为项目实施的工具，用于提高自身的系统部署效率；系统集成商把低代码开发视为一种新功能，招标时为潜在客户提供更完整的解决方案。

2）软件开发承包商。通过低代码开发对外提供开发服务，承接各类企业的原有信息系统改造或创新应用开发等项目。通过低代码开发平台，可以有效提高开发效率，降低人员投入成本，能够在更短的时间内开发出一个完整的应用系统。

3）一站式应用开发平台服务商。将低代码开发打造成一个平台，任何人或企业都可以到平台上开发应用，并且可以进行二次开发个性化定制服务，而平台则负责提供技术支持。

4）企业自用。企业内部具备设计开发能力，使用低代码平台构建自身需要的应用系统。

5）个人研究学习。个人或教育机构研究和学习低代码平台及技术。

按用户专业程度，技术人员一般可分为3类。

1）特定技术人员，指前端、后端和DBA等专业技术人员。

2）一般技术人员，指有一定逻辑编码能力的开发人员，能够快速理解并运用表达式、事件等概念。

3）非技术人员，指没有开发经验的产品、运营、商务和行政人员。

低代码平台最终的受众群体是企业，只有企业深度应用后才能产生更大的规模经济效益，无论是其他软件厂商集成自家产品后捆绑销售，还是低代码平台提供商自行销售，最终面向的都是企业用户。

3 低代码开发平台设计与实现

3.1系统架构总体设计

本项目部署的目标平台为混合云，系统将以微服务、SaaS为基础平台展开设计，整合Kube.NETes、Serverless和NoSQL等技术架构，构建支持云原生低代码技术平台。低代码开发平台系统架构如图1所示。

图 1 低代码开发平台系统架构

第一层支持IaaS（基础设施即服务），云服务提供商租赁模式的基础设施，本项目使用混合云。第二层支持CaaS（容器即服务），使用云厂商提供的托管的容器编排引擎部署和运行容器，管理集群，自动扩展和故障管理，并维护共同的基础设施层，包括治理和安全，本项目使用的为青云，其内置了Kubernetes。第三层支持PaaS（平台即服务），使用云服务提供商云服务中的软件，如数据库、对象存储和缓存等，本项目使用对象存储OBS。第四层支持SaaS（软件即服务），将低代码开发模块封装为单独的应用，提供给各个租户。

3.2表单引擎设计

表单引擎是快速实现表单开发的轻量级设计工具。目前，有2种思路可实现表单引擎设计，具体如下。

1）基于文件：创建表单时，先创建一个网页文件，在该文件上按需拖放Web控件，表单运行时，给网页随机生成一个地址，并将地址配置到菜单。

2）基于关系数据库：由表单设计器、表单解析执行器、表单模板3部分组成。表单设计器将表单元素存储到关系数据库，并为每个表单生成一个ID；表单模板将从表单设计器上设计的组件关系存储到数据库，由各个组件表组成的数据关系，组合成表单模板；表单解析执行器解析表单模板数据，并在网页上展示。

3.3流程引擎设计

流程引擎用于为表单的审批提供支持，本项目流程引擎使用开源的Camunda，可自定义流程模板和节点驱动。

3.3.1数据库设计

自定义的数据库表主要对Camunda原生的数据库表做进一步扩展，以支持子任务、任务与审批对象之间的关联、多人会签投票、审批历史等与业务强相关的场景。流程引擎数据库表设计如图2所示。

图 2 流程引擎数据库表设计（部分）

3.3.2功能实现

各租户可根据自身业务流程需要自定义流程模板，并可保存后再次编辑。Camunda工作流引擎的流程元素节点主要包括开始事件、中间/边界事件、结束事件、网关、任务、子流程、数据对象引用、数据仓库引用、参与者和组。其中，最常用的任务节点包括常规任务、不足的是，空中三角运算的三维模型生成技术存在一些局限性，例如模型效果受到采集影像影响、生成的较高精度模型仍然需要内业人员进行针对性修缮、重做等，进而导致三维可视化系统制作过程中产生新的开销。不过可以预料的是，随着测量技术与三维可视化技术的迭代更新，更加成熟的理论应用和研究成果将不断迸发。在全面实施乡村振兴战略背景下，乡村规划作为促进乡村可持续发展的重要治理工具之一，将发挥更大的作用。这也将为我国乡村地区实景三维模型建设提供技术参考与应用思路，为加快构建智慧乡村平台提供技术可行性依据。