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