设计系统的组件库，究竟是应该大而全，还是小而美？
点击"远行设"添加关注，最新设计内容随时掌握🤔🤔🤔
在 Sparkbox 的 2018 年设计系统调研问卷中，超过八成的人表示，设计系统 (design systems) 可以帮助设计师和工程师提高工作效率，确保 UI/UX 具有一致性，提升代码的可复用性。
一个成熟的组件库需要有多少个 UI 组件呢？Ant Design 的 Sketch 组件库有 33 个组件，Shopify Polaris 有 28 个。组件的数量是否越多越好，越多越牛逼呢？🐂
“组件太少，没意思。”
“组件库肯定是越多越好！保持产品 UI 统一，提高团队效率！”
一开始，我们也是这么想的。大而全的组件库肯定是最好的。
https://design.canonical.com/2016/07/getting-vanilla-ready-for-v1-the-roadmap/
理想中，我们的协作模式是这样的：
1、A 遇到了一个新的交互问题。
2、为了解决问题，A 制作好组件，并给组件起了一个名字。
3、这个组件能很好地解决 A 遇到的新问题。
4、过了一段时间…
5、B 遇到了同样的交互问题。
6、B 可以直接使用已有的组件，而不需要从头设计。
现在，我们在组件库里积攒了几个组件。当遇到新的用户场景，我们就不必担心从零开始，不知从何下手。我们可以选择组件库里现成的方案。但是，当新需求不能用已有的组件来满足时，我们该怎么办呢？
我们可能会通过改进已有组件来解决新需求。比如：
1、C 遇到了一个交互问题。
2、这个问题和 A 遇到的问题非常相似，但也有新挑战。
3、C 认为，如果可以对这个组件做一些修改，就能同时满足新旧需求。
4、C 提议改进已有组件。
我们也可能会添加一个新组件。比如：
1、D 遇到了一个交互问题。
2、这个问题和 A 遇到的问题有些相似，但也有新挑战。
3、D 认为，尽管可以用已有的组件来凑活，但最好再做一个组件。
4、D 提议添加一个新组件。
有时，面对新需求，我们既不修改，也不添加组件，而是把这个问题作为组件库的例外。比如：
1、E 遇到了一个交互问题。
2、这个问题和 A 遇到的问题有些相似，但也有新挑战。
3、E 认为，尽管可以用已有的组件来凑活，但最好还是把这个问题作为一个特例。
4、E 提议一个新设计，但不做成可复用的组件，不算在组件库内。
如果一切顺利，组件库里积累的组件会越来越多。组件库越丰富，能覆盖的交互问题也越多。但大而全的组件库是最终答案吗？
很多人的直觉是，只要组件库有足够多的组件，研发问题就都能用组件来解决。从此，开发产品就像搭积木一样简单。不仅单个团队可以快速高效地打造出体验一致的新产品，整个研发体系也具有可扩展性，能持续应对新的需求和挑战。
但事情恐怕没有那么简单。记得小学时的八色圆珠笔吗？它是否真的比普通的圆珠笔更好用？因为笔芯多，它的笔身比普通的圆珠笔粗，不适合长时间使用。因为笔杆结构设计复杂，按制部分也更容易坏。如果你平时只需要一种颜色的笔芯，其他 7 种笔芯都是累赘。
表面上，笔芯越多就能吸引更多的用户。有的喜欢黑色，有的喜欢蓝色，有的平时经常需要用到红色，还有些长尾用户喜欢绿色、橙色、紫色。但实际上，每天需要同时用 8 种颜色的用户几乎不存在。单色的圆珠笔的用户群体最大。而每增加一种颜色，用户群体会小一些。
大而全的组件库也有同样的问题。组件越多，目标用户群反而更小。如果一个应用开发者平时只用组件库的百分之十，那么剩下 90% 的组件对他来说都是累赘。他也不想浪费时间看剩下 90% 的代码和文档，也不想搞清楚所有组件之间的关系，更不想让剩下 90% 组件里隐藏的 bug 连累到他的应用。
我们可以把这些看作是组件库的隐形成本。如何减少隐形成本？这里有三种方案：
1、给臃肿的组件库瘦身，只保留常用组件，去除不通用的组件。
2、开发者尽可能提高组件库的使用率，想办法把每一个组件都用到项目中。😂
3、利用某种未知的技术让大家既不看代码也不看文档就知道如何使用组件库，并确保组件库的每个版本都没有 bug。🤣
第三种方案不是我等凡人能实现的，而第二种方案恐怕又未免削足适履。只有第一种方案具有可行性。古人有句话说得好，杀鸡焉用牛刀。只有提供合适的组件库，才能真正提高团队的效率。
“合适” 比 “牛逼” 更重要。每个团队都与众不同，其产品和业务场景也各具特色。盲目追求 “大而全” 不可取。但在 “大而全” 和 “小而美” 之间，究竟哪个点才算合适？本文恐怕无法给出明确答案，但至少我们可以从三个方面入手：
首先，设计组件是抽象的过程。与错误的抽象相比，重复 (duplication) 的成本更低。抽象出来的组件应是常见问题的答案，而不是每个问题的答案。如果组件变得越来越复杂、难以维护，那么它的抽象可能是错误的。如果一个组件库需要同时服务多个产品，那么它应该是核心组件库，只包含通用、基础的组件 (比如，表单元素)。另一方面，根据业务场景的不同，每个产品可以有自己的组件库，或者叫卫星组件库。
Duplication is far cheaper than the wrong abstraction.
- The Wrong Abstraction, Sandi Metz
其次，组件库不仅关乎组件，也关乎人们的协作方式。因为基础组件需要被很多人用到，所以我们往往以委员会的形式来一起决定研发路线。委员会的人数越多，效率也越低。根据我的经验，如果委员会的效率低，委员会就应该把精力放在简单、不重要的决策上。反之，如果委员会比较小、效率高，可以把精力放在更重要的决策上。为了提高决策效率，可以考虑把人数较多的委员会拆分成几个小委员会。比如，一个核心组件库委员会和几个卫星组件库委员会。
Authority is best applied on the simplest and least important decisions.
Not the most important.
- Minimal API Surface Area - Learning patterns instead of frameworks, Sebastian Markbåge
最后，组件库不是表面工作。毕竟，产品研发工作不是一蹴而就的，组件库可以帮助研发团队持续地维护产品。在组件库的研发工作中，我们需要合理地衡量隐形成本：
1、组件库在每个项目中的使用率。如果使用率比较低，那么组件库可能太臃肿。
2、组件库维护团队对新需求的响应速度。如果组件库已经拆分为核心组件库和卫星组件库，那么对于核心组件库来说，反应慢并不是一个大问题；但是对于卫星组件库来说，开发效率低、反应速度慢 (比如，合并 PR) 则是需要担心的。
3、组件的代码质量和文档质量。虽然高质量需要时间来打磨，但是对于组件库来说，质量为王，尤其是核心组件库和基础组件。这样才能真正提高团队的效率。
作者：Jamie Fang
文章地址：https://zhuanlan.zhihu.com/p/37401387
作者twitter：twitter.com/jamiefang
作者Dribbble：https://dribbble.com/jamiefang
本文由Jamie Fang授权发布于远行设。未经许可，禁止转载。
往期精彩✨✨
想法结合工具，让你的效率翻十倍
渐变质感技法：渐变配色之对比用色（上）
点击“阅读原文”更多内容等着你✨✨✨