“打通设计与研发效率最后一公里”-云事业部前端团队 D2C/C2D落地经验分享

🧭 概述

京东云前端团队与Relay设计平台团队进行联合共建，通过提出C2D2C（Code to Design to Code）模式 ，将云事业部Mobius Design System 设研资产打通，实现“一套资产，双向流动”，进一步解决设计师精力分散，版本代差问题和D2C效果有限的问题。

🕵️ 起因

京东云前端 业务组件库 去年快速发展，积累了 140+ 个业务组件，供各业务线使用，累计提效 840+人/天，节省人力成本近 300W+。基础 UI 组件库 Mobius 也逐步适配了 科技前端委员会牵头打造的 B端设计体系 - JDT Design Token ，解决了部分设研协同效率问题。但我们不想止于提升自身职能的研发效率，更期望站在更高视角去尝试提升研发上下游链路的协作效率💪💪💪。经过团队内部的脑暴与讨论，最终定位聚焦提升设计师与研发协作效率。同时，目前主流设计平台(eg. Figma/RELAY )的设计理念与前端很多概念是对齐的，于是我们进一步思考是否可以将设计与研发资产进行同源改造。目前设研资产不同源会导致以下问题：

1. 设计师精力被分散：基于基础组件+业务抽象而成的高级组件、业务组件，虽然它们和基础组件相似度很高，设计同学还是要花费人力进行设计资产的研发（画组件、DesignToken 绑定、交付前端同学编写组件代码、发布设计师可用的 Axure/Figma 元件）等一系列操作。
2. 设研资产存在版本代差：DesignToken 维护时在设计同学、前端研发间 经常会出现忘记绑定、Token 变更同步不及时、版本偏差等问题，需要在两端同时查找原因，且难以主动发现问题。
3. 无法完美达成 Desgin To Code 效果 ：当前 D2C 只能达成基础效果，出码能力及后期维护成本较高，且没法识别前端私有物料资产。

于是我们进行了 “设研资产同源” 改造尝试 🏃‍♂️🏃‍♂️🏃‍♂️，期望解决以上问题。\
解决思路即 C2D2C 模式提炼如下👇️👇️👇️：

1. 先通过 Code To Design 解决设研资产版本代差问题
2. 再通过设计平台 Plugin 能力管理并关联 Design Token 达成设计体系级别的主题管理能力(设计资产 + 前端物料)
3. 最后基于设计平台 Design To Code 的能力达成设计稿转代码/组件，即让研发同学只专注于业务逻辑填充即可

💁‍♂️ 一起看看 去年 第一期 的结果

基于京东云前端组件库 Mobius 自动生成 Figma 控件（以 Button 组件为例），一期已生成 10+ 个控件。

设计师使用 Figma 控件（UI 控件也具有 hover/click 等

修改 DesignToken，更新到 Figma 变量、生成CSS/SCSS/JS等等变量文件，将新主题应用到页面中（页面以组件库文档为例）（修改了圆角 sys.corner.regular 和 主题色 sys.color.brand)

🧠 可行性研究

在确定方向初期，需要先思考大致的实现方式，会不会遇到不可解决的问题。对于针对京东云组件库的 C2D2C，会考虑以下几个问题：

1. C2D 过程中，将组件 HTML/CSS 转换为设计控件时，由于元素的 CSS 样式效果未必能够和设计软件提供的能力一致，例如 CSS 中的 flex 布局非常灵活，在 Figma 中只能使用 AutoLayout 来实现一部分效果。

   思考：对组件库来说，代码集中在1-2个仓库，且维护人员少、不分散、好培训，基础组件交互效果较为简单，总体可控。因此只使用限定的 CSS 样式（设计软件能实现的那部分）来达到所需效果是可以保障的，总成本不高。

   

2. 前端组件的所有属性/交互/组合，未必都能渲染到设计控件上。例如弹出框的动画、动态增减的 Tabs等等

   思考：需要转换思维，由于设计源头的改变（从设计师稿 变成了 组件库代码为源头），并不是所有都需要还原到设计稿中。设计师在制作控制台页面设计时，只需要使用控件的一部分效果。例如某个页面的“VPC下拉选择” 组件，业务上需要远程搜索，但设计师通常只使用 Select 的常规控件表示即可，设计稿只体现了设计效果，并非真实业务的体现。因此虽然在 Select 基础组件实现中有“远程搜索”、”加载动画“ 等等，但是未必都需要生成到设计控件中，只生成设计所需的控件即可，源头在组件库，设计师要参与到组件库研发中，贴近研发视角来共建基础组件。

   

3. D2C过程中，设计稿转代码通常准确性低、不利于维护

   思考：第一，我们的目标聚焦在 “生成 使用京东云组件库的 研发初期用于布局的 代码”，不太恰当且笼统的说：生成Vue组件的 Template 标签中的代码。\
   其次，由于设计软件控件是由前端组件库生成，在生成控件过程中有很多的机会进行转换处理（额外组件信息注入、嵌套组件识别等等），由这些高质量 UI 控件组成的控制台页面的设计稿，会有更多的方式方法来生成高质量的页面代码。也可以通过批量生成标注数据集，进行训练让 AI 生成可靠性更高的代码。

   

4. 现有设计软件的能力评估

思考：内部 Relay 和 外部 Figma 都有控件的能力，能够通过 API 的形式进行批量生成。对于 DesignToken 希望通过设计软件内置的主题编辑、风格控制手段实现，彼时 Relay 平台对变量的使用、维护还在规划中，Figma 的变量系统在当时相对来说更可用。前期可以通过使用 Figma 来进行控件生成，待 Relay 相关功能发布时，通过 Relay 的 Figma 插件导入。

📝 实现方法简介

🎨 Code To Design

1. 将 DesignToken 通过 API 导入 Figma ，生成 Figma Variable。

2. Figma 有 ComponentSet 的概念，一组 Component 的命名按照 属性A=值,属性B=值,... 来命名的话，可以把这些 Component 组成 ComponentSet，因此对于一个前端组件，我们把它所有需要的（属性名，属性值) 组成一个矩阵，遍历出所有的 Component，让他们组成一个 ComponentSet。

   

对于矩阵中的每个元素，使用对应的属性K/V组合作为前端组件的Props，在 DOM 中渲染出这个前端组件。对每个渲染的前端组件的 HTML、CSS 进行解析。

3. 解析 HTML 和 CSS ，转换为 Figma 结构和布局配置。

4.

5

🎨 Design To Code

去年我们立项一起与零售 Relay 平台合作，尝试使用 Relay 平台的能力进行 D2C 探索。目前，在配置好约定字段的前提下，将当前生成的 Figma 设计组件库导入 Relay 后，可实现简单的研发组件 D2C。未来 Relay 平台会在这个方面重点研究，找到高质量 D2C 的形

另外业界也有很多代码生成的方案，也将持续发展基于 AI 的 D2C 模式。比如 Builder.IO 的代码生成即是基于 AI 的，使用我们生成的控件制作的页面，可使用 builder.io 的插件转化为组件库代码：

📅 后续计划

• 京东云前端物料全部达成设研资产同源。
• 主题编辑系统，在 DesignToken 的各个场景进行实时预览，导入导出 DesignToken
• DesignToken 按照社区标准化建议进行改造 https://tr.designtokens.org/format/#abstract
• 探索基于 AI 的 D2C

原文链接：https://developer.jdcloud.com/article/4232