无代码生产新模式探索

Posted 2022-07-28 阿里巴巴淘系技术团队官网博客

如何高效率规模化生产中后台页面，如何保障产品标准、质量及体验的一致性，如何提升开发效率是我们当务之急的命题。

背景

电商发展至今，供给侧升级降本提能、精细化运营是未来的关键，由此B端中后台需求井喷并呈增长态势。随着运营工作台SOP体系通过跨系统能力整合打造运营标准操作链路，解决运营操作体验及站点交付效率问题时，运营能力的产品&体验一致需要页面研发保障，提供保障体验的高效页面研发能力尤为重要。

中后台场景交互视觉趋于标准，需求链路长角色多协同成本高，现有研发方式研发核心围绕原子及业务组件ProCode大量低水平重复，LowCode事件联动，数据绑定等仍需大量代码瓶颈明显，页面生产模式亟待突破。

如何高效率规模化生产中后台页面，如何保障产品标准、质量及体验的一致性，如何提升开发效率是我们当务之急的命题。

问题&策略

目标面向工作台/大淘宝中后台，革新页面生产模式升级页面生产工具带来生产效率的提升。

主要围绕两个思路：

1. 以场景为中心。针对中后台场景特点及对大部分现有业务梳理，表单列表详情类场景占比86%，基于抽象特征提炼统一描述，固化结合领域特性标准化场景，围绕标准生产资料进行产品设计及页面研发生产能够将场景价值最大化，有效降低边际成本提升整体生产效率。

2. 以流水线式为出发点构建全局最优的生产模式。本身整个生产过程可以看做是有序的且包含多个角色，围绕产品功能本身做不同部分、环节生产加工的流水线，将各环节加工产物标准化并流转，提供适配不同角色的工具，提升整体协同生产效率。并且希望站在全局最优效率的角度去看整个生产链路，而非单一解决某个角色或环节的问题而粗暴将工作量转移，并且根据必要性，可转换性，可替代性构建新的生产模式。

整体方案

协同模式升级：通过设计与前端的标准场景规范定义，沉淀场景物料，以场景为中心，产品围绕场景设计、页面围绕场景搭建、接口基于场景配置推导，改变各角色的生产关系，缩减转译环节，提高整体交付效率

研发模式升级：构建无代码UI生产能力基于场景无代码配置生产（包含联动交互、条件渲染，数据绑定等完整功能）页面并生成数据API需求描述，后端按要求提供及绑定API后完成研发。

产品标准及体验保障：基于标准场景页面全流程无代码研发，保障产品设计和技术实现的标准及产物质量。同一体系内都呈现一致的交互语言和产品调性，降低用户学习成本，提升业务使用体验。

技术架构

场景标准化

平台架构以场景为中心，产品围绕场景设计，页面基于场景搭建，API 数据结构根据场景定义。因此，要定义出场景，收敛并标准化沉淀。

首先场景是基于中后台常见的产品模式和功能板块拆解，对交互形式、接口数据结构进行标准化收敛后，提取出的功能高度收敛的场景物料和场景控件。

从技术上定义来看：

1. 按UI体系原子化设计的粒度划分，场景物料属于模版粒度，比如，基础查询场景包含筛选表单、操作区、展示表格、翻页器，是页面内的大区块；场景控件属于组件和模块的粒度，比如员工选择器、日期展示组件等。

2. 从能力上看场景物料和场景控件具有业务属性，内置了业务相关逻辑和API数据请求，比如：Fusion Table 是纯 UI 组件，AntD ProTable 封装了翻页、筛选等预设逻辑，查询场景物料还额外封装了接口请求处理，标准了场景所需要的接口及其数据格式即场景模型。

场景内置核心功能，并预留一些扩展能力，通过场景控件扩展场景中输入/展示/操作等 UI 组件，通过能力插件扩展条件渲染、联动执行等非 UI 型能力。场景与控件正交组合，再结合能力插件，就构成页面区块的完整功能，多个区块布局组合就构成完整页面。

围绕上述核心逻辑，我们构建了完整的场景标准化体系：

1. 制定场景规范：成立场景规范小组，结合业务场景诉求，制定各场景统一的交互样式和接口数据规范。

2. 建立场景沉淀机制：对于与现有场景完全不同的新场景，先按业务诉求梳理场景案例，对功能抽象分类，再经由场景规范小组评审，设计出符合规范的场景，最后开发并沉淀场景。对于与现有场景相似但有定制化诉求的，拆解出要扩充/定制的能力，同样经过小组评审后，在现有场景上进行迭代。

3. 构建场景生态体系：围绕整个大淘宝中后台域，构建整体场景标准及多业务域协同机制，统一管控及沉淀标准场景。并提供自定义物料研发套件及接入能力，以支撑更大范围业务场景。

数据标准化

数据标准化核心为模型定义，数据模型生产及数据实体生产三个环节，将基于场景标准化产出的场景物料对应的API及其所需字段通过场景化搭建配置组合业务模型中的字段生成具体所需API及字段，后端根据API需求提供并绑定API实体完成页面所需API的标准化生产。

模型定义，基于现有页面API结构的拆解，主要有这几部分：

1. 网关模型：描述工作台网关封装的数据结构，包含接口成功失败标识、错误信息、网关额外的调试信息等。网关模型固定，对工作台所有接口都有相同的结构。

2. 场景模型：描述具体场景涉及的所有接口的结构，包括场景内固定的入参、返回值字段，以及如何通过场景配置引入的业务模型字段。

3. 业务模型：描述实际业务中的概念、涉及对象及其属性，包括字段、类型、含义等。同一个业务模型可以用于多个产品页面。

模型或者说标准的定义并不一定是定义本身多先进，而是大家认可并且能够遵循。因此在整个工作台维度我们成立了覆盖全域产品后端的规范小组，通过整体Review，RFC机制保障模型的标准及有效，通过每个团队的接口人推进规范落实及收集反馈持续优化。

数据模型生产：有了上述三个模型，就可以在使用平台研发时，通过选择业务模型字段并关联到场景配置中，进而推导出页面所需的接口定义（入参和返回值的字段结构）。技术上类似模版引擎，场景模型是模版，将业务模型字段填充到模版中的占位符，最后再套上网关模型的固定结构，就是期望的 API 数据模型。

数据实体生产：后端按照推导出的 API 接口定义来标准化实现接口，同时我们也基于场景标准构建了通用的Java类，比如分页列表类、级联查询类等，配合一些工具函数，将 DO/DTO 快速转化成 VO，降低接口表现层的研发成本。大部分情况下比如新业务后端都相对能够较好的按照所产出的结构提供数据，但是针对一些存量接口，二方服务依赖较多的接口等情况后端改造及适配成本相对较高，我们也提供了字段组合映射能力及服务编排能力，以更低成本将非标接口快速转化成推导出的 API。

无代码页面生产

无代码核心目的是通过场景标准沉淀的场景物料及数据规范完全无代码生产完整功能页面并驱动页面所需API数据结构的生成，以解决现有研发效能低，体验&质量难保障及前后端联调等协同问题。

页面由UI、交互、数据构成，场景标准化和数据标准化保证了研发资产（场景和模型）是收敛的，已经有了 UI/交互/数据的结构化的大框架，只需要少量的研发工作就完成页面研发，而对于简单的结构化的页面研发，高效的方式就是可视化配置。

从场景的角度出发，剩余的研发工作主要有场景配置、多个场景布局和联动、一些全局数据的贡献等，都可以收敛并抽象成可视化配置。全流程无代码可视化配置能降低非前端上手门槛，进一步提高交付质量和研发效率。

与低代码的差异？相较通用低代码研发平台，我们基于标准场景搭建将非UI部分的交互逻辑和数据对接等也进行了抽象和更深层次的能力封装，去除手写代码的负担，使得全流程无代码研发成为可能。

1. 标准协议：以集团低代码协议和 OneAPI 2.0 协议为基础，补充场景模型、业务模型、网关模型、联动布局等协议，构成完整的无代码协议，同时支撑研发配置和运行渲染。

2. 研发资产：场景中心输入场景和场景控件，模型中心输入网关/场景/业务模型，共同作为标准的研发资产。

3. 研发配置：页面研发可以分为UI/交互/数据三个方面，从UI入手对单个场景进行配置，包括条件渲染、参数传递、全局筛选等功能配置，对多个场景组合布局，交互上配置场景间的联动关系，数据上将API推导的接口定义绑定到后端实现，就完成完整页面研发。结合实时预览和接口mock可以一边配置一边快速查看效果。

4. 构建发布：配置信息整合加工后，产出页面schema和API数据模型，然后提取组件依赖，结合脚手架生成代码并更新仓库，最后构建发布到CDN。除了常规的页面应用，也支持将页面构建发布成微模块。

5. 运行渲染：使用集团低代码渲染引擎解析页面schema，渲染布局、场景和场景控件，使用联动流程调度引擎处理整个页面的联动逻辑，接口请求则由场景自行发起和处理。

One more thing - 中后台研发效能度量

年年效能持续提升但是还是没变化？效率是中后台研发的核心目标之一，目前业界和集团内缺少兼具普遍性和实操性的效能度量方案。因此，有必要建立通用可行的中后台要能衡量对比中后台源码/低代码/无代码三种研发模式，覆盖研发及联调完整生产环节的效能度量模型及方案。以数据化方式度量项目、个人、团队的研发效能并指导未来效能提升的方向。

▐  现在方案的问题&策略

1. 效能度量方案仅停留在代码复杂度层面，采用霍尔斯特德复杂度来度量，无法衡量项目变更的复杂度变化，无法解决中后台源码/低代码/无代码三种研发模式的效能对比。创新性地设计归一化最小作用域复杂度模型，解决变更和不同研发模式统一度量问题。

2. 大部分度量方案没有针对研发全链路更细致的度量指标。中后台效能度量方案从微观和宏观的研发、联调时长出发，结合研发流程，计算过程指标和结果效能指标，并提供效率提升的分析依据和量化基准。

▐  核心方案

1. 定义效能指标及计算公式：分析拆解效能的度量指标，建立效能指标计算公式。研发效能 = 归一化复杂度 / 研发总耗时 = ( 最小作用域差量复杂度 / 研发模式标准页面复杂度 ) / ( 连续研发工时 + 连续联调工时 )。

2. 构建复杂度度量模型：改进霍尔斯特德复杂度算法，引入代码Diff、依赖分析、AST分析，搜寻差量代码的最小作用域，计算变更引入的复杂度，解决目前业内霍尔斯特德复杂度无法评估变更效能。

3. 构建连续时长度量模型：预处理源码/低代码/无代码研发和联调操作的打点数据，按时间进行阈值分隔，动态构建活跃会话窗口，计算连续研发时长和连续联调时长。

4. 标准页面归一化：对不同研发模式的页面分层采样，统计场景频次和占比，构建标准页面，用于归一化项目复杂度，解决不同研发模式语法信噪比不同导致的复杂度比较问题。

5. 完整度量计算链路：归拢中后台三种研发模式，设计度量采集、数据加工、指标汇总的完整链路，为提供效率提升的量化基准和分析方向

总结

▐  一点感悟

• 关于低代码/无代码

由于近年来各种LCDP/Low-Code概念太热各种方案及平台层出不穷，导致不少偏执的认识。部分人粗暴的把所有研发内容可视化，比如一些仅仅是把写代码的过程转化为可视化过程的产品，针对某些人群在某种程度上是降低了门槛，但在真实生产中效果有限定位尴尬。另外一种声音是完全否定，只要是听到相关名词就觉得是重复的，或者说觉得做不到、效果一定不好。很多过程的配置化、可视化确实不适合就如前面的描述。但是无法否认的是可视化方式更直观、约束更强、门槛更低，核心考量在于具体的场景，研发环节及内容抽象度及合理性，能否标准化，配置是否足够友好，目标用户及所解的命题。

• 关于新工具学习使用成本及收益

对于解决问题的新工具如何考量自身学习和使用的投入产出，主要三个方面：权衡取舍，成本、边际量。直白说如果需要获得的是编程技能，那用这类研发工具那是不适合的。如果你有大量的页面生产工作，并且期望高效的完成，那投入成本学习是有价值的。所以很多时候要客观理解具体的使用情况及反馈（当然是在工具真的能解决问题的前提下）。

• 关于研发生产

我们大部分时间开发其实本质就是在做某种逻辑的转换，而不是做什么设计，如何将人肉繁杂的处理过程、协同过程转为更高维度的抽象，各角色围统一模型有机协同生产，带来整体提效是需要持续探索的。而不是单一的构建一个工具、能力粗暴转移工作量，仅仅解决一个角色自身问题为出发点。

▐  一些结果

完成无代码平台初步建设，实现多角色协同生产，缩减非必要的转译环节，提高页面生产效能。定义场景标准，沉淀25个标准场景，场景业务覆盖率达到96%；沉淀39个场景数据及81个业务数据规范。构建统一的中后台研发效能度量方案Orca-Efficiency能够度量完整页面研发及联调过程，可度量及对比ProCode、LowCode、NoCode三种研发模式。

平台全年支撑200+需求/项目迭代，覆盖大淘宝商家、商品、营销、智能人群运营全业务产品整体新需求覆盖率79%，并支撑直播域，X业务等10+产品构建。根据统一效能度量无代码模式效能相较源码提升5倍，低代码提升1倍，完整协同及生产提效68.6%。并且通过标准场景及无代码方式有效保障产品体验&研发质量。

✿  拓展阅读

作者|俊希（卢俊希）

编辑|橙子君