【低代码】低代码平台演变过程和最终形态预测_低代码平台可能会采用统一的数据模型,如实体-关系模型(er模型)

一、 概述

这几年低代码概念非常火热，市面上的低代码平台如雨后春笋应运而生，低代码平台百家齐放、千姿百态。有以某一个应用或者行业为基础的，从SaaS平台演化过来的低代码平台，比如非常成功知名CRM平台Salesforce，这类平台可以称为特定垂直领域低代码平台；有以代码脚手架为基础的，代码自动生成平台，它可以为专业编码人员减少部分重复的工作，从而提高效率，比如jeecg这样的平台；还有一类是号称低代码APaaS平台，是在建立一个标准的用户体系上的paas平台，平台提供有限的组件和服务，用户可以在这些组件和服务的基础之上构建自己的应用平台。
笔者以自己的背景和能力来主观的臆断（预测）各类平台的最终走向，不是什么权威之谈仅仅是一个一直从事低代码平台的研发人员的一些想法，供同道之人交流与参考。

二、 现有各类低代码平台

垂直领域低代码平台

这类低代码平台，本身就不是作为研发平台设计的，它是一个领域中的成熟产品，产品本身提供了丰富的扩展功能，比如前面说的Salesforce，还有国内的OA产品泛微。它们在自己的特定领域是成功的，它们的目标就是增强产品的能力，从而在竞争中获胜。它们本身应该是没有意愿去研发通用的低代码平台的，和低代码关联只是蹭这个热度，是一个宣传手段而已。

代码自动生成平台

这类低代码平台，本质上并没有减少代码量，只是利用工具、脚手架模板等手段来自动生成代码，减少开发人员的代码输入量，尤其是减少程式代码（有一定规律的代码）数量，所以能够提高程序员的效率，并且程序员可以对所有代码进行二次编辑，从而获得程序员的喜爱。这类工具我觉得最合适的方式应该是作为IDE的插件存在。然而一些低代生成平台在这个基础上添加了技术框架、基础功能和服务，进一步的减少研发技术人员新建项目时的重复工作。它的思路其实还是通过提供现成的代码来减少研发人员的代码输入量，而不是减少代码量，所以它本质上并不是低代码平台，而是一个研发辅助工具。

APaaS低代码平台

这类低代码平台是目前比较主流的，也是我们平时接触最多的。它们一般都提供以下几个核心功能：
1， 多租户的用户组织架构。大厂借助其早期推出的产品积累的用户，推出基于已有平台用户体系推出自己的低代码平台，是非常占有优势的。比如：阿里的宜搭借助盯盯的用户体系快速推广。其他低代码厂商，比如：明道云、简道云等等也建立了自己的用户体系，并且为了快速推广也可以便捷的接入钉钉、企业微信的用户体系。可见多租户的用户体系是目前APaaS构建的低代码平台的一个核心的部分。
2， 页面设计，包括自定义表单和大屏展示。页面设计是各个低代码平台的核心功能，是各个厂家标榜自己的特色的地方，也是实现方式差异较大的地方。各个厂商都提供了常用的表单组件，部分厂商还正对大屏推出对应的设计组件或者单独的产品。低代码平台为了降低使用人员的开发难度，在设计表单时会在后台自动生成对应的数据存储接口和数据存储方案（一般应该是非关系数据库）。这样就将表单的设计和数据模型统一起来，大大减少研发的工作量。
3， 工作流引擎。因为目前绝大多数APaaS形式的低代码平台都是面向企业单位内部的办公业务，所以工作流是一个必须的增强组件。目前低代码平台中的工作流引擎基本上就是充当一个状态机的作用，作为业务状态流转的设计工具和运行平台。
4， 业务逻辑规则引擎。大多数低代码平台现阶段这部分能力都较弱，这不是说厂商不知道这个问题，而是这是一个设计两难的问题，这部分设计了太复杂的平台的上手难度就大，不利于平台的推广，设计了简单的面向的业务场景就有局限性，目前大多数产品都是将这部分内容整合到表单设计中的，通过表单的高级选项提供。阿里的宜搭设计了连接器来实现个性化的业务逻辑，并充分利用阿里云上提供的服务来增强这部分能力。
这类低代码平台是目前的一个主流的形态，大家都这么想，应该是有它存在的道理的。但我觉得这个不会是低代码平台的最终方向，这样的低代码平台最终还是一个一个产品，它摆脱不了产品自身领域的局限性，无法适应不同业务的需求、也不能满足开发人员天马行空的想法。这类低代码平台继续发展会各具特色、各自会在某一个领域获取一定的成功、不同领域的低代码平台也可能会相互衔接，从而增持它们自己的能力，在短时期内应该还会继续发展，但是它们没有改变开发人员的研发模式，本身的局限性无法解决，所以它也不会是未来低代码平台的最终形式。

三、 低代码平台的最终形态猜想

先给出结论，低代码平台的最终形态应该是一个新的研发集成平台（IDE），软件的发展就是一层一层抽象和一层一层的封装，低代码平台应该是在现有的软件环境的基础上进一步抽象，从而产生的新的IDE平台，这个平台能力更强，对研发人员要求更低。
低代码平台作为一种新的开发方式应该是革命性，作为一个研发平台它不应该局限于某个具体应用、某个行业，也不应该局限于某个具体的技术，更不应该绑定某个具体的用户体系；作为新的开发方式它应该摆脱以前的面向数据处理的程序设计语言，采用面向业务的图形化的设计单元，来进行程序设计。
笔者认为未来的低代码作为一个新的研发方式，它一定会建立自己的一套标准。这个标准应该类似于研发语言或者关系数据库SQL的标准，它应该反映新的面向业务的设计思想、延承软件工程的成熟方案；标准应该包括两部分，一、交互页面的描述规范，它不像html那样定义详细到具体的展示方式，它只描述页面包含的组件和关系；组件的种类和数量规范不作规定，低代码平台可以对其定义和扩展，同时具体的展示方式有各个低代码平台也根据这个描述和扩展属性使用自己的技术体系自行实现。二、业务逻辑描述规范，同样它不是和CPU处理执行对应的、也不是面向过程的或者面向对象的程序语言规范，它应该是一个业务处理流程规范，描述业务逻辑的处理（步骤）逻辑单元，和不同逻辑单元之间的关系，包括顺序管理和数据传输关系；具体有哪些逻辑处理单元规范并不做规定，由各低代码平台提供。
自从软件行业兴起之时，研发人员就一直在思考如何提高效率，减少代码量就是提高效率的一个有效的手段，可以说研发人员一直在思考和实践低代码研发；笔者刚开始工时用Delphi研发mis系统，就觉得是一个神器，解决了用语句画界面的繁琐工作，大大提高的研发效率。随着技术的发展我们的研发方式应该有一个质的飞跃，像SQL标准一样改变了数据存储和分析的方式，新的研发方式一定是面向更多的领域、更多的业务，同样从业人员也会更广泛。未来的研发方式一定是低代码的、低技术门槛的，同样也是一个革新的形式，这样就必然需要一个新的规范，处于能力的不足和实践经验的匮乏笔者暂时没有办法给出一个具体的详细的规范，但是笔者一直在研发一款低代码平台，乐扣平台www.locode.net，一直在思考低代码平台最终的形式，虽然现在乐扣平台还没有将规范完全抽象出来，但我们的研发过程一直保持可以向笔者认为的最终形态的演化路径。下面一节将描述笔者理想中的低代码平台应该具备的功能和平台与规范的关系。

四、 笔者理想的低代码平台

笔者认为低代码的规范包括两部分，所以低代码平台的核心设计能力也应该是交互设计和逻辑设计两部分；低代码平台另一个核心的内容应该是它的运行平台。
新的研发形式一定也会派生新的辅助功能和工具，比如，代码（配置）的版本、跟踪调试、团队管理等等功能。另外笔者还将阐述现有的低代码平台中的核心能力未来如何演化，并融入新的平台。

交互设计

交互设计不仅包括表单设计、大屏设计还应该包括首页、框架、登录等等软件中所有可能的页面设计。作为一个开发平台，不应该对软件的形态和样式有任何限制。
交互设计应该是可视化的，并且最好是所见即所得的。平台根据用户的研发操作生成符合规范的页面。平台提供组件，每个组件应该包括三部分内容：
1， 组件在规范中的描述（数据结构），
2， 组件的可以配置的属性，在低代码平台上展示，供研发人员设置。
3， 组件的渲染方式，它根据规范中描述的组件渲染成最终的展示形式。
这些组件种类和页面的展示都是独立于平台提供的，它就像现在流行的前端框架，比如：vue、react等等。平台提供的能力就是根据规范组装这些组件。研发人员可以通过扩展这些组件来提高低代码平台交互设计的能力。为了进一步减少代码量，可以推出不同行业的专有组件。
不失一般性，针对特殊场合，组件提供扩展属性可以穿透渲染引擎，直接作用于最终的展示文档，比如：提供css样式直接作用于最终的html，这样可以提高平台的开发的普适性，尽管平台设计的目标就是减少代码量，但也要提供这样的能力。

逻辑设计

业务逻辑是变化的、复杂的，现在一些低代码平台都提供了很多行为配置页面，但只能在其特定业务范围里解决一些可以预知的逻辑问题。Mendix也提供了Microflow来设计逻辑，但感觉有和程序语言一一对应的嫌疑，依然用现有的程序设计思维来操作。笔者认为，逻辑设计应该是类似的流程，但是每一个逻辑单元（步骤、节点）应该是面向业务、面向场景的，比如：认证、加密、服务调用等等。这些逻辑单元应该包括以下三部分内容：
1， 输入和输出接口数据规范。
2， 逻辑单元的配置属性，平台根据这些属性生成配置页面。
3， 逻辑处理程序，它最总负责处理逻辑单元中的业务处理。
低代码平台，通过可视化的设计页面，把这些逻辑单元组织起来，并使用规范定义的结构描述逻辑单元之间的顺序和数据交换关系。同样规范并不规定逻辑单元的种类和数量，这部分和前面提到的交互架构一样，也应该是独立的。为了进一步减少代码量，平台可以根据不同的应用行业或者场景提供特定专有逻辑单元组件。
同样不失一般性，低代码平台应该也提供执行代码的逻辑单元，可以是现有的程序语言，比如：java、js等等，以备现有逻辑单元不能满足特定需求时使用。

运行平台

低代码平台的另一个核心内容应该是它的运行平台，它是执行平台设计的页面和业务逻辑的载体。它不应该受限于具体的技术框架，它应该是一个引擎，根据设计平台生成的符合规范的文档，调用组件的渲染程序生成交互页面，按照流程调用逻辑单元执行业务逻辑。运行时可以直接解释执行平台设计阶段产生的文档，也可以对这个文档进行一次优化预处理，从而提高执行效率。
运行平台作为低代码平台的核心部件之一，还起着应用部署的功能，所以它的部署一定要简单，并且通过它的部署来屏蔽不同应用部署的复杂性。运行平台本身可以单独部署，也可以和设计平台整合在一起以达到实施更改的能力。

辅助工具

辅助工类似现有IDE环境的各种插件，它不是必须的，但是它们可以提高效率和质量。一些辅助工具甚至是不可或缺的。

版本管理工具

现在研发人员比较流行的是git版本管理工具，低代码平台的配置文档也是文本格式，也可以继续使用git工具。但是低代码平台是设计并可以运行的，也可以研发一个和平台更好整合的版本管理工具。
跟踪调试工具
无论交互研发还是业务逻辑研发，都可能碰到比较复杂的应用场景，跟踪调试的功能对于研发人员是必须的。

文档生成工具

平台集成帮助文档的编写和发布，在研发的同时完成文档的编写，并可以将文档和业务的功能关联。

项目管理工具

低代码平台不局限于做一些简单的应用，大型应用需要多个人组成团队协助，所以平台应该集成协同沟通工具、项目文档管理工具、项目任务管理和分析功能。

其他能力

虽然平台和应用场景、业务无关，但是多年的研发工作中碰到的典型问题在低代码平台中应该如何处理。整合已有的一些系统、规范还是非常必要的。这一节说明以下，业务上常见的问题在低代码平台中如何处理。

用户集成能力

逻辑处理单元中有对应的session数据处理操作，和不同的用户体系对接就是通过不同的逻辑处理单元来修改session数据。比如：和钉钉、企业微信对接，就需要调用对应逻辑单元。同样交互设计登录页面时也可以调用OAuth2.0认证组件调整到对应的第三方认证平台。
就是这部分业务内容都不是固定在平台之中的，而是通过页面组件和逻辑单元来扩展的。

工作流引擎

工作流引擎同样也不是平台的本身的能力，它是作为一个第三方服务在业务逻辑单元中引入的。

业务集成

低代码平台研发的应用不是有一个孤立的系统，它可以通过数据直接访问、第三方服务调用的方式来整合现有的业务系统，也可以将平台研发的后台逻辑接口开发给其他业务系统调用，从而实现业务和数据的集成。

其他减少代码量的特性

低代码平台的核心目标是减少研发人员的入门门槛，让更多的业务人员能够参与到研发中。减少代码量是这个目标的一个关键手段。模板和复用是研发过程中减少代码的重要手段，低代码平台应该能够在不同的层面上发挥它们的作用。
1， 应用模板，这个类似于git上现成的项目，导入后根据用户的自己业务场景再做二次开发。是最大粒度的复用，但只适合相同行业应用。
2， 页面模板，不如：登录页面、首页框架，等等，这个可以在某一个具体的场景下复用。
3， 关系数据库增、删、改、查逻辑处理模板、流程发起和提交模板，这些可以在后台业务逻辑中针对不同的场景中复用。
4， 组合组件，多个组件常用的组合模板，比如：新闻展示模板，由一个图片、标题（文字）和正文（富文本）组合而成，可以在页面设计中快速导入这个组合，从而减少开发量，提高速度，它是更细粒度的复用。
低代码平台应该可以在各个环节通过这样的复用或者辅助工具来简化研发工作，但平台本身不能约束研发人员的创作空间。

五、 总结

笔者一直从事低代码平台的研发，一直致力于降低研发人员的技术门槛、减少业务研发人员的重复研发工作，将研发人员的经理集中到业务分析中。上述的笔者认为的理想的低代码平台应该具备的功能，乐扣平台大部分都以实现，只是受于能力还没有抽象出一个系统的研发规范。我想未来的低代码平台一定会是一个全新的研发方式，它一定也是一个普遍性的研发工具，而不是局限在某一个特定领域或者整合在某一个具体的平台当中的。