我们需要怎样的低代码平台

低代码概念最近很热，也涌现出了众多的低代码平台，国内比较有代表性的有雀书、钉钉、企业微信，国外的 MS Power Platform、Salesforce、Budibase 等。

低代码的方向大致有几类：

• 面向业务的，系统提供大部分成熟的能力，业务人员通过裁剪和配置，就可以很快的完成功能搭建。Salesforce、Shopify 等也可以归入此类。

• 面向业务的，抽象系统的预制能力，并提供编排引擎，让业务人员可以通过图形化编排的方式，完成功能的搭建。包括 BPM 平台、BI 平台基本上都可以归入此类。

• 面向技术的，通过构建一个应用框架，让技术人员可以服用大部分的预制功能，加上少量的个性化功能代码，完成降低编码投入的目的。小程序、云凤蝶等快速构建前端应用的平台都可以归入此类。

• 面向技术的，通过图形化编程的方式，简单的实现 CRUD 的操作，从而可以利用比较廉价的外包资源，完成应用功能的搭建。普元的 EOS，以及一些面向元模型的低代码平台都可以归入此类。

第一类低代码平台，其实称之为 Saas 平台会更合适。这些平台其实是一个成熟的 Saas 产品，提供业务人员成熟的功能，业务人员通过配置完成对本团队的适配。这部分能力，不管是 CRM 还是电商平台，以及未来我们需要提供的支付平台，都是成熟经过市场检验的，基本上有比较好的接受程度。

第二类，对于一些特定的领域，包括 OA、审批流、报表等，经过长期的沉淀和教育，基本上已经有比较多的受众接受了这部分的低代码编排方式，还有像 IBM、Accenture 等公司也有大量的咨询人员可以帮助企业完成这部分功能的定制化，所以在也有一定的市场地位。

第三类，是最近刚刚兴起的，包括小程序、云凤蝶等，对于特定的前后端功能，一些不是太复杂的也不是关键的能力，特别是后端的能力，有一定的市场。但是对一些复杂的能力，或者是对客的能力，好像还没有成功的案例。

第四类，个人对这类的低代码平台就不是太认可。这类的平台，其实就是将 java、C#、go 等代码块转换成了一些图形的组件，同时在模型的映射上往往还有从领域模型到元模型的映射工作，在效率和灵活度上其实有一定的损耗。同时对于技术人员而言，拖拽比编码要更快，这个观点很难被认可。

所以，我理解的低代码平台，其实也不是一个全新的概念，本质上和我们架构设计上一直要求的封装、组件化、容器化是一脉相承的。我们在软件架构上通过封装和组件化，沉淀了固化可复用的能力，后续构建功能的时候可以复用这部分能力，达到提升研发效率的目标。通过容器化，将一部分固化的框架能力沉淀到底层，在容器上构建业务能力的时候就不在需要考虑这部分底层框架已经预制的能力，也能达到提升研发效率的目标。

低代码平台的目标有很多，有安全性、快速制成业务、降低开发成本、降低复杂性、提升实施效率、降低维护成本、支撑快速失败等。但是我认为最重要的，低代码平台要解决的问题就是日益发展的数字化需求和数字化人才不足之间的矛盾问题。解决这个矛盾的方案无非就有两个：降低数字化应用的构建门槛和提升数字化应用的构建效率。那怎样的低代码平台才能达到这个目标呢？

首先，如果是一些固化的功能，在业界都沉淀了很多年，有很成熟的应用和模式，比如 CRM、OA、电商平台、支付平台等，那 Saas 的模式或者我们叫开箱即用的模式是最经济的。这就好比我们去买个冰箱，往角落里一放，插上电、设置一些温度之类的参数就可以使用，如果不设置参数用默认配置也能用的没啥毛病。

如果做不到如此开箱即用，那可能还需要一些开发的工作。这里就有两个思路：提升效率和降低门槛。

对于提升效率，无非就还是沿用架构设计上组件化的思路，将预制的功能封装成技术组件，然后开发人员通过编排的方式，将技术组件重混成适合本公司特点的数字化应用。典型的就是一些前端的编排，后端的小程序平台、AI 低代码平台等。

对于降低门槛，无非就是将编码转换成脚本的方式。比如 BPM 平台将通过 xPDL 定义流程编排，辅助以图形界面，将流程引擎难度的工作变成了图形化编配的工作。又比如 BI 平台，通过一些图形化的界面和预制的展示模版，将写 SQL 才能完成的数据分析工作变成了图形化配置工作。利用这些平台，加上低成本的外包，完成 OA、审批流、报表功能的构建。

所以，对于低代码，第一优先级采用开箱即用的 Saas 模式，其次采用预制功能灵活组合的模式，再次对于一些专业领域采用图形化编排加外包开发的模式，最后如果有 GPT 这样的代码自动生成工具也行 ^_^。其余的类似图形化编程的低代码平台，不要也罢。