從0到1實現VueUI庫思路

組隊

UI 庫是很龐大的一個項目，若是我的開發，會很佔用個人業餘時間，因此我想到了組隊，便在掘金髮佈一個這樣的事情，很快便召集了20多個前端加入進來。

scrum 敏捷模式

這麼多人加入，怎麼樣的流程管理能保證項目有效進行，讓他們按時按量完成任務，最後保證進度，此時我採起了如今很流行的 scrum 敏捷模式來作流程管理。

選用 tapd 管理工具

國內有不少工具來作 scrum 敏捷模式管理，經投票決議而定，最終選用 tapd。

分出角色

既然打算作一個大型項目，那麼就應該有項目經理、架構師、前端工程師、設計師、產品、測試等角色。

創建迭代 1

我本身擔任了產品和項目經理的角色。做爲產品，迭代 1 我提出的需求很簡單，實現 16 個基礎組件，大概是每一個參與開源小夥伴，一人一個組件的量，很輕鬆。

迭代 1 的開發

作一個 UI 庫項目，迭代 1 的開發任務相當重要，它是一個項目的源頭，若是源頭沒有思考清楚，後面迭代將會是災難性的。進過咱們爬過的坑，我認爲迭代 1 的開發應該作好以下幾件事情：

• eslint 策略
• 制定代碼規範，例如 css 只能採起 BEM 命名規範
• 單元測試
• css 架構
• 分支管理策略，如何讓多人開發，發生代碼衝突機率最小
• 搭建 UI 庫官網，能夠寫組件 API
• 作好 pr ，這是保證代碼質量最後一關

若是其中一個沒有提早作好，咱們能夠想一想後果，例如 css 架構在迭代 1 沒有搭好，後面迭代 x 纔去搭建的話，那麼全部 css 都得按照新架構從新寫，這是個巨大的坑。

迭代 2

迭代 2 需求依然是作一些基礎組件。我着重說下迭代 2 的開發任務，除了實現需求，架構師將重點放在了項目架構上，主要作了以下事情：

• 引入新的 eslint 策略，讓 eslint 僅檢測本身 commit 的代碼，無論其餘人代碼，避免代碼衝突。
• router 全由命令行控制一次性導入，這樣不須要每一個人手動將寫好的組件添入 router 中
• 用命令行生成一個組件模版，無需每次開發組件都去新建文件

迭代 2 其實就是將不少開發上無心義的活，讓命令行自動執行了，讓咱們將注意力放在正確的事情上。

迭代 3

有了前面兩個迭代的基礎，迭代 3 僅需按照已有規範繼續開發新的組件便可。

迭代 x

此後迭代不斷新增，不斷優化組件，直到庫中組件已實現足夠多，也能夠用此庫寫一個完整項目了，即可以發佈第一個版本 npm 包了。

開源項目地址

地址

想參加開源？

如今項目還處於迭代 3 ，初步階段。若是想參加開源，加我我的微信便可：fcsboy （非誠勿加）

或者掃碼：