早期白癜风能治好吗 https://m.39.net/pf/a_13150497.html本文主要从企业数字化需求、现有产品分类、表达能力差异、面向用户差异等角度提出了低代码、零代码划分，简要介绍了传统开发、低代码、零代码三种开发方式关系和优劣势，希望对想了解这些产品间差异的同学有所帮助。
01、从企业需求出发，结合现有产品做区分
首先要了解一下企业对应用软件的需求，企业需求主要聚焦在数据分析类（BI），信息管理类，业务流程类三种场景上。目前市场上做的较为成功的产品也都往往构建在需求和技术实现的最佳结合点上。结合这两点，我们对现有产品做一下归类分析，很容易得出下面这张图。
但真实世界往往没这么简单，企业越大、数字化越深入，各种需求就会越复杂：
业务持续发展，应用系统需要有持续的迭代、演进和重构能力；
业务模型、逻辑异常复杂，需要有调试排错的能力；
既有的组件、类型无法覆盖企业各种差异化场景，要能有良好的可扩展性；
企业存在大量存量应用或服务，需要实现跟这些存量系统集成；
企业开发、生产环境隔离，制品应用需要有独立部署运行的能力；
投产后职能转移给运维，制品应用需要有设计良好的可运维性；
…
这些其实是软件工程领域长久存在的问题，但上面这些产品并没有给出答案，原因在于这些产品就不是面向这些问题设计的。
02、从封装层次（表达能力）做区分
我们把软件开发这件事情做一下抽象，虽然软件最终运行在各种通用运行时上（比如jvm或者操作系统），但是我们做软件开发层次是不一样的。传统开发工作在通用编程语言代码层，产物不管是解释执行还是编译执行，都运行在通用运行时上；低代码开发工作在经过封装的编程模型描述层，根据实现方式的不同，有的产物经过编译运行在通用运行时上、有的产物运行在自己的运行时上（执行引擎）；零代码开发工作在更加固化的业务模型描述层，产物通常运行在自己的运行时上（执行引擎）。
理论上零代码平台能干的事情低代码平台都能干，低代码平台能干的事情传统研发都能干，不过工作的复杂度和效率不一样。举一个具体的例子，比如我们需要开发一个请假审批流，如果我们使用流程引擎产品（多数企业基于支持BPMN2.0规范的activiti、flowable开源项目构建流程引擎产品），开发者开发这个流程只需要设计描述该流程的XML文件就可以，流程引擎产品已经内置好管理和驱动该流程需要的数十张表和执行逻辑。但如果这个流程用低代码或者传统开发方式去实现，那这个开发者就需要去设计模型、逻辑来管理流程任务、任务状态的流转等逻辑，相当于要把流程引擎干的事情自己重新做一遍，会是一个非常复杂的过程（当然因为不需要抽象所以复杂度不会达到从头设计一个流程引擎的程度，但还是会相当复杂）。
他们的关系好比是三维模型投影到二维，二维模型投影到一维。维度降低，站在该维度做事的复杂度就会越低，但也会失去上层维度的表达能力。这里我们以表达能力为衡量依据，提出了低代码（Low-Code）和零代码（Zero-Code）的概念。
零代码偏向于业务模型的抽象，解决的是特定业务需求高效数字化的问题；低代码偏向于编程模型抽象，解决的是高效编程的问题。当某些条件（场景）命中时，零代码无疑会有更高的效率。工作流、报表、电子表格就是经典的场景抽象。但面对复杂的融合性场景及其演化需求时，有没有合适应对这些场景的零代码模型是个问题、能否很好的配合使用也是个问题。这时就需要依赖低代码甚至更传统编程技术。
03、从产品综合能力做区分
低代码是通用编程技术的发展和补充、零代码是低代码及通用编程技术的发展和补充，三者在通用性和易用性上有着非常好的互补性，在这点我想大家应该形成共识。正是由于存在这种互补性，因此在实际产品实践中，低代码作为一个有良好扩展性和集成性的产品，它可以设计成和传统开发和零代码产品有良好的互操作。
04、从面向用户的角度做区分
I传统开发参与者都是软件工程某个专业领域的技术人员，比如产品设计师、前端开发工程师、服务端开发工程师、测试工程师，运维工程师等，他们使用自身专业领域的知识和工具，通过团队协作的方式来完成软件开发、迭代和运维。
I低代码开发通常面向业务IT人员，他们长期专注在某些业务领域的信息化数字化，同时具备业务领域专业知识和低代码开发能力。另外他们需要持续响应业务需求的变化，并提供应用运维保障等能力，负责整个业务IT体系的治理和建设。
I零代码开发主要面向企业业务人员（即所谓的平民开发者），通常来说需求相对简单、明确，重点
