再谈低代码开发平台(200727)

今天准备谈下快速开发平台和低代码开发平台方面的内容。

快速开发平台本身的欠缺点

对于快速开发平台在10年前我关注的比较多，当时也是属于快速开发平台的狂热者，也试图去构建一个完整的包括了对象建模，数据建模，流程建模，规则建模，界面建模的完整快速开发平台。但是最近几年这方面的关注比较少，只在16年对开源的基于元数据驱动的EOVA平台进行了简单试用，在去年对JEPaas平台进行了简单试用。

当然就公司来说本身也有一个积累了很多年的技术平台，要上升到产品化的快速开发平台还有一定距离，但是也足够我们日常项目使用。其中最重要的就是流程引擎和4A，还有就是共性的技术组件的抽取和积累。

这几年没有关注快速开发平台，其原因究竟在哪里？实际上最主要的原因包括二个方面：

• 快速开发平台本身往往是一个封闭的系统，扩展维护存疑，同时该技术资产不受企业控制。
• 面对一些特殊的和复杂的业务场景需求往往难以满足，同时也没有开放扩展类接口能力。

特别是对于第2个问题，即使你满足了99%的功能需求可灵活配置，但是关键需求的1%无法满足，整个快速开发平台是黑盒你无法去定制和扩展，同时平台提供商也不帮你定制开发，那么这个业务系统就很难最终交付给客户使用。

我们经常会说软件开发商有时候会绑架客户，那么同样道理，这类的快速开发平台能力提供商往往就容易绑架软件开发商。软件开发商用平台朝客户交付了软件产品，但是最终这个软件产品的可运维属性并不真正掌控在软件开发商手里面，这就是最要命的一点。

也正是这个原因我们也看到，往往是有一个小规模的软件开发队伍的甲方企业往往容易选择这类快速软件开发平台，即自己定制和快速开发后自己用，平台提供商提供二次服务能力，减少了软件开发商这个环节。

再其次， 一个软件企业的开发团队本身也不愿意采用这种平台 。

团队人员往往喜欢学习和尝试各种开源技术和新框架，希望自己在开发过程中锻炼自己各方面的技术能力储备提升自我价值，这种技术能力储备本身是适配所有的软件开发企业的。

而对于这种快速开发平台本身，开发人员更多是进行简单的配置和 SQL 编写，很多技术细节已经封装在底层，开发人员想要提升技术能力很难。

如果要给刚毕业的一开始就接触这种平台，即使你平台用的再熟，脱离平台你发现连基本的简单功能都做不出来。对于 Java 的常用开发框架，开源组件，三层架构，数据库建模等更是一窍不通，这也是大部分从事软件开发人员不愿意的事情。

快速开发平台的优势在哪里？

而今天我为何还要再谈快速开发平台？

主要原因还是这几年快速开发平台本身也在快速的发展，一个快速开发平台只要应用的企业和团队多了，那么就更加容易在实践过程中不断的将个性化需求抽象为共性需求融入到快速开发平台里面，这个本身有一个过程，积累的越久，快速开发平台的能力往往也就越强大。

而当前来说，一个好的快速开发平台往往可以解决90%以上的业务需求功能实现，而个性化或定制的充分提供开放接口给你自己去处理。那么这种开发平台本身是有价值的，可以真正做到快速的功能交付和对需求的敏捷响应能力。同时一个功能开发往往还同时适配桌面和手机端，更是减少了重复开发和定制的工作量。

而对于开发人员来说，很多开发往往做的实际就是开发平台的活，简单的增删改查功能，而且做的质量还没有开放平台好，要价和成本还不低，速度也慢。这类开发人员往往最终一定会被取代掉，这也是我原来就强调过的对于软件开发人员的薪酬一定会出现两级分化。高的会很高，而低的也会更低，不会出现类似前两年随便一个IT培训班出来的人员就能够拿高工资的现象。

由于快速开发平台本身的交付周期很短，可以更加方便我们快速的形成可用的产品原型给客户演示和试用，并快速的进行迭代变更和优化。这可以很好的解决传统模式下静态原型或Axure原型本身交互和数据上面的弱项，真正让用户边使用边优化。

如果一个业务系统真正发挥作用了，业务和数据量也都呈现明显的增长趋势，我们大可以重新规划完全重做并脱离快速开发平台，而采用快速开发平台则是拥有了最小的试错成本。

最近几周，自己又重新搜索了下当前提供商用的快速开发平台的公司，对于几个产品也初步进行了演示环境的使用，确实了比前面几年有了很大进步，至少我们常用的功能实现都能够很轻松的配置出来。几家的比较下来，自己比较推荐如下这家的快速开发平台，也准备在后面深度试用下。

http://www.jepaas.com/

对于这个平台我自己做了简单的试用，大家也可以试用下，简单总结就是对于快速开发平台仍然任重道远，远远没有达到我们期望的一个程度。

我们熟悉的软件项目也，平常看似单纯而率直，但很可能一转眼就变成一只时程延误、预算超支、产品充满瑕疵的怪兽，所以，我们听到了绝望的呼唤，渴望有一种银弹，能够有效降低软件开发的成本，就跟电脑硬件成本能快速下降一样。但是，我们预见，从当前开始的十年之内，将不会看到任何银弹，无论是在技术上或管理上，都不会有任何单一的重大突破，能够保证在生产力、可靠度或简洁性上获得改善，甚至，连一个数量级的改善都不会有。-《没有银弹》

如果最近又接一些小项目，也打算用这个平台做下尝试，看下实际的效果如何。而对于快速开发平台而言，一个好的快速开发平台必须具备的一些关键能力如下。

1. 高度灵活，可配置的流程引擎能力，4A能力，核心是用户，组织，资源，权限。
2. 报表平台能力
3. 灵活的页面表单可视化设计和配置能力
4. 业务规则和逻辑的可配置能力
5. 数据库sql的灵活配置能力
6. 同时对桌面端和移动端的双向生成和交付能力
7. 门户的可配置化和定制能力
8. 日志监控和运维管理能力，封闭平台应该提供的问题排查能力
9. 灵活开放的二次开发接口能力

如果从甲方角度思考，还有一点就是可可以完整源代码导出并交付的能力，方便后续甲方接手管理和运维。一个好的快速开发平台一定不能搞来自我封闭，导致后续客户无法自行维护，也无法进行能力迁移，这些问题点都必须避免。

从快速开发平台到低代码平台

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

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

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

那么我们接着能够考虑的就是在平台层足够强大后，我们的开发能否进一步更加简化，能够实现无代码或少量代码就能够完成一个功能的开发和朝云端的部署上线。

比如我们现在看到的亚马逊的公有云提供的ServerLess就是一个典型的场景。你只需要写少量的配置文件或函数方法，就能够完成一个类似网页爬虫，信息搜索，图片存储等互联网功能。

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

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

• 面向业务人员：完全不需要开发经验，不用接触代码。典型是类似各种BPM可定制产品。
• 面向技术人员：提供快速开发平台和工具，比如代码自动生成，功能大部分可配置+脚本模式。

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

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

对于起步JuStep的快速开发平台和PaaS云，我没有进行试用，但是在10年前推出的快速开发平台我试用过，这个企业能够这么长周期的生存下来产品应该自有一定的优势和能力。特别是现在提出的快速开发平台和PaaS云+DevOps融合集成更是一个大趋势。

即我们原来在谈整个云原生解决方案的时候，里面有一个内容块就是快速开发平台和开发框架。

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

其次，对于一个快速开发平台，我们可以有一个重要结论： 你对不同业务，不同场景下的通用性适配能力越强大，那么你实际运行的黑盒代码性能就越低。

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

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

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

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

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

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

1. 少量代码或者无代码，业务人员也能参与
2. 提供可视化，可配置的工具进行配置和建模
3. 可同时发布到多个平台或终端
4. 提供和云端的持续集成和发布能力，可持续交付，即我们常说的DevOps

对于低代码开发平台和快速开发平台区别，实际我想强调一个重点，我个人认为很重要，即： 低代码开发需要实现从最早的以数据库对象建模方式转变为服务化建模方式。

即快速开发平台提供的能力应该是各种技术服务和技术组件，我们前台应用的构建能够快速的使用和组装这些能力服务，实现快速的可视化编排，这点大家也可以参考下JuStep快速平台的思路。

由于我们自己没有详细试用，因此在这里不做评价。

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

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

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

不是简单的我们传统应用拆分小了，而且我们的前端应用模块，后端能力模块也全部微服务化，形成我们当前说的平台+中台+前端应用的分层模式。

这种模式如果再和我们当前的DevOps和容器化技术结合，那么整个开发完成的应用就更加容易持续发布和交付，也更加容易在后续继续弹性资源扩展和调度。