引言

随着 React.js 的崛起，最近组件化前端开发十分流行。

大型公司开始开源其前端框架，谷歌有 MaterialUI，Shopify 有 Polaris,

Palantir 有 Blueprint。

你或者你的老板也许正在考虑创建自己的组件库。

创建自有组件库让人十分激动，但你得明白可重用组件库并不是银弹。

如果你想让其他团队也使用组件库，需要花费很多努力创建组件库。

在投入时间、人力和资金之前，你需要仔细权衡组件库的必要性。

为什么不该创建可重用组件库?

团队也许并没有准备好付出巨大努力实现组件库。

在刚开始开发还没有人用的组件库之前，最好明确此时可能并不是最佳时机。

有很多考虑问题可以确定此时不是创建组件库的时机。

团队风险承受能力较低

往任何项目投入大量的时间和人力都是有风险的。

你需要评估团队的风险承受力。

如果排期很紧，而且存在外部依赖导致变动时间很短，你可以考虑推迟项目，直到团队变得更加稳定。

如果你团队很小，无法产出有回报的代码，你会想等到团队壮大，或者你可以投入整个团队进入项目。

不熟悉可重用性

团队成员是否创建过 npm 模块？ 是否参与开源项目？ 或者想过采用什么方法为其他开发者构建工具？

如果这些问题的答案是否，你也许得鼓励他们从小项目做起。

你可以开始一个小型项目一起创建简单可重用的组件。

在开始提交代码实现项目之前，团队应该理解创建可重用组件的挑战。

团队没有能力维护

诚实对待这个现实。

如果团队只有三人，其他人使用组件时，你可能没有能力维护库。

你是否愿意招聘工程师支撑项目？

你的团队预算是否能够支持?

要是有人离职呢？

你是否记录他们写的代码？

或者你的团队是否有足够人力支撑？

无法向产品和老板交差

只是一个库并不会直接影响底层产品。

你最终会看到交付代码的速度提升，但整个过程需要几个月或者几年。

你能否说服非工程群里明白库的价值?

不要让像这样的项目因为没有人支持而失败。

为什么应该创建可重用组件库?

提升效率

一旦你有了自己的组件库，你可以快速交付更多代码。

想想网站上有多少个按钮？

工程师们花费多长时间一遍一遍的写按钮？

考虑下还有很多种方式可以实现按钮。

可以<button>或者给<a>添加样式。

按钮也会管理不同的状态，像悬浮和加载。

你不会想让工程师浪费时间考虑这些细节。

当你让工程师们解放出来专注更有挑战的事情，他们可以花费更多时间处理复杂的功能。

强制开发统一

应用有很多工程师共同开发，你想提供目标用户一致的体验。

鼓励所有的工程师重用组件会让用户使用起网站更有意思。

提升性能

当每次调整组件功能一遍一遍地构建，因为 JS 代码需要编译。

最后 JS 包文件会膨胀。

更糟糕的是，有人不喜欢自己造轮子，单独引用新库，增加额外依赖，需要单独维护。

维护更少代码

当你重用组件时，会减少尺寸和代码复杂度。

组件重用会让 bug 更容易排查。这点很不错。

更容易进行后续升级

五年之后，你想要推倒之前的前端代码，用最新的框架替换。

通过替换应用中的一个个组件而不是整个应用替换会变得十分容易。

译者注

• 原文链接

• 原文有删减，因译者水平有限，如有错误，欢迎留言指正交流