1 寫在開始

技術(shù)迭代是在任何團(tuán)隊都是老生常談的話題衬浑，尤其是在前端技術(shù)發(fā)展迅速的這些年。無論是一幫久經(jīng)沙場的老油條放刨，還是剛畢業(yè)滿懷沖勁兒和憧憬的新兵蛋子工秩，都希望自己能學(xué)到一些跑在生態(tài)第一梯隊的技術(shù)，但企業(yè)的技術(shù)并不是求新进统，而需要多個維度去判斷是否合適助币。如何更好的選擇更適合團(tuán)隊的前端庫，成為了一個值得探討的話題螟碎。

本文旨在分享運(yùn)行時相關(guān)庫的主觀看法眉菱，工程化相關(guān)不在此處提及。

請注意：

1掉分、本文中的”庫“是統(tǒng)稱俭缓，泛指可以通過npm倉庫管理的可復(fù)用的前端運(yùn)行時插件，可能指UI組件庫酥郭、單頁框架华坦、CSS庫等等。

這里順便多嘴一句不从，庫是library惜姐，不單指某一類特定代碼的集合，而是開源項目的可復(fù)用產(chǎn)出物的統(tǒng)稱椿息。而框架一般指具有約定的針對某一領(lǐng)域的解決方案歹袁。

2、本文所有的內(nèi)容都為作者基于自己知識體系的主觀表述寝优，如有不同意見宇攻，一定是你對，歡迎交流指正倡勇。

3、本文以作者本人在19年4月整理的angular生態(tài)進(jìn)行UI組件庫選型為例，進(jìn)行流程和指標(biāo)的解釋妻熊，案例時間久遠(yuǎn)夸浅，只幫助內(nèi)容理解，不做選型推薦扔役。

2 流程簡介

干貨開始帆喇，分享一下我的選型流程：

選型步驟.png

流程簡介：

1. 圈定范圍：根據(jù)環(huán)境因素（團(tuán)隊和行業(yè)的情況）進(jìn)行組件生態(tài)的初步篩選

2. 確定指標(biāo)：確定你所關(guān)心的分析指標(biāo)及對應(yīng)權(quán)重

3. 數(shù)據(jù)采樣：根據(jù)指標(biāo)對選型范圍內(nèi)的每個“參選者”進(jìn)行數(shù)據(jù)收集

4. 匯總分析：根據(jù)收集的指標(biāo)數(shù)據(jù)進(jìn)行橫向比較，進(jìn)行整體分析

5. 選擇結(jié)果且進(jìn)行兼容性檢查

接下來的內(nèi)容會根據(jù)上述流程結(jié)合案例分享亿胸。

3 流程詳述

3.1 圈定范圍

選型的本質(zhì)是比較和篩選坯钦，那么前提是先確定一個相對較小的選型范圍，便于減少后續(xù)分析的工作量侈玄。

那么如何圈定選型范圍婉刀？

3.1.1 信息查找的渠道

我們查找比較新的庫通常會去github或掘金等技術(shù)社區(qū)或者搜索引擎直接搜索，接下來簡單列舉幾個我常用的組件庫查詢途徑：

• awesome topic：如我要找angular相關(guān)的組件庫 awesome-angular-components: Catalog of Angular 2+ Components

• 技術(shù)社區(qū)/公眾號相關(guān)文章：如CSDN的跨端開發(fā)框架深度橫評之2020版

• 官方文檔：如vue官方幫助你打消你選型疑慮的對比其他框架 — Vue.js

• 搜索引擎：建議使用google序仙、DuckDuckGo突颊，如果翻不過去就Bing

3.1.2 初步篩選需要考慮的因素

環(huán)境因素.png

3.1.2.1 團(tuán)隊環(huán)境

• 人員平均技術(shù)能力：在人員平均能力不是特別強(qiáng)的情況下，過于復(fù)雜的庫會增加項目開發(fā)和學(xué)習(xí)的成本潘悼。

• 人員學(xué)習(xí)能力：如果你選擇的庫的復(fù)雜度遠(yuǎn)遠(yuǎn)超出于你團(tuán)隊人員的學(xué)習(xí)的能力律秃，會需要你進(jìn)行二次研發(fā)或封裝，增加研發(fā)成本治唤。

• 團(tuán)隊原有的框架積累：不要輕易放棄團(tuán)隊原有的技術(shù)方向上的積累棒动，同方向的技術(shù)迭代會讓你事半功倍。

3.1.2.2 生態(tài)環(huán)境

為什么要考慮生態(tài)的流行度宾添？

你選擇的庫的流行度決定你招人的難易程度船惨，如果你選了一個小眾的框架，大概率需要付出新招的開發(fā)人員的全部學(xué)習(xí)成本辞槐。

庫的流行度也一定程度上說明了相關(guān)生態(tài)的完善和健康度掷漱，用的人多功能就會相對完善，bug解決的時效性也會更好榄檬。

3.1.2.3 行業(yè)線環(huán)境

• 契合度：舉個例子卜范，我的行業(yè)線使用的是比較復(fù)雜且要求高效的業(yè)務(wù)系統(tǒng)，那么有功能強(qiáng)大的table組件所在組件庫就是更適合我行業(yè)線的鹿榜。

• 運(yùn)行時要求：有些行業(yè)線因為軟件更新要求嚴(yán)格海雪，所以瀏覽器版本落后，可能需要兼容老版本的瀏覽器舱殿。如我19年在組件庫選型時奥裸，支持IE11是必要條件。

3.1.3 我的案例

以下是我根據(jù)當(dāng)時（19年）社區(qū)的流行度和環(huán)境因素圈定的選型范圍：

選型范圍.png

3.2 確定指標(biāo)

3.2.1 指標(biāo)結(jié)構(gòu)

基于自己對生態(tài)的理解沪袭，整理了一份指標(biāo)（累死我了湾宙，手動狗頭），還有很多不完善的地方，僅供參考：

指標(biāo).png

量化方式因為太多了侠鳄，會在第三節(jié)進(jìn)行概括行的分享埠啃，接下來會一一介紹指標(biāo)：

3.2.1.1 基礎(chǔ)指標(biāo)

1. *生命周期階段：簡單看一下即可，無需量化數(shù)據(jù)伟恶，重點在于判斷庫是否處于不穩(wěn)定或無人維護(hù)的狀態(tài)碴开。

   • 是否有release版本：判斷該庫是否處于不穩(wěn)定狀態(tài)，通常我們會通過避免使用一個太”新”的庫來規(guī)避技術(shù)風(fēng)險博秫。

   • 官方是否仍有升級計劃：判斷該庫官方是否還持續(xù)投入

   • 最近一次feat或fix的更新時間：或是否聲明即將停止維護(hù)潦牛，判斷該庫是否處于停止維護(hù)狀態(tài)

2. *社區(qū)活躍度：是最重要的考量標(biāo)準(zhǔn)之一。和買車一樣挡育，銷量高的無論是維修還是保養(yǎng)都便宜巴碗，出小毛病還能容易找到解決方案。

   • google trend的搜索指數(shù)：最好從整體和區(qū)域兩個維度分析静盅，庫可能存在地域性良价，比如下圖：vue在中國的搜索指數(shù)遠(yuǎn)遠(yuǎn)高度其他國家。

     vue世界熱度分布.png

   • github的star數(shù)量：一定程度上能說明受歡迎的程度

   • github的issue應(yīng)答率和應(yīng)答速度：是判斷一個庫是否活躍的重要因素

   • github的Pull requests close比例：是判斷一個庫是否活躍且穩(wěn)定的重要因素蒿叠，某些庫在生命的末期或者不活躍后明垢，可能存在缺乏人員維護(hù)的情況，如ant Design的mobile版本市咽、element ui都出現(xiàn)過類似的問題痊银。

   • npm下載數(shù)量和趨勢：能夠很大程度上反應(yīng)一個庫的用戶數(shù)量

   • code的Contributions圖：是判斷一個庫是否活躍的重要因素

3. 安全可控

   • 是否開源：需要識別一下源碼是否完整

   • 是否有大公司（團(tuán)隊）主導(dǎo)：大多數(shù)成功的開源項目都是有一個穩(wěn)定的團(tuán)隊維護(hù)，這樣能更好的保證框架的穩(wěn)定和生命力

4. *功能完善度：是最重要的考量標(biāo)準(zhǔn)之一施绎。

   • 特性覆蓋率：量化方式可參考3.1.2

3.2.1.2 環(huán)境指標(biāo)

1. *業(yè)務(wù)（行業(yè)線）契合度：是最重要的考量標(biāo)準(zhǔn)之一溯革，可與“功能完善度”一同分析。

   • 重點特性完善度

2. 運(yùn)行時版本要求

   • 要求的最低支持的瀏覽器/Node版本：量化方式可參考3.1.1

3. 生態(tài)流行度

   • 同基礎(chǔ)指標(biāo)的社區(qū)活躍度

3.2.1.3 研發(fā)成本

1. 工程化完善程度

   • 編譯產(chǎn)出物是否支持多方式引入

   • 源碼組織方式（mono-repo還是multi-repo）

2. 代碼是否有良好的設(shè)計：大型的庫基本可以放心谷醉，良好的設(shè)計會讓代碼擁有更好的可讀性致稀，方便維護(hù)和升級。

   • 是否漸進(jìn)式提供：一個庫優(yōu)秀的public API設(shè)計能力的前提是源碼的清晰的構(gòu)造層次俱尼，這也是代碼擁有更好可讀性的前提抖单。

   • 庫結(jié)構(gòu)的抽象程度：是代碼是否好修改的考量因素之一。

3. 研發(fā)文檔完善度

   • 是否有貢獻(xiàn)指南

   • 是否有二次開發(fā)文檔

   • 源碼工程中是否有研發(fā)demo：有一個閉環(huán)可驗證的demo是提升研發(fā)效率和研發(fā)質(zhì)量的前提遇八。

   • 源碼工程中是否有完善的測試用例

3.2.1.4 開發(fā)/學(xué)習(xí)成本

也就是使用成本矛绘。

1. API簡潔程度

   • API面積（個數(shù)）：無論是考慮開發(fā)成本還是學(xué)習(xí)成本，單個庫的大面積的API都是災(zāi)難刃永。

2. *文檔完善度：好的文檔是一個好的開始货矮，也是能節(jié)省推廣成本和降低推廣阻力的途徑之一。

   • 可讀性

   • 是否有源碼示例

   • 是否有可交互DEMO

   • 國際化程度（是否有中文）

   • 是否有歷史文檔

   • 文檔美觀度

3.2.1.5 用戶體驗

一般UI組件庫才需要的衡量指標(biāo)斯够，這塊的知識體系需要一些設(shè)計知識囚玫，如果有時間喧锦，會單獨(dú)寫一篇詳細(xì)展開。

3.3 數(shù)據(jù)采樣

僅舉例部分指標(biāo)的量化方式劫灶，本節(jié)重點展示采樣對比的效果裸违。

3.1 如何量化指標(biāo)（有時間再整理）

3.1.1運(yùn)行時版本要求：

• 最直接的就是查閱github主頁上的 Browser Support /Environment Support

• 去官方文檔中查閱

• ISSUE查找

3.1.2 特性覆蓋率：

• 目標(biāo)庫的特性（功能/組件）數(shù)量/需求的特性（功能/組件）數(shù)量

3.2 我的案例

3.2.1 搜索指數(shù)

1. 趨勢對比

   一年內(nèi)的趨勢.png

2. 流行區(qū)域

   流行區(qū)域.png

3.2.2 項目背景

項目背景.png

3.2.3 社區(qū)活躍度

1. 社區(qū)支持

社區(qū)支持.png

2. 貢獻(xiàn)

Contributions.png

3.2.4 功能完善度

功能完善度1.png

功能完善度2.png

3.2.5 重點特性完善度

重點特性完善度.png

3.2.6 二次研發(fā)分析

以material2為例：

material2.png

3.4 匯總分析

3.4.1 客觀分析

客觀分析.png

3.4.2 主觀結(jié)論

主觀結(jié)論.png

3.5 選擇結(jié)果且進(jìn)行兼容性檢查

選型后，記得檢查和你使用其他庫的預(yù)依賴本昏。

4 寫在最后

本文主要是對過去知識體系的梳理和完善，將選型思路根據(jù)自己的知識體系分享出來枪汪，希望能給更多的人提供思路涌穆。

無論是流程還是量化的指標(biāo)，都是和我的知識體系緊密聯(lián)系的雀久，所以并不是適合任何情況的選型分析宿稀，僅作為選型分析和庫本身分析的參考。

附錄：系列文章的目錄結(jié)構(gòu)

1赖捌、前言：一點對于前端框架設(shè)計的淺顯思考

2祝沸、前端技術(shù)研發(fā)人員的能力模型

3、如何進(jìn)行前端選型越庇？

4罩锐、如何畫好一個前端框架圖？

5卤唉、如何進(jìn)行前端框架推廣涩惑？

6、關(guān)于開發(fā)人員支撐形態(tài)的見解

7桑驱、如何根據(jù)用戶（開發(fā)人員）反饋進(jìn)行框架優(yōu)化竭恬？

8、前端框架用戶體驗方向的思考

9熬的、專題1：前端自動化解決方案

10痊硕、專題2：前端研發(fā)流程下的權(quán)限控制