組隊
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 （非誠勿加）
或者掃碼：
