低代码开发平台（200613）

这周我差不多花了两个半天的时间进一步研究了下网上的低代码开发平台，也就是原来我们经常说的快速开发平台。研究这个的一个主要原因就是我们看到在新的微服务，DevOps，ServerLess技术，前端新技术的发展趋势下，低代码开发在时隔多年后被再一次的提起。

在微服务和云原生解决方案不断发展的情况下，我们看到当前的云服务已经从最传统的弹性计算和存储能力，提升到了我们常说的PaaS平台层，即提供更多的类似消息，缓存，数据库，中间件，安全，大数据平台等平台层服务能力。

有了这些共性技术服务能力后，应用开发就能够基于这些共性技术服务能力，应用开发能够更加只关注业务流程和业务逻辑的实现，再加上当前主流的微服务+DevOps+容器调度的云原生解决方案思想。即我们当前的应用开发更加敏捷和高效，能够快速的响应业务的需求。

那么我们接着能够考虑的就是再平台层足够强大后，我们的开发能否进一步更加简化，能够实现无代码或少量代码就能够完成一个功能的开发和朝云端的部署上线。比如我们现在看到的亚马逊的公有云提供的ServerLess就是一个典型的场景。你只需要写少量的配置文件或函数方法，就能够完成一个类似网页爬虫，信息搜索，图片存储等互联网功能。

第一：传统的快速开发平台

为了搞清楚低代码开发，我们可以看下在原来我们经常提到的快速开发平台。对于原来我们谈的快速开发平台，我想可以初步分为两种典型的类型。

1. 面向业务人员：完全不需要开发经验，不用接触代码。典型是类似各种BPM高度流程表单可定制产品。

2. 面向技术人员：提供快速开发平台和工具，比如代码自动生成，功能大部分可配置+脚本编写模式。

对于面向业务人员方式的平台往往就是一个高度灵活的空平台，所有的对象，数据，流程，规则，权限等你都可以随意的配置和定制。类似各类BPM产品，但是实际上可以看到这类产品无法开发规则业务复杂的系统。

对于面向技术人员的快速开发平台，类似我们常说的普元，JeeSite， JEPaaS，起步科技的PaaS平台等都属于这种类型。但是这种类型的平台本身又细分为了两种，一种是仅仅辅助开发和代码生成，即所有的开发内容都生成代码，脱离开发平台环境也能够成功运行；还有一种就是强绑定，平台很大内容不生成代码，对你黑盒，无法脱离环境运行。

我原来比较强调技术开发类平台是否提供源代码，是否进行强绑定，但是最近思考了下这个反而不是重点，真正重要的还是这个平台对各类场景，各类业务需求下的通用模式抽象能力，这个将直接影响到平台本身的好坏。比如一个平台本身黑盒无法扩展，但是你的业务场景又很难配置出来，那么整个平台的可用性就大大的打折扣。

其次，对于一个快速开发平台，我们可以有一个重要结论：

你对不同业务，不同场景下的通用性适配能力越强大，那么你实际运行的黑盒代码性能就越低。

也正是这个原因，我们看到很大快速开发平台代码臃肿，性能低下，你开发的时候速度倒是快了。但是后续系统的性能完全跟不上，也无法扩展，这些都是要命的问题。

第二：从传统快速开发到低代码开发平台

为了进一步谈我自己对低代码开发平台的理解，我先引用下网上对低代码开发的一些定义和说明。

低代码开发平台是无需编码（0代码或无代码）或通过少量代码就可以快速生成应用程序的开发平台。它的强大之处在于，允许终端用户使用易于理解的可视化工具开发自己的应用程序，而不是传统的编写代码方式。构建业务流程、逻辑和数据模型等所需的功能，必要时还可以添加自己的代码。完成业务逻辑、功能构建后，即可一键交付应用并进行更新，自动跟踪所有更改并处理数据库脚本和部署流程，实现在 IOS，Android，Web 等多个平台上的部署。 

低代码开发平台(LCDP)英文全称为Low-Code Development Platform,一个显著的特点是，更多的人可以参与到应用程序开发当中，不仅是具有专业编程能力的程序员，非技术背景的业务人员同样可以构建应用；对于大型企业来讲，低代码开发平台还可以降低IT团队培训、技术部署的初始成本。

从这个定义上面我们可以找到一些关键点，简单总结来说就是

1. 少量代码或者无代码，业务人员也能参与

2. 提供可视化，可配置的工具进行配置和建模

3. 可同时发布到多个平台或终端

4. 提供和云端的持续集成和发布能力，可持续交付，即我们常说的DevOps

对于低代码开发平台和快速开发平台区别，实际我想强调一个重点，我个人认为很重要，即：

低代码开发需要实现从最早的以数据库对象建模方式转变为服务化建模方式。

传统的快速开发平台不论是表单或流程涉及，更多的还是围绕数据库为核心进行，建立的对象可以生成数据库。相关的表单操作也围绕数据库进行。

而在低代码开发时代，我个人更加推荐一个转变，就是基于对象服务化的分层开发模式。这个本身也是更加贴近我当前中台和微服务的构建思路。即你首先去构建你的对象并发布你的服务，然后再考虑如何基于这些发布的服务类构建上层的应用。即我们的开发过程横向拆分为两端。而中间基于服务进行松耦合连接。

即：微服务 + 服务 + 前端应用。

不是简单的我们传统应用拆分小了，而且我们的前端应用模块，后端能力模块也全部微服务化，形成我们当前说的平台+中台+前端应用的分层模式。这种模式如果再和我们当前的DevOps和容器化技术结合，那么整个开发完成的应用就更加容易持续发布和交付，也更加容易在后续继续弹性资源扩展和调度。