大家好，我是TT。

这篇内容我们来说一说低代码，与某种具体技术不同，对于低代码的概念，业界至今没有达成一致意见（我估计以后也不会，这是低代码被赋予的职能决定的）。

但作为低代码的接触着，甚至是架构者，我们需要对低代码平台到底是什么有一个清晰且深入的了解。这篇内容里，我会通过对低代码平台进行归类带你厘清低代码的概念，并带你分析当前低代码的发展现状，让你在脑海里建立起对低代码的直观印象。

在这里所说的内容都侧重于低代码的架构、策略和技术的实现。所以，对低代码是啥理解得越清楚，相应地，你就越容易理解我所作出的架构和策略的选择，以及为啥要采用特定的技术实现选型。反之，在概念理解有误的情况下，后续的内容有可能使你陷入目标与执行相互矛盾的困境，难以自拔。

什么是低代码？

要讲清楚一个模糊的概念，一个有效的手段就是先应该尝试对它，以及相关的概念进行归类，然后比对，从比对中得出关键差异。

但要对低代码做分类，并不容易。由于低代码概念和内涵未达成一致，业界对它进行归类的方式也多种多样。这里，我以我理解的低代码的几个重要特征作为维度，对低代码进行归类，同时你也能通过这些分析，了解我们这门课要实现的低代码平台到底是啥样的。

按代码量的维度来分类

这个维度下，App的开发模式可以分为三种：纯代码（ProCod）、低代码（LowCod）、无代码（NoCod）。

这三者有着巨大的差别，我们需要非常准确地将它们分开。纯代码是这个维度下的一个基准概念，它指的是传统的手工编码的模式开发应用。而低代码和无代码比较容易搞混。

从中英文字面上说，无代码意味着App的开发过程没有代码的参与。但是这样的理解比较粗浅，为了获取更加权威的理解，我尝试从头部分析机构Forrstr和Gartnr所发布的报告中，查找与无代码相关的调查报告，但一无所获，不知道是不是这些头部机构并不认可无代码这个概念。

低代码模式下的App开发过程是需要有代码参与的，特别是面对一些复杂的业务逻辑，通过表达式或者直接编码的方式来表达，反而更加清晰。而无代码模式开发App的全过程，没有任何代码的参与，不仅是从开发者角度看是这样的，从无代码内部的实现方式看，也是这样的。

严格来说，把采用无代码模式生成App的过程称为开发是不恰当的，因为它只是对已有原子业务能力进行二次组合，形成具有特定功能的新业务而已。因此从这个角度来说，低代码和无代码完全不是一种东西，切不可将这两者混为一谈。

但有一个情况非常容易混淆低代码和无代码。当低代码的成熟度到一定高度时，在某些细分场合下也是可以实现零代码开发的。在这个情况下，从App开发过程的表现看，这二者差异微小，此时最容易将两者混淆。当然，我们也不排除一些低代码解决方案提供商为了夸大其低代码的效果，而故意将二者混为一谈，把无代码当做一个噱头来宣传。实际上，低代码模式要将一个场景做到零代码，难度是非常大的，并且有诸多的业务前提。

在代码量这个维度下，我们专栏所说的低代码是指这个分类中的“低代码（LowCod）”这一类。

按适用范围的维度来分类

这个维度下，低代码平台可以分为专用型和通用型两种。

所谓通用，指的是开发平台不事先假设自身只能应用在特定的场景、业务、行业，而是具有广泛的适用范围。

具有这样特征的开发平台往往需要有一个通用的底座。这个底座是纯技术性的，它不依赖于特定的业务功能，而只与业界广泛使用的标准协议、技术标准产生耦合。不过，这个时候，我们只有深入平台架构实现的细节，才能判断平台到底是低代码还是无代码，这就导致平台的使用者难以甄别。（注意，我这里的目的不是想告诉你如何甄别，而是为了告诉你这里所说的低代码平台具有的特征）

但是，通用是有代价的，越通用就往往意味着在特定业务场景下的效率越低，越通用就意味着默认配置里的个性化信息越少，为形成某个具体场景所需的配置量就越大，从这个具体场景的角度看，效率相应也就越低。

所以通用型的低代码平台往往伴生着这个特征：有相对完善的有插件（或类似）机制。这一点相对来说比较好识别，相对高通用性的技术底座来说，插件是廉价的，因此通用性低代码平台往往会有数量众多的插件。这些插件可以定制出各式各样具体的业务场景，通过插件的定制化和扩展性来解决效率问题。

这个维度下，这门课所说的低代码指的是通用型开发平台，它具有一个通用性非常高的底座，和一个相对完善的插件机制。

按输出的App的类型来分类

其实，在一个具有较高通用适用范围的低代码平台来说，按照输出App类型分类几乎是没有意义的。之所以不得不按输出App类型分类，是因为开发平台的通用性不足，而在有了足够高的通用适用性之后，支持开发各种类型App的问题，就不在于能不能了，而只是时间问题。

尽管我们这门课所说的低代码指的是“通用型”这一类，但这并不影响我们看看现在业界其他低代码平台都可以输出哪些类型的App，大概有流程驱动型、表单驱动型、模型驱动（ORM）型、BI分析类型这几种，具体你可以看看这张表格（5星为满分）：

这里，我主要给你区分一下表单驱动型和模型驱动型这两个类型，因为它们比较容易被混淆。

所谓模型驱动型App，它的模型指的是数据模型，或是数据关系。而这里所说的关系，指的就是符合三范式的关系型数据库的关系，也就是你数据库中各个数据表之间的关系，比如表1的a字段和表2的a字段是相同的，但与表中的a字段没有关系。在正确配置了各种数据关系之后（这个过程一般称为数据建模），页面上就可以很容易创建各种CRUD类App了。

表单类App则是仅以数据为中心，创造各种表单来收集或呈现数据。这里的关键点在于，这类App并不

转载请注明:http://www.aideyishus.com/lktp/2821.html