网易云音乐低代码体系建设思考与实践

本文主要谈一谈网易云音乐大前端团队在面向模式化研发场景的低代码体系的建设思考和实践。本文将会从当前我们所面临的业务研发问题出发，谈一谈我们对于构建低代码研发体系的思考，进而介绍我们正在构建的同时支持 LowCode 和 ProCode 在线研发的在线快速研发能力。

业务研发现状

先看下的我们的业务现状。伴随着业务的快速发展，出现了大量的平台化产品，其中公共技术，质量保障，数据智能相关的平台有 40 多个，另外云音乐主站，Look 直播，音街 还有大量的 CMS 平台，和各类的 web 应用。并且，这个数字还在不断的增加。而另一方面，无论是 CMS 平台，还是活动类页面都呈现着明显的模式化特征。这就意味着，开发者所面临的大量的开发需求其实是重复类似的。

而我们的研发现状是：大量的业务需求和低效的研发吞吐之间的矛盾。 我们不妨以不同视角来看下对于研发现状的一些心声：

产品同学经常抱怨：只是改个文案，前端却需要排 2 周，还要合并需求发布，怎么能这么低效；后端同学经常会碰到：一些内部系统体验不好，要改 UI，得找前端资源来排期，但前端没有资源来做；而前端同学则面临的是：业务需求很多，每个都很急，简单重复的需求，没有设计稿，我很难有技术上的成长！

这里我做了一个简单的数学统计，在中后台，前端人均支持平台 3.3 个，平均交付周期在 2 周左右。右图是一张来自 Muse 平台第 20 期的需求清单，你会发现大量的需求是类似于 “改文案”， “加字段” 等琐碎细节，但这些问题却需要多方协同，排期开发。

业务快速发展中的应用开发困境

为什么会出现这样的问题？我认为，可以从 4 个方面来拆解业务快速发展中的应用开发困境：

• 首先是 人员，一方面人员的流动性是难以避免的，另一方面，全栈型的开发者在当下是极为稀缺的。
• 其次是 变化 ，因为需求总是不断在变化的，而迭代的周期却越来越短。
• 第三是 复杂，一方面是技术体系变得越来越复杂，另一方面是研发依赖变的越来越复杂。
• 第四是 脱节，一方面是 需求与开发交付的脱节，另一方面是长流程与快速交付的脱节。

从关注应用开发到关注业务的交付

我们该如何应对？我的思考是需要让一线开发者 “从关注应用的开发过程转移转向关注业务的交付过程” 。

传统的业务开发过程我认为是一种线性的应用开发过程，需要经历需求沟通，开发测试，再到发布部署几个环节，这个过程往往依赖多个工种在不同环节的专业分工，所以存在较高的沟通协作成本。并且开发者会过多的关注于灵活分散的本地开发工具，以及复杂的 web 应用架构，从而忽视了业务交付本身。

我认为，理想的开发过程应该是非线性，业务的变化，可以被快速的响应，多种研发角色都能低成本的使用低代码的方式介入到交付过程中。而这依赖于标准化和集成化的快速研发能力，以及更加轻量可控的 web 应用架构。

云音乐在线快速研发交付体系

基于这样的思考，我们一致认为需要构建一套快速研发交付体系来应对业务的变化。通过这套体系，我们可以去有效串联公司现有的设计规范，开发模式，开发工具，和基础研发设施。于是，我们在云音乐技术中心立项了 “探戈低代码” 项目，探戈是一种优雅的双人舞蹈，隐喻我们致力于为业务研发交付带来的全新体验。

云音乐探戈低代码项目的核心优势包括三个方面：

• 基于源代码的可视化搭建能力：它提供了从源码到源码的可视化搭建体验，不依赖特定的 DSL 和也没有私有的搭建协议，做到与前端框架无关，支持 LowCode & ProCode 双模式在线开发能力。
• 与既有研发设施无缝集成，提供一键应用创建和发布部署能力：能对前端部署平台，对接版本控制系统 Gitlab，并完全复用现有的物料体系。
• 提供对接契约联调和模型驱动的能力：支持与云音乐现有的契约联调模式对接，提供设计器内的自动化联调能力，并借助后端元数据中心的应用接口模型信息构建自动化的页面生成方案。

传统低代码搭建方案的弊端

在讲云音乐的低代码的技术方案前，我们不妨首先分析下传统低代码搭建方案所存在的问题：市面上绝大部分的低代码方案都可以用下面这张图来进行描述。核心在于将视图逻辑转换为 页面描述 逻辑，在此基础上构建 节点模型和属性模型，进而借助对模型的操纵变更来修改 视图逻辑。

这里的问题在于，搭建引擎的设计者通常需要首先去定义这里的 页面描述协议 ，通常采用 JSON 的方式进行描述，受限于特定的业务场景和开发者的个人喜好，这里的协议设计存在非常多的不确定性因素，很容易导致协议的不一致性和后期的维护问题，由于需要与编程语言进行对等映射，这种私有的搭建协议方案，也很难做到图灵完备。

简单总结一下，我认为这类传统的低代码搭建方案有三个较为明显的弊端：

• 采用私有的搭建协议，导致协议设计成本高，难以长期维护，难以做到图灵完备。
• 依赖特定的 DSL 方案，使得物料一定程度上受限于特定的搭建方案。
• 由于上述两个原因，导致只具备单向转码能力，一旦输出源码，过程不再可逆。

云音乐基于源码的低代码方案

我们需要重新思考低代码搭建的协议设计问题，我们期望新的搭建协议需要足够通用且易于理解，易于维护，甚至不用维护，易于操纵，并且能够做到与前端框架无关。这个时候，我们想到了 AST（Abstract Syntax Tree），也就是编程语言源代码的抽象语法树，它用于表示源代码结构的结构化描述。对于 JavaScript 语言而言，Babel 已经提供了面向 JS 语言的 AST 解析和生成能力，借助于 Babel 的工具函数可以很容易的实现对源代码节点的操纵和变更。

因此，在探戈低代码体系的可视化搭建模型，我们采取的核心思路是：将源代码解析为 AST ，在 AST 的基础上进一步抽象和建立 文件模型 和 节点模型，通过将视图的拖拽配置行为转为对 AST 的操纵和修改，进而将变化后的 AST 重新还原为源代码。

LowCode & ProCode 双模式实时切换

由于采用了完全基于源代码的低代码搭建方案，在云音乐内部构建的低代码平台能够同时提供 LowCode 和 ProCode 两种研发模式，并且两种模式中用户的行为可以做到完全对等，用户在设计视图中的行为都会实时的同步到源代码中，而源代码的变更也可以实时的反映在设计视图中。借助于这种双模式切换的能力，可以为一些进阶场景提供更加灵活的线上研发体验，并且，用户在本地创建的源代码项目也可以采用兼容模式在线继续开发。

与既有研发设施无缝集成

对于云音乐的探戈低代码体系而言，在构建了 LowCode & ProCode 混合研发模型的基础上，我们更加关注于与内部既有研发设施的集成上，从而进一步加速业务研发效率。探戈平台提供了与 Gitlab 集成能力，用户的每一次保存操作都会将源码写入到 Gitlab 的仓库中；提供了与研发平台的集成能力，可以一键快速创建应用，并可以一键部署和发布应用；提供了与物料中心的集成能力，可以快速消费团队内的二方，三方组件包；提供了与数据网关的集成能力，借助于契约联调模式，可以在线快速生成页面；提供了与 D2C 的集成能力，支持从设计稿一键生成代码。

契约联调和模型驱动能力

云音乐的研发体系中建立了契约联调的研发模式，提供了接口契约及其变更管理，接口自动化 Mock 能力，并且借助代码自动化分析中心提供的应用的基础元数据，可以为探戈低代码平台提供强有力的应用数据模型和服务支持。目前云音乐的探戈低代码平台已经初步构建基于契约联调模式的在线自动化联调能力，基于应用元数据的模式化页面自动化生成能力也在推进过程中。

One More Thing：基于源码的低代码引擎

在构建云音乐探戈低代码体系的过程中，我们将核心的低代码能力进行下沉，抽象并构建了基于源码的低代码引擎的生态体系，一方面为平台侧能力提供了更加解耦和易于维护的底层方案，另一方面借助与多方团队合作来共建公司内的低代码生态体系。

借助于探戈低代码引擎，在内部我们重新启动一个低代码项目时，只需要 30 行代码就可以轻松的完成整个低代码项目的前端实现，开发者可以将更多的关注点放在服务集成和用户功能上，从而极大的降低了内部的试错成本。

小结

最后，简单回顾下我们在云音乐正在构建的低代码研发体系。为了应对业务研发过程中的问题和挑战，结合云音乐的业务研发现状和技术体系现状，我们认为采用低代码的方式来构建在线快速研发交付能力，可以有效的应对模式化业务研发场景中的问题，并且可以简化前端开发流程，赋能多种业务研发角色，为此我们构建了云音乐探戈低代码研发体系，该方案完全基于源代码方案，不采用私有搭建协议，不依赖特定的 DSL 方案，并且支持与内部既有的基础研发设施进行无缝集成，来加速模式化业务研发的效率。

在后续，我们将继续带来更进一步的有关云音乐低代码能力建设的技术分享。