使用零代码平台构建应用，应该怎样转变思路？

Posted 2021-11-09 dotNET跨平台

最近两年，越来越多的各类零代码产品在市场上出现，与此同时，企业的数字化转型的速度也越来越快，零代码产品已然成为了帮助企业数字化转型的利器。

技术也在不断地演进，其核心目的就是让开发人员能够更专注于业务逻辑：

1、上古时代我们通过传输字节码和电子信号在物理层来完成通信，需要自己处理各种丢包、重试等网络问题，最后就出现了 TCP 协议来解决这些问题；

2、在分布式时代，解决了「三高」问题，同时也需要我们来处理熔断、负载均衡、服务发现、认证和授权、链路追踪等问题，这时很多微服务的中间件就出现了，比如：API 网关有 Ocelot、Zuul；链路跟踪有 Zipkin、Jaeger、SkyWalking；服务发现有 consul、Eureka ；甚至出现了像 Spring Cloud 这种全家桶式的框架，这些工具帮我们处理了通信细节，使开发人员使用较少的代码就能开发出健壮的分布式系统；

3、上面提到的各种中间件帮我们解决了很多问题，但对各种中间件框架的学习、排错也是一件令人头疼的事情，为了解决这些问题， Service Mesh 就诞生了；

4、再往后就出现了 Serverless 技术（ FaaS 和 BaaS ），其目的仍然是降本增效，关注业务，关于 Serverless 的详细介绍可以看看 《带你了解 Serverless 无服务器架构

零代码平台在现在的技术背景下，恰逢其时，就是为专注业务而生。但在我们使用零代码平台时，还是需要有些思路的转变，特别是如果你有技术背景更是如此，为什么这么说呢？

1、客户往往会根据自己的经验将业务背景转化为最终的实现，并告诉你该怎么做，如果是定制开发，很可能就会按照客户的思路去实现来，但使用零代码平台，发现实施时比较别扭的时候，就会去更深层次挖掘客户背后的真实想法，这样实现的功能更能符合预期；

2、技术人员会根据自己之前个性化开发的经验来使用平台，会有思维上的局限性。

下面来讲两个案例来看看怎样进行思路的转变。

案例一

某客户的一个报销流程功能有很多不同的分类，比如日常费用报销、差旅报销等，两种不同类型的表单上的字段显示差异较大，但数据源使用的是同一个。

定制开发的思路

1、将费用报销和差旅报销的所有字段都放到一张表中；

2、表单上添加一个报销类型的下拉框，当切换不同类型的时，控制相应控件的显示和隐藏；

3、保存数据时收集界面可见的控件的值即可。

如果按照这个思路在零代码平台中去实现会遇到麻烦：

1、当切换不同类型的时，控制相应控件的显示和隐藏，这时需要对每个控件去编写隐藏规则，当涉及的控件比较多时，很繁琐；

2、如果有些复杂的控制逻辑隐藏规则不能支持，还需要编写表单脚本进行处理，增加实施成本和难度。

零代码平台实现思路

1、正如上面所说，去控制每个控件的隐藏规则的成本比较高，所以需要思考在平台中有什么成本比较低的实现方式；

2、在平台中利用引用功能，可以快速创建一个相同功能，原功能和引用功能共用一个数据源；

3、原功能表单配置成日常费用报销，引用功能表单配置成差旅报销

4、在原功能上添加自定义按钮打开引用功能的表单，差异点就是之前需要打开表单后进行类型的切换，现在是在打开表单前通过不同的按钮进行选择。

案例二

某集团公司客户说我们需要一个论坛、可以发帖子供很多人讨论。

定制开发的思路

1、根据客户的要求定制开发一个论坛；

2、部署一个开源的论坛系统，但还要考虑跟现有系统的各种集成，比如单点、数据统计、提醒等；

在我们的零代码平台中暂时还没有论坛模块，那能跟客户说我们不支持吗？肯定是不行的。所以这时就需要挖掘客户到底想要什么？经沟通后发现，客户的目的就是想要有一个针对某个话题供讨论的地方，形式不一定是论坛，只是一想到根据主题讨论很容易就想到了论坛。

零代码平台实现思路

1、创建一个带流程的功能模块；

2、流程控制永不结束，在两个节点直接来回流转，可以任意选择审批人（需要参与讨论的人）；

3、接收人可以填写审批意见（主题的回复）后提交，而且流程天然有消息提醒，提交后，相关人员会收到邮件或企业微信消息提醒。

当把示例做好跟客户演示后，客户对实现效果很认同，觉得满足了他们的需求。

零代码平台可以理解为一种面向业务的语言，最终帮助客户来实现业务价值，也能够当成是一个聊天沟通的工具，和客户统一语言。在最终落地实现的时候，一定要了解到客户背后最真实的想法，然后结合零代码平台的功能，给出最佳实践。