认识达内从这里开始

组件化的开发方式可以说是程序员使用非常多的一种软件开发架构方法了，而对于组件来说，通用性和易用性就成为了需要衡量的不同性能，下面我们就通过案例分析来了解一下具体情况吧。

先对这两个概念进行定义，避免含义宽泛造成误解。在本文范围中：

通用性：指组件库提供的元素(图标、按钮、组件、模块等)对于设计需求的适应能力，即能否以较少的元素实现较为多样的产出形式。

易用性：指组件库对于使用者的友好程度，即能否帮助设计师以较少的认知与操作成本来调用和定制组件。

具体到 Sketch 的实践层面，我们通常会将若干元素打包为 Symbol，构成一个可供复用的组件。其中，“通用性”与“易用性”体现在：

Symbol 内部元素的可控性越低，其用途就越单一，对于使用者来说也更易于认知和记忆。但要满足复杂的设计需求，所需 Symbols 的数量就更大，整体架构的复杂度更高，库的制作和维护成本也更高。

Symbol 内部元素的可控性越高，其用途就越广泛，需要配合“Overrides”面板控制的嵌套及样式关系就越为复杂，因此使用者对其用途的理解与记忆成本就越高，每次根据特定需求进行调整定制的复杂度也越高。而相应的，由于 Symbols 的高度整合，库的整体规模会相对较低，架构相对简单。

以上两种状况，任何一个极端都不利于构建高效实用的组件库，制作者需要针对每一个图标、按钮、组件、模块，考虑如何实现通用性和易用性的平衡。

以“Social”库当中的一些实现方式为例，来简单描述下这种平衡。

图标

“Social”库提供了40个常用的功能性图标，并以此为基础扩展出了不同形状样式的共计48个“Category”类图标(用于金刚位或消息列表等等)：

从实现方法上，后两类图标显然无需定义 24x2 共计48个 Symbol;将基础图标 Symbol 与背景样式 Symbol 进行嵌套，打包成一个 Symbol 即可解决问题。这个 Symbol 具有高度的通用性，使用者可以通过“Overrides”控制其图标样式与背景种类。但从使用角度，这种方式不利于一目了然地识别和记忆，不利于使用者在一时间了解有哪些同类元素可供调用，需要依靠猜测及“Overrides”进行复杂的控制。分别定义成48个图标之后，无论使用者打开源文件进行参考，还是直接作为 Library 调用，都可以清晰地看到全部可用元素。

同时，这48个图标并不代表所有的可能性，你仍然可以通过 Sketch 52 提供的Symbols 样式定制功能实现更多的规格。

按钮

“Social”库提供的行动类按钮包括以下3类，5种风格共计15个：

除了左侧带有图标的按钮之外(这类按钮的自适应性需要用到一些有意思的 hack 来实现，单独找一篇聊)，其他几种风格，包括圆角矩形或胶囊状，以及实色、Ghost 样式等等，从技术角度同样可以藉由一个 Symbol 实现，并通过“Overrides”控制实际风格。但同样，作为组件库，相比于技术逻辑是否极致，易于发现、识别并快速调用才是为优先的。

Feed Header

“Social”库提供了8个 Feed Header 组件，用于构建信息流卡片当中的用户信息。

如果加以整合，这8个 Symbols 完全可以压缩成两个，甚至是一个;在调用时通过“Overrides”控制内部元素的呈现或隐藏。然而在那样的情况下，从“需要调用”到“完成调用”这个过程已然需要使用者付出大量的认知成本，需要反复调整元素的布局与呈现关系，才能调试出可能符合自己需求的组件。

结语

综上所述，对于“Social”库来说，我更希望使用者在调用其元素时，可以一目了然地发现所有选项，并能快速完成选择和调用;而非提供一系列极致整合的“通用”组件，使你不得不预先进行猜测、判断，并通过大量的定制工作才能达到目标。

当然，这种平衡性原则也和库本身的性质有关。“Social”库的目标本就包含“减轻甚至免除受众改造组件的成本，实现更快的使用速度”，因此会使天平更倾向于“易用性”的一侧，而非高度整合的“通用性”。如果你需要制作的库更在于体量的控制或是需要体现前端开发方面的实现逻辑，那么对天平倾向性进行相应地调整也是有必要的。

节选：Beforweb

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。