数字孪生低（零）代码不仅仅只是拖拉拽

Forrester在2014年首次提出了“低代码”这个词 ，当时对于“低代码”的定位则是“通过显著减少手工代码编码量来加速应用程序的交付（accelerate app delivery by dramatically reducing the amount of hand-coding required）”。

其实这句话可以做两个层面的拆解：

第一、针对开发语言本身，当前这一类编码语言的开发效率低；

第二、针对工作流的，基于手工编码的软件交付效率低；

从开发语言这个层面上来说，我们当前使用的开发语言大多属于第三代的高级变成语言，其中包括一些当今最常用的语言，如 JavaScript、Java 和 C#，这一代开发语言相比于前两代的开发语言的特点就是抽象程度更高，同时也更符合自然语言（大多还是英语），便于人类的理解，但是还是存在一定的门槛，需要经过特定的开发培训之后才能成为正式的软件开发工程师。

前两代编程语言相对于第三代变成语言来说更适合机器的理解，但是抽象程度更低，不太适合人类的理解，使用门槛比较高。

虽然第三代语言相对于前两代已经抽象程度更高了，但是从发展的角度来看，还是有一定的门槛，所以James Martin 于 1982 年在他的《无程序员的应用程序开发（application development without programmers）》一书中介绍了第四代编程语言，他提议使用 第四代编程语言技术将使非程序员能够开发软件。第四代编程语言旨在通过使用声明性语句和预构建组件来提高抽象级别从而提高生产力和简化开发，这是在开发语言上的一个发展背景和趋势。

从工作流这个层面上来说，工作流过程或者工作流脱节都会导致效率过低，所以提高协同效率或者减少工作流的环节就成为了其中关键的环节，而这种协同或者精简的核心就是要能够“统一语言”，以前总是说设计不懂开发，交付不懂开发，开发成为了交互环节上最容易脱钩的环节，如果使用的开发平台是一种大家都可以理解的语言或者模式，这样很多工作协同起来则会更轻松，对于一些轻量的应用需求，交付人员或者设计人员可以不需要开发人员的参与直接就可以完成项目的交付。

有很多专业的开发人员把现阶段宣传的“低（零）代码”认为是一种“智商税”，其核心的观点则是“不存在通用的低代码开发平台”，现在看到的更多的低代码的应用场景更多是BPM中的表单定制、流程定制等；另外一类则是大数据领域的一些数据面板类应用的配置，包括一些BI的工具以及类似组态这种工具，我们现在所说的数字孪生低代码平台大多数的应用场景也是聚焦在这个方面。

数字孪生领域对于低代码概念的引入，其实核心也是自顶向下的，这个顶也就是我们事先已经定义好了一个成熟的数字孪生应用的范式或者是模式，然后就是可以通过低代码的方式来提供这种生产能力，降低应用构建的复杂度和成本。

而对于软件开发人员的逻辑更多是自底向上的，比如一个专业的开发平台应该从数据建模、逻辑编写、界面开发、开发调试以及应用部署各个流程提供有效的支撑在能够称得上是一个开发平台。

但是从市场的角度而言，低代码的核心用户群体就是“非专业的开发用户”，他们可能是实施交付人员，也可能是产品经理，甚至设UI设计人员，所以针对非专业开发用户而言，“低代码或者零代码”进行应用构建的定位是非常合适的，这也是为什么低代码开始收到欢迎，本质上他把应用开发的群体放大了，对于专业开发人员的而言，最大的兴趣可能就只是在如何开发出一个很好的低代码平台，而不是如何应用一个低代码平台。

从严谨性的角度来说，低代码更适合做市场的宣传口号，因为这样更容易被理解，直接通过拖拉拽的方式就可以实现精美应用装配，显然是一个很动人的故事，而从产品逻辑上来说，到底什么样的低代码平台才是一个合格的低代码平台呢？

2020年Gartner 更新发布了企业级低代码开发平台的关键能力报告《Critical Capabilities for Enterprise Low-Code Application Platforms》给出了11个关键指标，在这边我们可以参考借鉴一下（参考知乎@Brian xu）：

1. Intuitive, No-Code App Development

易用性，在不写代码的情况下能够完成的功能。这是低代码开发平台生产力的关键指标，也是应用开发者选择使用低代码的初衷。

2. Application User Experience

使用低代码开发平台所构建的应用程序的用户体验，其对比的标的就是和代码开发的应用进行对比，从经验来说低代码平台后期遇到的比较大的麻烦就是性能的优化，随着页面和逻辑的复杂度增加，同时又由于缺乏必要的代码优化手段，导致程序臃肿，用过微软自动生成代码的感受会更深一些。

3. Data Model and Management

数据建模和管理能力，这个指标就是通常所讲的“模型驱动”。任何一个应用都是要面向一定的领域的，而面向领域的应用搭建过程中建模则是最关键的内容，对于预置组件类型的平台核心的就是通常只能够支持相应领域的模型组件，但是很难提供细颗粒度的通用建模能力。

4. Process and Business Logic

流程应用与业务逻辑开发能力和效率。这个能力分为两层：第一层是指使用低代码工具是否可以开发出复杂的工作流和业务处理逻辑；第二层则关注开发这些功能时的，低代码工具的便利性和易用性。一般的说，第一层决定了企业级应用项目是否能够成功交付，而第二层则影响项目的开发成本。不论如何，使用者都应关注第一层。在此基础上，如果项目以工作流为主时，第二层也应该作为重要的评估指标。

5. Platform Ecosystem

开发平台的生态系统。低代码开发平台的本质是开发工具，内置的开箱即用的功能无法覆盖更多应用场景。此时，就需要基于该平台的完整生态系统，来提供更深程度、更全面的开发赋能。很多开发平台都在建立自己的插件机制，就是平台生态的一个典型体现。

6. API and Integration

编程接口与系统集成能力，为了避免“数据孤岛”现象，企业级应用通常需要与其他系统进行集成，协同增效。

7. Architecture

系统是否支持更先进的架构、清晰的分层，以对接物联网IoT、RPA机器人、ML机器学习等新的技术。

8. Quality of Service

服务质量，与上一点类似，服务质量也是衡量运行于公有云模式下低代码开发平台的指标。这里的服务质量，除了通常所说的“无故障使用时间”外，还要考虑资源是否支持独占模式，避免某一个应用的高负荷，导致其他应用不可用或出现性能劣化。

9. Persona and SDLC

用户模型与软件开发周期支持。软件开发的生命周期中，除了开发和交付，还需要包含设计、反馈、测试、运维等多个环节。

10. Governance

开发管理。企业级软件的项目规模通常比较大，而且业务更关键，这就对开发团队管理提出了更高的要求。现代软件开发中主推的敏捷开发是否能在低代码中落地，是衡量开发管理能力的重要指标。这通常包含了代码库权限管理，版本权限管理，发布权限管理等一系列功能，帮助开发团队负责人降低软件开发管理过程中带来的各种人为风险。开发团队规模越大，越推荐开发者关注这一指标。

11. Security and Compliance

安全与合规。低代码开发平台需要在部署方式、系统安全机制和权限管理和控制功能等层面发力，全方位赋能开发者构建安全的，符合企业规则的企业级应用。

另外一个需要聊的就是目前出现一个很重要的趋势就是数字孪生低代码这种应用模式和云平台的aPaaS层是紧密相连的，所谓的aPaaS可以理解为PaaS的一种，即“平台应用即服务（application Platform as a Service）”，Gartner对其所下的定义是：“这是基于PaaS（平台即服务）的一种解决方案，支持应用程序在云端的开发、部署和运行，提供软件开发中的基础工具给用户，包括数据对象、权限管理、用户界面等。”

这种一体化或者融合趋势背后的原因可以如下理解：

1、面向非专业用户的流程闭环，低代码面对的都是非专业的的开发人员，这种非专业性可以这么理解：

你是一个专业的开发，但是在数字孪生领域你是非专业，比如很多JAVA开发可能对于3D开发就相对比较陌生，所这种情况下，集成方更多希望你给我个链接我们集成一下就好了，最多API交互一下，3D相关更深入的内容，我不想了解的很深入；

你不是一个开发人员，你不懂开发，但是最后你还是需要交付一个开发成果，这个时候应用部署的难度就会很大，如果是基于云平台则可以保证开发流程和运行的流程是一体化的，而不用管下层的细节了，这样难度会大大降低，而且也是个低代码应用开发的必要条件了；

2、云渲染基础设施需要，数字孪生云渲染天生就是要基于云环境，所以在这中情况下这就是部署的必要条件了；

3、生态的整合，数字孪生通常是在应用构建的下游，所以在生态上和其他应用是互生关系，尤其是和数据依赖比较紧，所以现在很多的中台都会提供低代码这样的平台用于数据的洞察分析。

从当前的情况来看，低代码的通用应用构建深度还不够，但是从上面的理解来看，当前模式的低代码构建一定是和相应的领域强相关的，比如构建数字孪生类型的应用，然后通过aPaaS平台进行更丰富的ISV应用整合从而覆盖更大的业务场景，这可能也是以前潜在的路径。