設計系統的組件庫，究竟是應該大而全，還是小而美？

來自專欄設計研習社

(閱讀時間: 大約 6 分鐘)

在 Sparkbox 的 2018 年設計系統調研問卷中，超過八成的人表示，設計系統 (design systems) 可以幫助設計師和工程師提高工作效率，確保 UI/UX 具有一致性，提升代碼的可復用性。

一個成熟的組件庫需要有多少個 UI 組件呢？Ant Design 的 Sketch 組件庫有 33 個組件，Shopify Polaris 有 28 個。組件的數量是否越多越好，越多越牛逼呢？??

「組件太少，沒意思。」

「組件庫肯定是越多越好！保持產品 UI 統一，提高團隊效率！」

一開始，我們也是這麼想的。大而全的組件庫肯定是最好的。

理想中，我們的協作模式是這樣的：

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. 組件的代碼質量和文檔質量。雖然高質量需要時間來打磨，但是對於組件庫來說，質量為王，尤其是核心組件庫和基礎組件。這樣才能真正提高團隊的效率。

歡迎關注我的專欄: