1 写在开始
技术迭代是在任何团队都是老生常谈的话题，尤其是在前端技术发展迅速的这些年。无论是一帮久经沙场的老油条，还是刚毕业满怀冲劲儿和憧憬的新兵蛋子，都希望自己能学到一些跑在生态第一梯队的技术，但企业的技术并不是求新，而需要多个维度去判断是否合适。如何更好的选择更适合团队的前端库，成为了一个值得探讨的话题。
本文旨在分享运行时相关库的主观看法，工程化相关不在此处提及。
请注意：
1、本文中的”库“是统称，泛指可以通过npm仓库管理的可复用的前端运行时插件，可能指UI组件库、单页框架、CSS库等等。
这里顺便多嘴一句，库是library，不单指某一类特定代码的集合，而是开源项目的可复用产出物的统称。而框架一般指具有约定的针对某一领域的解决方案。
2、本文所有的内容都为作者基于自己知识体系的主观表述，如有不同意见，一定是你对，欢迎交流指正。
3、本文以作者本人在19年4月整理的angular生态进行UI组件库选型为例，进行流程和指标的解释，案例时间久远，只帮助内容理解，不做选型推荐。
2 流程简介
干货开始，分享一下我的选型流程：
选型步骤.png
流程简介：
-
圈定范围：根据环境因素（团队和行业的情况）进行组件生态的初步筛选
-
确定指标：确定你所关心的分析指标及对应权重
-
数据采样：根据指标对选型范围内的每个“参选者”进行数据收集
-
汇总分析：根据收集的指标数据进行横向比较，进行整体分析
-
选择结果且进行兼容性检查
接下来的内容会根据上述流程结合案例分享。
3 流程详述
3.1 圈定范围
选型的本质是比较和筛选，那么前提是先确定一个相对较小的选型范围，便于减少后续分析的工作量。
那么如何圈定选型范围？
3.1.1 信息查找的渠道
我们查找比较新的库通常会去github或掘金等技术社区或者搜索引擎直接搜索，接下来简单列举几个我常用的组件库查询途径：
-
awesome topic：如我要找angular相关的组件库 awesome-angular-components: Catalog of Angular 2+ Components
-
技术社区/公众号相关文章：如CSDN的跨端开发框架深度横评之2020版
-
官方文档：如vue官方帮助你打消你选型疑虑的对比其他框架 — Vue.js
-
搜索引擎：建议使用google、DuckDuckGo，如果翻不过去就Bing
3.1.2 初步筛选需要考虑的因素
环境因素.png
3.1.2.1 团队环境
-
人员平均技术能力：在人员平均能力不是特别强的情况下，过于复杂的库会增加项目开发和学习的成本。
-
人员学习能力：如果你选择的库的复杂度远远超出于你团队人员的学习的能力，会需要你进行二次研发或封装，增加研发成本。
-
团队原有的框架积累：不要轻易放弃团队原有的技术方向上的积累，同方向的技术迭代会让你事半功倍。
3.1.2.2 生态环境
为什么要考虑生态的流行度？
你选择的库的流行度决定你招人的难易程度，如果你选了一个小众的框架，大概率需要付出新招的开发人员的全部学习成本。
库的流行度也一定程度上说明了相关生态的完善和健康度，用的人多功能就会相对完善，bug解决的时效性也会更好。
3.1.2.3 行业线环境
-
契合度：举个例子，我的行业线使用的是比较复杂且要求高效的业务系统，那么有功能强大的table组件所在组件库就是更适合我行业线的。
-
运行时要求：有些行业线因为软件更新要求严格，所以浏览器版本落后，可能需要兼容老版本的浏览器。如我19年在组件库选型时，支持IE11是必要条件。
3.1.3 我的案例
以下是我根据当时（19年）社区的流行度和环境因素圈定的选型范围：
选型范围.png
3.2 确定指标
3.2.1 指标结构
基于自己对生态的理解，整理了一份指标（累死我了，手动狗头），还有很多不完善的地方，仅供参考：
指标.png
量化方式因为太多了，会在第三节进行概括行的分享，接下来会一一介绍指标：
3.2.1.1 基础指标
-
*生命周期阶段：简单看一下即可，无需量化数据，重点在于判断库是否处于不稳定或无人维护的状态。
-
是否有release版本：判断该库是否处于不稳定状态，通常我们会通过避免使用一个太”新”的库来规避技术风险。
-
官方是否仍有升级计划：判断该库官方是否还持续投入
-
最近一次feat或fix的更新时间：或是否声明即将停止维护，判断该库是否处于停止维护状态
-
-
*社区活跃度：是最重要的考量标准之一。和买车一样，销量高的无论是维修还是保养都便宜，出小毛病还能容易找到解决方案。
-
google trend的搜索指数：最好从整体和区域两个维度分析，库可能存在地域性，比如下图：vue在中国的搜索指数远远高度其他国家。
vue世界热度分布.png
-
github的star数量：一定程度上能说明受欢迎的程度
-
github的issue应答率和应答速度：是判断一个库是否活跃的重要因素
-
github的Pull requests close比例：是判断一个库是否活跃且稳定的重要因素，某些库在生命的末期或者不活跃后，可能存在缺乏人员维护的情况，如ant Design的mobile版本、element ui都出现过类似的问题。
-
npm下载数量和趋势：能够很大程度上反应一个库的用户数量
-
code的Contributions图：是判断一个库是否活跃的重要因素
-
-
安全可控
-
是否开源：需要识别一下源码是否完整
-
是否有大公司（团队）主导：大多数成功的开源项目都是有一个稳定的团队维护，这样能更好的保证框架的稳定和生命力
-
-
*功能完善度：是最重要的考量标准之一。
- 特性覆盖率：量化方式可参考3.1.2
3.2.1.2 环境指标
-
*业务（行业线）契合度：是最重要的考量标准之一，可与“功能完善度”一同分析。
- 重点特性完善度
-
运行时版本要求
- 要求的最低支持的浏览器/Node版本：量化方式可参考3.1.1
-
生态流行度
- 同基础指标的社区活跃度
3.2.1.3 研发成本
-
工程化完善程度
-
编译产出物是否支持多方式引入
-
源码组织方式（mono-repo还是multi-repo）
-
-
代码是否有良好的设计：大型的库基本可以放心，良好的设计会让代码拥有更好的可读性，方便维护和升级。
-
是否渐进式提供：一个库优秀的public API设计能力的前提是源码的清晰的构造层次，这也是代码拥有更好可读性的前提。
-
库结构的抽象程度：是代码是否好修改的考量因素之一。
-
-
研发文档完善度
-
是否有贡献指南
-
是否有二次开发文档
-
源码工程中是否有研发demo：有一个闭环可验证的demo是提升研发效率和研发质量的前提。
-
源码工程中是否有完善的测试用例
-
3.2.1.4 开发/学习成本
也就是使用成本。
-
API简洁程度
- API面积（个数）：无论是考虑开发成本还是学习成本，单个库的大面积的API都是灾难。
-
*文档完善度：好的文档是一个好的开始，也是能节省推广成本和降低推广阻力的途径之一。
-
可读性
-
是否有源码示例
-
是否有可交互DEMO
-
国际化程度（是否有中文）
-
是否有历史文档
-
文档美观度
-
3.2.1.5 用户体验
一般UI组件库才需要的衡量指标，这块的知识体系需要一些设计知识，如果有时间，会单独写一篇详细展开。
3.3 数据采样
仅举例部分指标的量化方式，本节重点展示采样对比的效果。
3.1 如何量化指标（有时间再整理）
3.1.1运行时版本要求：
-
最直接的就是查阅github主页上的 Browser Support /Environment Support
-
去官方文档中查阅
-
ISSUE查找
3.1.2 特性覆盖率：
- 目标库的特性（功能/组件）数量/需求的特性（功能/组件）数量
3.2 我的案例
3.2.1 搜索指数
-
趋势对比
一年内的趋势.png
-
流行区域
流行区域.png
3.2.2 项目背景
项目背景.png
3.2.3 社区活跃度
- 社区支持
社区支持.png
- 贡献
Contributions.png
3.2.4 功能完善度
功能完善度1.png
功能完善度2.png
3.2.5 重点特性完善度
重点特性完善度.png
3.2.6 二次研发分析
以material2为例：
material2.png
3.4 汇总分析
3.4.1 客观分析
客观分析.png
3.4.2 主观结论
主观结论.png
3.5 选择结果且进行兼容性检查
选型后，记得检查和你使用其他库的预依赖。
4 写在最后
本文主要是对过去知识体系的梳理和完善，将选型思路根据自己的知识体系分享出来，希望能给更多的人提供思路。
无论是流程还是量化的指标，都是和我的知识体系紧密联系的，所以并不是适合任何情况的选型分析，仅作为选型分析和库本身分析的参考。
附录：系列文章的目录结构
3、如何进行前端选型？
4、如何画好一个前端框架图？
5、如何进行前端框架推广？
6、关于开发人员支撑形态的见解
7、如何根据用户（开发人员）反馈进行框架优化？
8、前端框架用户体验方向的思考
10、专题2：前端研发流程下的权限控制
网友评论