@C7210?： 本期是一篇很长的译文，Using Sketch Libraries to build better design systems，从理论方法到实践演示，一应俱全。
看完本文你会学到：
- 如何解决Symbols同步共用问题？
- 使用Sketch Libraries创建组件库
- ?对核心Libraries中的元素进行更新
另外说，Sketch 48 Beta已经开始提供Colors Management方面的功能，又是一次体系化角度的重要更新。
注意：Libraries功能仅在最新的Sketch 47当中提供。
所谓设计，就是在一系列约束条件下构建解决方案的过程。——Adam Morse
从某种程度上讲，设计体系便是这样的一种约束。诸如配色、图标、按钮等一系列设计语言要素共同构成了标准化的体系，为设计决策提供着指引。
遵从于这样的标准化体系，设计流程能够得到有效加速；同时，设计模式的复用性与一致性也将得到提升，产品设计方案整体更具扩展性，更易于维护。
然而在现实当中，创建和维护标准化设计体系的方式却多种多样。Sketch是我们在设计工作当中的利器，可以帮助我们简化设计体系的创建流程，但其自身在各方面存在的问题也是无法忽视的。
问题所在
在Sketch 47为我们带来Libraries之前，Symbols一直是Sketch当中最为重要的功能之一，同时也是构建设计体系的关键能力。Symbols用于创建可复用的界面元素，有助于维护设计方案的一致性。然而一直以来，这一机制的作用范围仅限于文档内部，除非借助第三方插件的帮助，否则Symbols无法在不同的文件之间保持同步。
这为什么是问题？
对于小项目来说，这没什么大不了。你可以将全部设计方案，甚至包括高保真原型、流程图一类都塞到一个文件当中，Sketch处理起来也不会产生什么问题。
然而，情况会随着项目规模的扩大而有所不同。出于性能效率或协作方面的考虑，我们通常需要将项目打散到不同的Sketch文件当中；这时，Symbols同步共用方面的问题就会暴露出来。
我们的团队有三个产品用到了同一套Symbols，这里的挑战就在于如何确保Symbols在不同项目之间的同步性。这三个产品都是很大的项目，各自的源文件都包含上百个画板（Artboard），因此难以通过单一Sketch文件来承载，否则文件将变得非常庞大。
△ 一个Sketch文件承载了整个组件库
从前的处理方式
我们曾经使用一套Sketch模板来集中放置所有的Symbols，这种方式参考了原型制作工具Marvel官方的设计规范创建方法。在此基础上，我们进行了一定程度的扩展，例如在不同的Sketch文件当中通过Craft插件统一调用Symbols模板文件。
△ 使用Craft插件构建组件库
事实上，我个人并不推荐这种方式。文件尺寸的确得到了控制，Symbols的来源也得到了统一。但问题在于，一旦模板当中的Symbols发生变化，对于那些已经插入到不同文档当中的Symbols，我们无法进行同步性的更新。
Symbols功能的本质目标是使项目更易于创造和维护。然而，强大的复用能力只是其中的一个方面；对于那些已经被插入到不同文档当中的Symbols，你根本无法进行统一管理与更新。
幸运的是，Sketch 47为我们带来了Libraries功能。
解决方案
Libraries功能可以帮助我们创建独立的、能够被多个文件统一调用的Symbols库。这种机制已经有些类似于前端开发者们所熟悉的Sass了。不仅如此，你还可以对Libraries进行嵌套。
大体上讲，如今你可以将不同类型的Symbols分别存放在不同的Sketch文件当中各自作为独立的Library，譬如配色定义、图标、按钮、表单元素等等；其他项目文件则可以统一调用这些源文件当中的Symbols。当你修改了Libraries源文件，相关的变化也会同步更新到所有的项目文件当中。
这种统一管理和调用的机制可以为工作带来诸多益处，包括：
- 减小文件尺寸
- 增强Sketch的性能表现
- 提升界面元素的统一性
- 提升项目整体的可维护性
Sketch官方团队是这样诠释Libraries功能的：
一个Library本质上就是一个普通的Sketch文件，其中的Symbols可以被其他Sketch文件调用。如果你编辑了Library当中的Symbols，那么调用了该Library的其他Sketch文件便会收到更新通知，你可以对变更进行预览、对比和确认，使这些Sketch文件所调用的Symbols自动更新至最新版本。→ ?Sketch 47 Libraries功能图文详解
使用Sketch Libraries创建组件库
在本文接下来的部分当中，我将展示如何使用Sketch Libraries功能创建UI组件库。不过在此之前，我们还需要明确一些思路与原则。
像开发人员一样思考
打造设计体系的过程中，设计师们要试着像开发人员一样思考。——D.R.Y – Don’t repeat yourself
组件库的基本概念就是逐层创建可复用的UI元素，保持文件的轻量化以及设计方案的一致性。
从“原始元素”入手
我们所创建的任何一个组件都是由若干“属性”组成的。这些属性就是设计体系当中最为「原始化」的元素。开发人员会在代码当中为这些属性创造各自的变量，以提升代码的复用性；对于设计师来说也是同理，我们可以为各种原始化UI元素创建Libraries，以便逐层构筑更高级别的组件。
原子化设计理论
为了确保组件库的扩展性，我将Brad Frost提出的原子化设计理论作为指导。这套理论简单易行，很容易理解。
简而言之，原子化设计的灵感来自于现实世界当中的分子结构。UI当中颗粒度最小的元素，即「原子」，组成了颗粒度较大的控件，即「分子」；而诸多分子又组成了更加复杂的组件与模块，即「有机体」。
将不同类型的Symbols放在各自的Library文件中
当然，如果你愿意，你仍然可以将所有组件都放置在同一个Library文件当中；而我的建议则是为每种类型的Symbols各自创建一个独立的Library文档。
类似于开发人员使用Sass partials的方式，调用多个Libraries文档可以使我们的设计体系更为优雅，更易维护。经过合理拆分的Libraries文档将更有利于被不同的项目调用；在需要的时候，也可以更加方便地进行扩展。
参照「原始元素」的思路，我们将从最为基础和核心的UI元素入手，包括颜色、图标等等，这些元素将在整个设计体系范围内被使用到；所有「原子、分子、有机体」级别的UI元素也正是由这些原始元素所构成的。
我们首先要对全局所用到的各类颜色进行定义。
第一步：创建新的Sketch文档，用于颜色定义
对于团队项目，我会在Sketch文件名当中统一添加「AIN」作为前缀，例如「AIN-Colors」等等，以便与其他项目进行区分。当然，命名方式和习惯因人而异，如果你和我一样需要处理很多不同的项目，通过前缀进行区分的方式或许值得考虑。
我会为设计体系当中的每一种颜色生成一个Shared Style，并按照不同的作用进行分类，包括「brand、greyscale、UI」等等；具体的分类方式就是在Shared Style命名当中通过「/」符号表示层级结构，Sketch会识别到该符号，并自动生成相应的架构。
接下来，我会为每一种颜色制作一个Symbol，并使用Symbol Organizer插件在Symbols页面当中对它们进行组织 – 在层级化命名方式的辅助下，Symbols页面将自动呈现出清晰的架构体系。
第二步：将颜色定义文档添加到Libraries体系
完成了颜色定义之后，我们需要将这份Sketch文档添加到Libraries体系当中。设计体系当中所有原子级元素的定义都需要这一步骤。
在顶部菜单栏选择「Sketch ? Preferences」，然后进入「Libraries」选项卡，点击“Add Library」按钮，选择我们在上一步里创建的Sketch文档。
如图所示，我将AIN-colors文档添加到了Libraries体系当中，这样我就可以在任何其他Sketch文件里对其进行调用了；这便是Libraries功能的强大之处。
怎样使用这些颜色Symbols呢？在接下来创建图标Library的过程中，我将进行演示。
第三步：创建新的Sketch文档，用于图标定义
类似于我们在第一步当中的做法，这一次我们对图标进行定义。新文档名为「AIN-icons」，与之前的「AIN-colors」文档保存在相同的路径中；之后所有原子级UI元素的Libraries文档也都将被保存在这里。