InnerEye低代码大屏——低代码思源与实践
01 前言
参天之木有其根，怀山之水有其源。当前低代码市场已呈燎原之势，那何为其星星之火？笔者认为是低代码思想。
低代码思源：土壤与根
本期将从低代码的发展历程、经典应用和关键定义，来分享笔者对低代码思想的理解。并结合低代码思想在InnerEye配置化大屏的具体实践，谈谈个人对低代码的相关感悟。
02 低代码的发展历程
2.1 Low-Code术语起源
2014年，全球最具影响力之一的研究机构Forrester，在一篇名为《New Development Platforms Emerge For Customer-Facing Applications》分析报告中，首次提出"Low-code platforms"低代码平台概念。
摘自：《TheForrester Wave™: Low-Code Development Platforms, Q2 2016》
2.2 低代码发展历程
"Low-code platforms"概念虽是2014年被权威机构提出，然而其仅仅是对当时低代码开发平台的一种label、category，其发展历程远早于2014年，最早可以追溯到20世纪80年代。
低代码发展历程
2.3 低代码经典应用
为了具象地呈现低代码开发平台，笔者分别罗列了基于窗体可视化组件进行编程的VB、面向儿童的图形化编程语言Scratch、前端早期开发利器Dreamweaver的操作界面，以及能适配各端的DSL工具uni-app。具体如下：
VB：可视窗体开发，编排视图、定义事件
Scratch：让儿童写代码，图像化编程语言
Dreamweaver：配置出代码，所见即所得
uni-app：DSL工具，开发一次，多端覆盖
2.4 笔者接触的低代码场景
除了以上开源、商业化的低代码开发平台和工具，笔者还在前端职业生涯中，接触过如下低代码场景：
(1) 电商首页管理（PC和H5）
核心功能：后台配置系统支持线上更换图片、模块增删和拖拽编排等，前端免打包部署。
(2) 应用生成
核心功能：按照配置平台给定模版，编排特定业务领域的应用（包含首页、搜索列表页、详情页），并支持应用发布。
(3) 算法流程编排
核心功能：支持各类算法组件的自定义和算法包上传，并基于svg实现工作流编排，形如阿里云的机器学习PAI。
阿里云的机器学习PAI：可视化建模
(4) 低代码大屏
核心功能：支持数据建模，并提供丰富的图表库，能够在0.5～1小时内配置出精美大屏。
InnerEye低代码大屏
本章节介绍了低代码的概念起源、发展历程、经典应用和个人实践场景，不仅是为了增强大家对低代码的感官认识，也是为了告诉我们软件从业者，低代码其实离我们并不遥远。
03 低代码的定义
除了感官认识，我们还需要有相对统一的定义，才能进行更准确、更深入的讨论。
3.1 LCDP的定义
LCDP全称为“low-code development platform”，笔者摘录了6个较为权威的定义及其出处，具体如下：
6个权威定义
在形形色色的LCDP定义中，我们不难捕获到一些具有共性的关键字，其词云如下：
LCDP词云图
3.2 Gartner对低代码定义的广义化：低代码迈向云服务（低硬件、serverless）
除了上述常规定义，在一些文献或语境我们不难发现，支持云部署已成为低代码的重要特性，低代码的定义已经被广义化：低代码迈向云服务。个人认为权威研究机构Garnter“功不可没”，有如下两个标志性事件：
(1) “aPaaS”概念的提出
2014年，权威研究机构Garnter在报告中《Magic Quadrant for Enterprise Application Platform as a Service》提出了“aPaaS”概念，强调了非技术交付人员能够通过云服务构建、部署应用，其对aPaas的定义如下：
中文定义：为应用服务提供开发和部署环境的云服务
(2) 云服务厂商被纳入低代码厂商
2021年，权威研究机构Garnter在报告中《CompetitiveLandscape: Enterprise Low-Code Application Platforms in China Platformas a Service》将低带码厂商分类四类（云服务厂商亦纳入其中）：
Gartner定义的四类低代码厂商
从低代码迈向云服务的趋势来看，笔者相信企业内的云平台相关部门，更有优势做出具有企业级影响力的低代码产品。
(3) 低代码思想的定义
前面两小节我们重点介绍了LCDP定义及其广义化，除了为了统一沟通语境，也是为了进一步回归低代码最原始、最底层的思想，个人作定义如下：
对业务领域进行抽象封装（建模），并转化为可配置、可编排、可复用的图形化编程语言或模式，从而达到消除或减少手工编码的作用，进一步达到降低编程门槛、降本增效和普惠数字化等目的。
如果对低代码思想进行更深一层的归纳，我认为其核心是：抽象、复用。
低代码思想的两大利器
04 低代码思想的一般指导过程
当前低代码的实践场景十分丰富，技术的实现跨度也很大，难有一招鲜吃遍天的技术银弹。但是在方法论层面，我们确实可以抽象出具有指导意义的一般过程，以下是个人的浅薄总结。
4.1 领域收敛（自洽闭环）
要旨：做减法、确定边界、寻找可标准化场景
4.2 领域建模
要旨：对领域内的各模型对象进行封装抽象（一般会有两次抽象过程，第二次是对程序实现的抽象）
4.3 模型可配置化
要旨：为各模型对象的基础属性提供配置化能力
4.4 模型可组合化（编排化）
要旨：为模型对象的位置和关系提供编排能力：平移、分组和结构化等
05 低代码思想在InnerEye大屏的应用
5.1 低代码大屏的产生背景
产生背景既是孕育思想的土壤，也是思想实践的用武之地。当初笔者决定探索低代码大屏这个方向时，主要基于如下几点考虑：
a. 不少业务方有大屏需求：汇报、活动战报、展厅播放、美化看板、监控、 目标管理等
618电商作战大屏（数据已特殊处理）
b. 许多业务方有需求，但是无技术，或有技术但无人力（实现成本大、周期长）
全球用户数据大屏（数据已特殊处理）
c. InnerEye早期从开发到上线一个大屏，周期长（3～4周）、投入成本大、复用能力低
定制化大屏的痛点
d. 符合InnerEye产品方向演进：大屏本质是精美看板，InnerEye拥有大屏所需的底层数据、建模能力和庞大用户群
InnerEye是OPPO内部最大的自研可视化BI平台，当前服务250+部门，约5千+用户
5.2 遇到的困难
虽有做事初心，但是要把事情做成，依旧挑战重重，具体如下：
工程巨大，实现有难度（组件繁多、交互复杂、涉及复杂的数据通信和存储，对抽象能力要求高）
创新风险（价值尚未被广泛验证）
未正式立项，没有迭代人力
淡淡忧伤
5.3 大屏基于低代码思想的具体实践
(1) 领域收敛（自洽闭环）
在千头万绪、无从下手之际，突然想起了贝佐斯的一句话：要在变化中找到不变，此念想引发了我正确的思考：
于是我开始做减法，不再徘徊于业内的大屏实现，不再兴叹于万千组件之间，而是罗列出了四个基本问题：
1、 将组件单元的配置化做到极致（尽量满足各种自定义需求）
2、将组件单元间的布局、组合做到极致（grid布局——显示屏布局原理）
3、将接口调用、数据读取配置化（将与后端的联调开发工作转换为配置工作）
4、动态列表生成：列表 = 行模板 + 数据（模型驱动视图思想）
亚马逊创始人：杰夫·贝佐斯
在领域收敛后，我找到了做事的抓手，并将上述四个基本问题，作为MVP最小验证模型的实现目标。
(2) 领域建模（封装抽象）
基于四个基本问题（场景），笔者对领域场景内的对象进行了更细化的抽象，具体如下：
领域场景的模型抽象
(3) 模型可配置化
为了把组件的属性配置做到极致，笔者挑了Echarts饼图进行充分验证（对所需属性尽量实现配置化），效果如下：
饼图配置化
为了实现组件支持多种数据源，笔者选用了文本组件作为实现范例，实现数据源支持静态文本、内置接口、外部接口(配置化调用)、父组件传值，并提供函数能力如数据格式化、时间组件等，在技术上是对富文本编辑器Quill进行改造，使其支持函数编译，效果如下：
富文本组件（多种数据源、读取方式、函数能力）
对于表格需求，我们需要支持动态列表，且每一行的样式，应该支持灵活组合，笔者基于“模型驱动视图”的思想，设计了支持Row容器的list组件：列表 = 行模板 + 数据，效果如下：
(4) 模型可组合化
为了使组件的布局编排做到极致，笔者借鉴了显示屏绘图原理，在具体实现上使用了vue-grid-layout组件，并实现了多个组件的分组，效果如下：
为了方便同时调整多个组件的位置和对齐，笔者借鉴了Flutter Row和Column组件的容器思想，组员也积极发挥创造力，在vue-grid-layout组件基础上实现了更为复杂的网格容器，效果如下：
5.4 方案验证
2022年6月份，在没有占用迭代人力情况下，笔者带领前端小组加班加点，快速完成了最小验证模型，并通过配置化还原了两个大屏，均在小时级别内完成，效果如下：
验证大屏一（数据已特殊处理）
验证大屏二（数据已特殊处理）
5.5 效能提升
(1) 手工编码大屏的成本——不少于10万、且难以复用
早期InnerEye定制化开发一个大屏，从需求到上线大约需要4周（20日工作日，近一个月），除了业务方，落地团队一般包含5人：1产品、2前端、1后端、1设计，假如人均成本每月按2万算（实际上应不止），那么一个大屏的成本就是10万，且复用能力低。
(2) 低代码大屏的提效——节约15～20倍成本、且能高度复用
借助于低代码配置化能力，前端团队几乎提供了一条龙服务：需求对接、UI设计、大屏开发、发布上线，时间周期从4周缩短到了1天，最快到1个小时，至少节约15～20倍成本。而且由于打通了底层能力，我们可以通过不断承接业务大屏需求来完善组件体系，既能避免闭门造车，又能为创新持续注入人力，且新增的组件后期能高度复用，做到了业务贡献和基础建设两不误。
5.6 业务贡献
完成所有技术验证后，我们开始紧锣密鼓对接业务方需求：海外业务大屏、通信大屏。在一周内最快完成了5个大屏，再加上内部使用的两个大屏，总共完成了13个大屏，整体节约的人力成本在百万级，也收到了来自业务方的感谢信。
合作案例：海外业务、通信
06 个人感悟
业内关于低代码的争议，由来已久，而拥趸对低代码的探索，却从未止步。面对争议与未来，笔者也分享下个人感悟：
1、低代码更应是一种思想、方法论，不要拘泥于其具体形式
2、低代码不是技术银弹，不要强求它同时满足所有场景；但它的两大思想利器——抽象、复用，相信始终能为你所在业务领域降本增效
3、“低代码”不仅是“低代码”，而且是“低设计”、“低部署”和“低维护”，贯穿整个软件生命周期，乃至“低硬件”
4、低代码的终极未必是无代码，低代码可能是在无代码基础上提供了专家编码模式
07 结尾语
本文更着重分享对低代码思想的理解和配置化大屏的设计理念，为避免重点被淹没，就降低了技术实现的分享权重。由于本人水平和经验有限，如有纰漏，望见谅、指正。
推荐阅读