Low-Code Practices in NetEase Cloud Music's Mid-Platform Frontend Team

1.业务痛点

1.1 产品线较多，跨部门协同效率很低

由于跨部门支撑，缺乏其他职能角色，对接流程混乱，后端团队规模远超前端，各业务组竞相锁定人力，导致团队割裂、目标混乱，前端难以产出价值。

1.2 团队水位低，需求吞吐量很难提升

基层成员能力受限，不能有效参与日常业务，需求大量积压在头部成员手中，导致交付吞吐量难以提升。

2.如何将低代码落地到业务中

2.1 外部协作流程重构

2.1.1 分类分级保障标准

将过去混乱的产品线进行分类，把保障标准与业务价值锚定，聚焦前端资源。

2.1.2 研发元信息标准化

为了约束上游需求侧产出、理清合作边界、减少业务侧对前端的强绑定，依托内部技术产品对研发流程进行元信息标准化，为低代码落地创造技术条件。其中涉及的内部产品包括： Overmind：云音乐自研产品，具备排期、拆分任务等事项管理，人力可视化能力。 OX：云音乐自研产品，具备将 Java 代码解析为接口文档的能力，接口即文档。

2.1.3 双周评审PK机制

为保证方案落地，前端主导发起双周评审PK，需求先在后端内部PK，再根据“分级保障标准”进行分流：一部交给后端搭建，一部被挤出，为其提供必要的使用培训和落地辅导，以形成机制保障。

2.2 团队研发模式转型

在处理完流程机制问题后，需要对内进行研发模式转型。

2.2.1 混合式架构迁移

全盘重建不现实也不必要，基于微前端的混合交付仍是最优解。

2.2.2 团队站位重分配

为了提升基层人员参与度，对各层级成员进行重新站位，将过去只能由少数人员解决的问题通过复杂度抽离进行下放，实现生产力改造。

2.3 团队的高阶在做什么？

2.3.1 面向前端开发的轮子

业务特征是天天与数据打交道，可视化诉求多。基于 ECharts 封装了 React 组件，做到面向大部分场景的开箱即用，让初级工程师、外包在能够兜住底线的情况下进行快速交付。

2.3.2 面向后端的生码工具

在低代码平台上，前后端搭建理念不一致导致后端难以使用。基于平台提供的 AST 操作能力，诞生了面向后端的图表智能搭建助手——一种基于一定组合规则的引导式搭建工具，在固定交互设计下非常适合非前端研发角色。

3. 阶段数据

3.1 团队需求吞吐量

在前端团队结构劣化挑战下，依旧取得了需求吞吐量提升约 100%，有效支撑了持续膨胀的业务。进一步占比分析表明，上述举措确实让基层人员有效承接业务需求，解决了长期“头重脚轻”的问题。

4. 能得到哪些有用的经验

4.1 LowCode 核心是让开发者享受到模板红利，部分新增需求可以通过模板快速交付

相信很多研发者看到低代码会觉得，浏览器中托拉拽的搭建方式看似高级，但在可维护性、可拓展性上存在很大瓶颈，但我认为这只是产品层面的展示形式，Tango 本身基于源码的低代码方案，这些问题都不大。

低代码的核心是让开发者享受模板红利，通过减少编码工作量来换取效率提升。这种操作在 ProCode 时代是惯用操作，只不过我们选择了将模板进行在线化管理，打破过去的项目禁锢，将单个开发者可见变为全局可见，让模板红利更加普惠。

4.2 长尾需求可通过低代码模式 “换道超车”

所有项目都希望需求尽快上线，但资源有限往往导致长尾需求积压。通过低代码方式让后端形成自闭环，使长尾需求 “换道超车”，让前端开发者专注于核心业务，而不是被长尾需求拖累。

4.2 依托 LowCode 的生产方式改造，是一个相对经济的解决方案

怼人力是短期有效的方式，但在现实中要面对招聘、落地、成长等时间和经济成本。依托 LowCode 拉低门槛，让过去不能参加、不能有效参与的成员都能参与进来，是一个非常经济可行的解决方案。

5. 依旧存在的问题

4.1 业务侧资产的相对匮乏

举一个例子：为什么后端会觉得上手成本高？

直接原因是平台侧提供的物料大多是原子化组件，页面的成型完全依赖开发者对组件的组合与配置。在当前业务侧资产相对匮乏的情况下，只能依赖前端编码来弥补这部分差距。

把 “从零到一搭建” 转变为 “修改页面模板”，大幅减少页面成型的工作量

我们希望改变后端搭建页面的流程，把 “从零到一搭建” 转变为 “修改页面模板”，大幅减少页面成型的工作量，其中需要大量的业务侧资产的沉淀（样板间、业务组件封装）。 最后： 【更多岗位，可进入网易招聘官网查看 ：https://hr.163.com/】