聊一聊低代码和零代码的差异

    去年跟其他同学交流网易轻舟低代码平台时被问到最多的一个问题是轻舟产品跟国内其他低代码产品有什么差异，我们回答是轻舟是一款典型低代码产品，而目前国内绝大多数低代码产品其实更偏向于零代码，但由于低代码、零代码没有清晰的划分标准，因此其实这个问题一直没回答清楚。今天我们主要围绕这个问题做个解读，希望对大家理解相关差异有所帮助。

1、从企业需求出发结合现有产品做一个区分

    首先要了解一下企业对应用软件的需求，企业需求主要聚焦在 数据分析类（BI），信息管理类，业务流程类三种场景上。目前市场上做的较为成功的产品也都往往构建在需求和技术实现的最佳结合点上。结合这两点，我们对现有产品做一下归类分析，很容易得出下面这张图

但真实世界往往没这么简单，企业越大、数字化越深入，各种需求就会越复杂：

• 业务持续发展，应用系统需要有持续的迭代、演进和重构能力；

• 业务模型、逻辑异常复杂，需要有调试排错的能力；

• 既有的组件、类型无法覆盖企业各种差异化场景，要能有良好的可扩展性；

• 企业存在大量存量应用或服务，需要实现跟这些存量系统集成；

• 企业开发、生产环境隔离，制品应用需要有独立部署运行的能力；

• 投产后职能转移给运维，制品应用需要有设计良好的可运维性；

• …

    这些其实是软件工程领域长久存在的问题，但上面这些产品并没有给出答案，原因在于这些产品就不是面向这些问题设计的。所以真实的企业数字化需求，下面还有一个更大的圈（如下图）

    这个更大的圈内的很多问题恰恰是Outsystems、网易轻舟等从软件工程的角度抽象的低代码产品想解决的问题。当然这里面也会有一部分的需求是低代码无法解决的，需要通过传统研发方式去满足。

2、从封装层次（表达能力）做一个区分

    我们把软件开发这件事情做一下抽象，虽然软件最终运行在各种通用运行时上（比如jvm或者操作系统），但是我们做软件开发层次是不一样的。传统开发工作在通用编程语言代码层，产物不管是解释执行还是编译执行，都运行在通用运行时上；低代码开发工作在经过封装的编程模型描述层，根据实现方式的不同，有的产物经过编译运行在通用运行时上、有的产物运行在自己的运行时上（执行引擎）；零代码开发工作在更加固化的业务模型描述层，产物通常运行在自己的运行时上（执行引擎）。

    理论上零代码平台能干的事情低代码平台都能干，低代码平台能干的事情传统研发都能干，不过工作的复杂度和效率不一样。举一个具体的例子，比如我们需要开发一个请假审批流，如果我们使用流程引擎产品（多数企业基于支持BPMN2.0规范的activiti、flowable开源项目构建流程引擎产品），开发者开发这个流程只需要设计描述该流程的XML文件就可以，流程引擎产品已经内置好管理和驱动该流程需要的数十张表和执行逻辑。但如果这个流程用低代码或者传统开发方式去实现，那这个开发者就需要去设计模型、逻辑来管理流程任务、任务状态的流转等逻辑，相当于要把流程引擎干的事情自己重新做一遍，会是一个非常复杂的过程（当然因为不需要抽象所以复杂度不会达到从头设计一个流程引擎的程度，但还是会相当复杂）。

    他们的关系好比是三维模型投影到二维，二维模型投影到一维。维度降低，站在该维度做事的复杂度就会越低，但也会失去上层维度的表达能力。这里我们以表达能力为衡量依据，提出了低代码（Low-Code）和零代码（Zero-Code）的概念。

    零代码偏向于业务模型的抽象，解决的是特定业务需求高效数字化的问题；低代码偏向于编程模型抽象，解决的是高效编程的问题。当某些条件（场景）命中时，零代码无疑会有更高的效率。工作流、报表、电子表格就是经典的场景抽象。但面对复杂的融合性场景及其演化需求时，有没有合适应对这些场景的零代码模型是个问题、能否很好的配合使用也是个问题。这时就需要依赖低代码甚至更传统编程技术。

3、从产品综合能力上做一个区分

    低代码是通用编程技术的发展和补充、零代码是低代码及通用编程技术的发展和补充，三者在通用性和易用性上有着非常好的互补性，在这点我想大家应该形成共识。正是由于存在这种互补性，因此在实际产品实践中，低代码作为一个有良好扩展性和集成性的产品，它可以设计成和传统开发和零代码产品有良好的互操作。

    比如网易轻舟低代码产品，我们通过组件扩展机制，可以接受以Pro-Code方式开发和提交的各种扩展组件，通过这种方式可以覆盖到平台既有的组件无法支持的场景（见下图）

    另一方面，网易轻舟可以很方便集成网易有数BI报表、流程等零代码平台，发挥其在应对特定场景下易用性的优势（见下图）。

    此外网易轻舟可以对接企业已有的运维基础设施，融入到企业IT研发和管理体系中。因此基于低代码产品去构建大中型企业研发平台，具有覆盖场景全面、易用性高，可支持企业IT研发体系的持续发展的特点。

    从产品化的角度，我们在综合表达能力（灵活性、易用性、可扩展性），集成便利性、运维自动化五个维度对传统开发、低代码和零代码做一个比较，大致可以得到下面这张图。

4、从面向用户的角度区分

• 传统开发参与者都是软件工程某个专业领域的技术人员，比如产品设计师、前端开发工程师、服务端开发工程师、测试工程师，运维工程师等，他们使用自身专业领域的知识和工具，通过团队协作的方式来完成软件开发、迭代和运维。

• 低代码开发通常面向业务IT人员，他们长期专注在某些业务领域的信息化数字化，同时具备业务领域专业知识和低代码开发能力。另外他们需要持续响应业务需求的变化，并提供应用运维保障等能力，负责整个业务IT体系的治理和建设。

• 零代码开发主要面向企业业务人员（即所谓的平民开发者），通常来说需求相对简单、明确，重点关注在需求的快速满足，不太需要关注应用持续迭代和运维等问题。

    这篇文章主要从企业数字化需求、现有产品分类、表达能力差异、面向用户差异等角度提出了低代码、零代码划分，简要介绍了传统开发、低代码、零代码三种开发方式关系和优劣势，希望对想了解这些产品间差异的同学有所帮助。对上述分类有不同意见或建议的同学欢迎留言探讨。