关键词：面试中组件库建立遇到的问题，解决方案等
TDesign 是腾讯各业务团队在服务业务过程中沉淀的一套企业级设计体系，于 2021 年 12 月底正式对外开源，它提供一套完整的设计体系，目前同时支持 4 个框架。由于参与贡献的人数众多，支持的框架数量也多，所以开源之后，大家对 TDesign 充满好奇，好奇为什么腾讯要推出 TDesign 作为企业级设计体系， TDesign 如何平衡通用和业务需求，满足集团诉求；想知道在如此多框架是如何保证不同框架版本同步和功能持续迭代等等。本文带大家快速了解 TDesign 是如何诞生、开源和运作的。
腾讯内部搭建了很多的设计体系和组件库产品，满足各自的业务诉求，提升研发效能。但是这些体系各自独立维护，难以得到有效复用。到了 2019 年，腾讯内部已经意识问题存在，开始选择内部开源共建与技术中台并行的路线，也就是开源协同。与此同时公司内对提供比较成熟、完整、维护成本低的组件库有强烈的诉求，这样面对内部需求和外部竞争的压力，需要从公司层面解决问题，以开源协同为契机迎头赶上。那么问题来了，内部面临两个选择：
- 从 0 到 1 吸收各个设计体系的的经验，为公司重新搭建，共同维护；
- 从 1 开始，在公司比较成熟的设计体系中选择一个再进行优化，打造一个迭代版本。
现有的设计体系都是基于自身的业务打造的，耦合了不少业务的属性，如果要做需要高复用性的设计体系，改造起来会有更高的成本，且之前设计体系中的组件库产品大多只实现了一种主流的开发技术栈，很难满足公司众多团队的技术栈使用需求，因此 Oteam[1]最终选择了集合大家的力量从零开始做一个组件库的方案。但是之前搭建设计体系思考是共通的，经验是可以传承的，所以各事业群之间可以一起协同，为公司搭建一个的通用性的设计体系。而多个团队的参与可以让设计体系考虑更周全，范围更广泛，能传递一致的设计理念，这才有了 TDesign 诞生。
诞生后的 TDesign 隶属于腾讯前端和设计两个领域委员会，每半年都需要制定 OKR 并对齐半年目标，明确发展方向和关键能力节点，每个月都需要向两个领域委员同步开源工作进展，接受委员会评审。领域委员则会定期会从代码研发治理、社区运营、影响力、业务落地情况等方面定期考核和指导团队建设情况。TDesign 日常运作的开支也大多来自于 Oteam 的各种支持和奖项。
在项目启动开始，首先统一 TDesign 的定位：聚集公司的设计、研发经验，满足产业互联网在各个应用环节所需要的一套设计体系。
TDesign 的主要参与成员都来自于公司内各大组件库产品的团队，借助大家之前建设、维护组件库的经验，遵循统一的 TDesign 企业级设计体系为 PC、 Mobile 、小程序、 Flutter 等平台提供基础组件库产品，满足通用需求：
- 对新增组件类型保持克制的态度，全体 PMC 成员达成共识后再着手新增；
- 相比起新增功能 API ，更倾向于自定义扩展或通过几个 API 组合的方式来实现， API 多了也会增加用户使用心智负担，反而变得 “不好用”；
- 将影响风格的变量尽可能的抽离为 Design Token ，满足各业务团队根据自身业务特性定制主题：
https://github.com/Tencent/tdesign-common/blob/develop/style/web/_variables.less
除基础组件外，TDesign 也联合公司内部多个业务团队，锤炼各垂直领域的行业组件，目前已经有地图、政务、智慧零售、医疗等行业组件正在建设中，基于 TDesign 的基础组件提供更复杂的、具有业务的属性的组件供项目使用。
通过以上方式，由基础组件库解决通用性和灵活性的问题，由行业组件库满足不同业务场景下易用性的需求，减少重复的人力投入，通过统一、完善的组件生态提升开发效率。
当然这里涉及到很多设计和开发的协同和思考以及基础设施建设，在本文中就不展开赘述， TDesign 团队会在后续时间与大家分享，欢迎大家关注腾讯设计公众号。
1. TDesign 的组织形式
按照开源协同的方式共建会卷入很多的团队和个人，当这么多人一起协同合作，一方面会带来丰富的组件库建设经验和充沛的人力投入，另外一方面也会带来很多的挑战：
- 大规模开源协同如何组织
- 多技术栈发展如何有效推动
围绕 TDesign 的定位，细化了 TDesign 合作方式，首先团队由 PMC 、联合团队、贡献者构成：
1.1 项目管理委员会 (PMC) 成员
PMC[2]成员需要一起制定开源项目目标，并保障每项工作按时完成。每周 PMC 都有线上项目例会，讨论周内遇到的问题、方案决策，同时 review 上周进展及制定下周计划。
对外开源后 TDesign 依然执行以 PMC 团队为决策核心的方式，所有内部与外部贡献者都由负责各个技术栈或专业方向的 PMC 同学分配和引导参与开源工作。
1.2 联合项目组
单纯依靠业余时间参与开源的贡献者，在面对业务使用需求及一些公共基础设施时总显得力不从心，因此除了广泛招募开源贡献者之外，也联合公司内的几个业务部门成立了联合项目组来参与日常运维和建设工作，参与项目组的部门会以团队的方式承担一部分 TDesign 的 OKR 。
目前大部分组件的设计稿都由参与联合项目组的设计师同学提供和维护。在组件开发遇到以下问题时：
- 原有组件开发者暂时无法参与组件 Bug 修复
- 新组件 / 新功能开发进展不如预期
联合项目组的同学会和 PMC 成员一起参与兜底，保障开发进度和产品质量。
1.3 贡献者
TDesign 开源项目建立以来，既有偶尔参与修复问题的普通贡献者参与，也逐渐有了很多积极参与建设的核心贡献者，其中一些核心贡献者在大家认可后也加入了 PMC 团队。对外开源以来，团队对公司内外参与贡献的同学都一视同仁，也非常期待有来自公司外的同学能够以 PMC 成员的身份加入团队一起参与 TDesign 的开源建设工作中。
通过综合开源招募和联合项目组两种组织形式，既能招募到更多贡献者一起贡献力量，也能通过项目组兜底处理紧急需求及通用基础设施建设，解放贡献者负担，使协作更流畅。21 年内共有包括设计师、开发者、运营同学在内的 300 多位同学通过这两种组织形式参与到 TDesign 的开源共建来。
2. TDesign 的开源治理机制
TDesign 官方支持众多技术栈，有多个仓库在同步推进建设工作，比较容易出现各技术栈实现不一致的问题，为此制定了一套开源治理的机制来保障产物一致性，降低协作成本。
通过以规则为中心，工具建设与贡献者激励并举的开源治理机制，来确保 TDesign 的持续发展，更好地为开源社区和开发者们贡献价值。
2.1 以规则为中心
为了更好的进行组件的开发和项目的持续迭代， TDesign 在项目初期，便制定了完整的规范，来帮助团队内部进行项目开发，并随着项目的持续开放，不断完善修正，覆盖了组件开发、 API 设计、代码风格、项目维护等多个领域共计 9 个不同的规范，从而帮助开发者在开始贡献前，清楚的明确边界。
TDesign 规范
https://tdesign.tencent.com/about/tech
开发者在了解 TDesign 的设计体系之后，便可以根据 TDesign 的各项规范着手进行开发。而在这个过程中， TDesign 所提供的各项基础设施，可以帮助开发者更好更快的完成项目的开发、不同贡献者之间的沟通。
2.2 工具建设
TDesign 团队将上述规范固定下来，变为可以自动化运作的工具，保障规范的执行效果。
2.2.1 基于 TDesign API 设计平台的组件开发
组件 API 作为 TDesign 最重要的底层资产，多个技术栈产品需要实现同一份 API ，这就要求不同平台的开发者在开发时能够在保持平台本身规范的同时，统一开发规范和逻辑。为此，TDesign 设计了一套 API 统一规范和配套工具链，来降低开发者在不同技术栈之间统一体验的难度。
组件负责人会在组件进入开发前，充分参考现有设计稿的交互及业界类似组件实现，起草完成 API 初稿，在通过与各技术栈开发者和 PMC 同学进行线上会议评审，对齐各个技术栈对某个 API 的实现方式，使用 TNode 等来抽象表达某技术栈的特殊语法糖。API 设计规范参见：
https://github.com/Tencent/tdesign/wiki/Component-API-Guide
在线维护组件 API
TDesign 工具生成组件定义
经由线上会议评审通过后，将 API 设计录入 API 设计平台，并在平台上进行组件 API 定义的维护。有了这份统一的 API 描述数据，不同框架都可以使用统一的 CLI 工具来生成在对应平台下所需的组件定义文件。开发者只需要引入对应的定义文件就可以直接进行组件开发，保证最终各个技术栈 API 实现一致。
API 设计平台的实现既帮助 TDesign 完成了 API 统一的工作，也为 TDesign 在后续拓展工具链应用、微前端以及跨端场景方面打下了良好的基础。
2.2.2 基于 GitHub 的自动化流程
1) issue 流转
TDesign 使用 GitHub 进行代码托管和 issue 追踪管理，开发者们也使用 GitHub 来完成项目的贡献。如果没有一套好的机制来保证，会出现 issue 和 pull request 管理混乱的问题。
TDesign 通过使用 Github 提供的 template 功能，优化了用户反馈和贡献的流程。
TDesign 还设置了一系列的 Github Action 流程，来实现 issue 的自动 assign 、通知、截图，把大量需要人工完成的事情，改为自动的，提升效率，并让贡献者可以在第一时间收到仓库的反馈，明确具体的处理者，获得更好的贡献体验。通过这套机制可以保障 issue 顺畅地流转，防止漏掉用户的反馈信息：
TDesign 在企业微信内容中配置了相关的机器人帮助即时同步，防止漏掉用户的反馈信息。
2) PR 处理
同样的 TDesign 还配置了 Pull Request 的 template ，开发者在参与贡献时，提供了对应的模板，帮助 Reviewer 快速获取此 Pull Request 的基本信息。
为了降低贡献者参与门槛，TDesign 把所有 PR 的前置检查都通过 GitHub Actions 自动触发，同时会根据本次提交的内容生成官网预览地址，PMC 成员和贡献者可以一起对照官网预览走查本次 PR 的改动内容，从而更高效的完成 PR 的 Code Review。
2.3 基于官网渲染工具的高效协作
除了代码层面，文档也是 TDesign 为用户提供的重要工具，而文档也是开发者们最不愿意做的事情之一，为了能够为用户提供更好的文档，TDesign 也做了一些举措，来降低文档的维护难度，让开发者们可以更加简单的维护文档。
TDesign 在各个技术栈的实现都共享同一份组件文档，因此设计师同学只需要在一个仓库中维护这些文档，所有技术栈官网中都将同步到这些内容。各技术栈仓库均以 Git Submodule 的方式引入直接使用，不会再重复开发，保证各个技术栈产物 UI 一致。各个技术栈开发者只需要关心组件 demo 内的实现，其他交由公共样式包和特定 markdown render 来处理就可以得到一份标准的 TDesign 官方站点。
TDesign 使用 Web Components 来实现官网站点的公共样式，并发布为独立的 npm 包：
https://www.npmjs.com/package/tdesign-site-components
各个技术栈开发者只需要关心组件的 Demo 实现，其他交由公共样式包和特定 Markdown Render 来处理就可以得到一份标准的 TDesign 官方站点。官网统一渲染工具目前还没有开源，后续 TDesign 会有文章详细介绍这部分内容的实现。
2.4 贡献者激励
TDesign 作为一个覆盖多个技术栈和应用场景的设计体系，需要有大量的用户和开发者参与其中，才能更好的服务用户，因此，在项目设计之初，便考虑到了贡献者激励的问题，帮助贡献者更好的参与到 TDesign 当中。
2.4.1 贡献者路线
在发展路线上，TDesign 设计了「用户、贡献者、核心贡献者、PMC、荣誉贡献者」的五级成长体系。当一个开发者在使用 TDesign 过程中，发现了一些问题，并完成了自己的第一个任务之后，会自动成为贡献者。而贡献者在持续活跃三个月之后，经由 PMC 提名或主动申请，可以成为对应领域的核心贡献者。核心贡献者经由 PMC 推荐或主动申请，则可以加入 PMC，成为 PMC 成员，进行 TDesign 的管理。当 PMC 后续工作发生变化，不再参与项目后，则从 PMC 退出，成为荣誉贡献者。
开发者可以根据自己的时间和精力来进行项目的贡献，并通过自己的持续贡献成为更高级别的贡献者，担负起更加重要的角色和责任，帮助 TDesign 更好的发展，同时也促进开发者自己的成长。
2.4.2 贡献者激励
承担一定的责任和义务，可以获得相应的激励和权益。为了感谢 TDesign 的贡献者们的付出，TDesign 提供了多层次的激励机制，让贡献者们的贡献能够被大家看到。
每个 TDesign 的贡献者都会展示在 GitHub、官网等处的贡献者名单当中，此外， TDesign 还会为贡献者们提供周边、专属头像、现金激励、年度团建等不同类型和方式的激励，以感谢贡献者的付出奉献。
3. 由内源到对外开源
3.1 代码开源
TDesign 组件库已经在公司内源上运作了很长时间，在将仓库从内网的 Git 服务迁移到 GitHub 前，也曾想直接在 GitHub 上初始化一个空仓库，然后用 TDesign 公共账号把当前代码一次性提交上去，这样最简单，理论上也不存在任何公司内部敏感信息的泄漏。但这样操作也存在一些问题：
- 历史贡献无记录，之前内网的很多同事已经为 TDesign 贡献了相当多的代码，期望在开源时依旧能够保留每个参与同学的贡献记录
- 代码演进无法回溯，TDesign 坚信一项原则“代码永远不会真正被‘完成’，只要它还活着”，对外开源的应该不仅仅是代码当前的状态，还应该保留代码整体演进、迭代的记录，以便后加入的贡献者可以回溯它的历史
权衡利弊之后 TDesign 放弃了这套简单的方案，选择保留代码历史记录的方式进行开源。为此 TDesign 联系到了所有之前贡献过代码的所有公司同事，请他们提供个人 GitHub 账号。然后重写了所有仓库的 git commit 历史，替换为外部 GitHub 账号，并抹除了潜在泄漏风险的提交记录：
经过多次走查后确定提交历史是安全的，符合公司信息安全规定后，最终将所有仓库迁移到了 GitHub，现在 TDesign 的所有文件都是提交历史清晰，有据可循的：
3.2 文档开源
除了代码，TDesign 也将所有之前在公司内维护过的文档，及内网仓库中的一些重要讨论 issue 全部迁移到了 GitHub wiki：
https://github.com/Tencent/tdesign/wiki 及对应技术栈仓库中：
3.3 过程开源
除了代码和文档等开源，TDesign 也在探索将团队整体协同运作的过程也对外开放，以帮助外部的小伙伴可以一起参与进 TDesign 开源生态的协同中来。在尝试过公司 TAPD 外部版本、腾讯文档、Notion 等文档协作工具后，TDesign 最终还是决定回归 GitHub，跟代码及 issue 社区保持最近的距离，方便大家了解最新的进展：
如上 TDesign 使用了 GitHub 的 Projects 能力作为任务看板，里面记录了团队每周迭代在做的事，和后续计划要推进的事项。如果你对 TDesign 的未来能力感兴趣，请关注这里的看板。
TDesign 接下来会按照 Roadmap 持续完善产品特性，推出更多组件库生态周边产品，敬请期待：
TDesign 在设计项目的治理体系当中，参考了国内外诸多开源社区的治理体系，站在巨人的肩膀上，才得以形成如今的治理体系。TDesign 对于让项目变得更好的心是不变的，欢迎反馈参与 TDesign 贡献的体验，并给出你的建议和意见，帮助 TDesign 社区更好的服务于开发者。
注释：
【1】对于适合开源协作的方向，各领域技术委员会指导建立各类虚拟项目组织（Oteam），通过内部开源协作的方式打破壁垒，营造开放的技术氛围和开放的代码文化，提升公司的研发效能和运营效率。
【2】腾讯内对开源项目的管理类似于 Apache 软件基金会 的模式，腾讯的领域技术委员会可以类比为 Apache 董事会，负责监督开源项目发展及为项目分配资源，决定是否启动或终止某个开源项目。开源项目的日常运作，包括内容和方向的技术决策权则交由由项目管理委员会（PMC）负责。
撰文：鼎鼎、哲哥
主创团队：腾讯 TDesign Oteam
快乐工作，快乐生活
Happy work , Happy life
/
若有收获，就点个赞吧
0 人点赞
