导语：本期由蔡剑涛投稿，从低代码的发展历程、经典应用和关键定义，来分享笔者对低代码思想的理解。并结合低代码思想在配置化大屏的具体实践，谈谈个人对低代码的相关感悟。

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组件：列表 = 行模板 + 数据，效果如下：

支持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 结尾语

本文更着重分享对低代码思想的理解和配置化大屏的设计理念，为避免重点被淹没，就降低了技术实现的分享权重。由于本人水平和经验有限，如有纰漏，望见谅、指正。

#作者简介

Jamter  OPPO数据中心高级前端工程师

负责OPPO内部最大的自研可视化BI平台——InnerEye前端组，有多年的大数据领域前端经验，专注可视化、低代码和大前端。

送你一本《副业搞钱手册》pdf 电子书

关注“副业怎么搞”，回复：fuye