相信低代码这个词大家经常听到，从 2014 年概念被提出，很多人就开始关注了，但是对于低代码的各种争议未有间断，有的人对它到底能否对企业、对开发者进行赋能，仍存质疑。

很多开发者也就此有很多争议，本次分享是想告诉下大家，看一看云智慧内部真实去用了一年之后的变化，将从数据可视化目前的现状，及其所暴露出来的的痛点，站在解决痛点的思路上推出低代码概念，介绍低代码引擎设计与思考，介绍数据可视化编排平台Flyfish的特点与能力、如何解决行业痛点及如何进行提效。

分享概要：

1、企业现状之下的痛点

2、低代码如何为企业赋能

3、低代码如何为开发者赋能

4、FlyFish低代码能力介绍

5、使用低代码运行一年之后的变化

01

企业现状之下的痛点

先看一下有哪些痛点，结合现有情况。大屏估计大家也经常看到，像天猫双 11 做的一些数据大屏，或者在运维场景中都能看到这种酷炫的大屏。

大屏的技术栈有很多，做大屏有时会用到一些 2D 的技术栈、效果等等，也会涉及到一些3D，甚至一些更细项的技术栈。

会经常用到很多图表的插件，比如 Echarts。再有像一些网络节点图、系统架构图业务，往往会用到一些专门画拓图、流程图的工具，像 AntV@G6、visjs 、D3-Graphviz 等，针对一些 3D 场景的时候也会做到。用到一些 Three、WebGL，甚至会用到一些对应的模型处理。

对于一些纯 3D GIS 场景，会用到一些 Cesium、Mapbox、3D tail模型、倾斜摄影，以及一些离线的方案、LOD方案等。光从技术栈上来看，就会发现很多很多。

◆ 架构复杂

然后再从架构上看，同样也是一样复杂。随便找一个日常的前端的架构，会发现需要进行很多的处理。每次都要去做这些工程的调整和配置，并且还要对大屏中使用到的控件进行一些优化处理，因为各个的控件在不同要求的屏上使用的层次深度也有所差异。

另外，我们对这种处理也不同，像一些兼容性渲染，多端适配，考虑到这些大屏有可能放到很大或是很小的屏幕上，多端的一些适配，对于一些通信的优化，动效的处理，包括实时性请求的一些处理，都是需要经过优化的，其中会很复杂。

◆ 部署复杂

除此之外，部署也很复杂，可以简单示意一下，还没有画那些像一些监控类的架构，或者是像一些 Docker 这些 Jenkins 自动化的一些东西，只是画了一下业务的逻辑架构。可以看到，我们有很多各种各样的端，像PC、H5、iOS、安卓这些小程序等等。

我们会有一些Nginx 的集群做静态服务，再做一些网关单点登录 SSO 集群。由于涉及到微服务，肯定会涉及到服务发现Nacos，以及dubbo、缓存、原数据存储、分布式文件存储，各个服务模块拆分调用关系就会很复杂。每次做的时候我们其实都是很难的，部署也很难。

◆ 痛点

站在工程的角度上看，也有很多痛点，应对需求、复杂度以及变化，归纳总结为以下几点：

除了上述所说的几点，还有信息丢失问题。在此放置了一张图片。这是一档综艺节目《王牌对王牌》，相信很多朋友都看过，是从最左边同学依次把一个词或者一句话传递给最右边同学。

看过的小伙伴可能都清楚，到了最后，基本上要么得到的信息寥寥无几，要么可能都偏离得特别远了。其实在咱们与客户整条链路沟通上，或者我们内部沟通上，其实传递可能不比节目上人员少，甚至可能更多。我们传递的时候，往往会丢失很多信息，最终发现做了的东西，与客户要的其实差得很大。

• 增效：可视化变成所见即所得，一站式开发无需搭建环境，通过拖拉拽的形式快速生成一整套解决方案。

  
  

• 高质量：开箱即用的高质量组件，同一套规则、同一套标准，经过多轮测试验证发版，稳定可靠。
• 可复用：会从原本一锤子的买卖，变成可以沉淀的资产，组件之间可以沉淀复用，数据方向可以规范标准。复用性强。
• 低门槛：由于低代码开发的特征，大大降低了开发的难度，使其可以非常快速搭建一套解决方案。无代码基础也可快速上手。