共计 3606 个字符，预计需要花费 10 分钟才能阅读完成。
作者：景庄
本文次要谈一谈网易云音乐大前端团队在面向模式化研发场景的低代码体系的建设思考和实际。本文将会从以后咱们所面临的业务研发问题登程，谈一谈咱们对于构建低代码研发体系的思考，进而介绍咱们正在构建的同时反对 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 计划，并且反对与外部既有的根底研发设施进行无缝集成，来减速模式化业务研发的效率。
在后续，咱们将持续带来更进一步的无关云音乐低代码能力建设的技术分享。
本文公布自网易云音乐技术团队，文章未经受权禁止任何模式的转载。咱们长年招收各类技术岗位，如果你筹备换工作，又恰好喜爱云音乐，那就退出咱们 grp.music-fe(at)corp.netease.com！