正確開始你的前端開源項目

簡單總結幾個常見誤區：

誤區一：

什麼才是前端開源的核心?

很多人覺得我把我的代碼扔出去就可以了，我也不管別人看不看，我也不管別人有用沒有用，總之我把我的code一扔，就算完成任務，這真的是大錯特粗，開源項目不是伸手黨的福音，但是它也不能只是你堆砌簡歷的一行URL。

我認為一個成功的前端工具或者框架項目，他一定是解決了一些其他同類項目無法解決的問題，或者有更優秀的性能，更好的開發者體驗或者更優的開發效率，又或者一個成功的前端項目從一開始就是解決了市面上別人都無法解決的問題，痛點，或者某個業務場景，性能瓶頸，或者優雅封裝。

如果一開始就把開源項目當成練手，那麼結局往往是比較失敗的，只有一開始就給項目定位成一個實際的，切實可行的解決方案，那麼它很可能結局就大不相同，甚至贏在了起跑線上。

這又和創業何嘗不是相通的啊。

誤區二：

混亂的項目結構，只關注結果不關注過程

有些人做的工程，往往只關注API部分和代碼最後執行結束的結果，總之無論如何，最後我的代碼能運行，能跑通，列印無錯就沒事了，這也是大錯特錯了。

開源項目和公司內部項目其實本質上的差別就是，公司項目關注結果，當然也關注過程，開源項目往往更關注過程超過結果，為什麼這樣說呢？

因為過程決定了質量，如果一個項目的質量和性能得不到保證，代碼寫的一塌糊塗毫無邏輯可言，項目結構凌亂加上沒有完整的測試覆蓋率，這樣的項目就算結果是保證的，誰又敢去用？而開源最終的目的是讓別人參與進來一同貢獻代碼，沒有一個好的規範，別人誰又如何參與呢？

所以這一點也是很多人開源項目做不長的問題，代碼混亂，別人無從參與下手，第三方對代碼存在懷疑，別人只好放棄。

誤區三：

缺少自動化集成和測試，項目代碼只是一氣呵成寫完的，之後再也不考慮維護

所謂的自動化集成，其實就是快速搭建起本地項目開發環境，這對於開源項目至關重要，如果別人搭項目環境都需要非常複雜的教程，驗證結果也非常困難，又讓別人如何有興趣參與其中呢？至於測試，是保證別人pr的代碼不影響已有邏輯的最後一關，我參與pr的很多項目，如果對你的修改部分不額外增加test用例，肯定是不會被merge的，覆蓋率不全也不會。這已經是開源開發者的共識。

只有考慮了長久的項目和後續的服務，以及環境集成，才會吸引更多人的使用和提交貢獻。

自動化集成的包含的面很廣，從第三方依賴的檢查，測試用例的執行，瀏覽器型號的測試覆蓋，自動編譯構建，版本更新等，這些都是成功項目必備的一環，甚至readme和代碼提交量的統計都可以做成自動的。

誤區四：

文檔和測試用例僅僅是寫了，也不夠，很多人沒有國際化概念

大家都知道，github或者gitlab等開源項目託管網站的用戶大部分是全世界的用戶，你的項目如果只有中文文檔肯定是不行的，包括發布到npm上去之後，可以見到非常多的chinese only的項目，這就阻擋了一部分用戶的門檻，雖然很多老外也會用漢語翻譯軟體。。。

然後就是測試用例的輸出，比如describe和it等輸出的語法邏輯詞不達意，甚至都是和用例完全不貼邊的，這也會對使用者造成非常大的誤解。

所以標準英文化文檔，是非常重要的一關，國際化概念要始終植入開發者的心中（ps：代碼注釋同理）。

誤區五：

不了解gitflow流程或者說自己開發根本不用branch，也不打tag，也不發releases

這裡其實無論是什麼項目，遵守一定的代碼管理規範和開發規範，才能最小化影響用戶，最簡單的例子，主幹上的修改肯定會影響一些新用戶的使用，如果文檔和用例不及時增加，那麼最後導致的就是別人會覺得你的項目充滿了bug。

框架，工具也是工程，工程管理的需求依然十分強烈。

誤區六：

項目不再維護，或者沒有精力維護，俗稱挖坑

挖坑不填很多人都有這個毛病，或者自己的項目沒有遇到bug，別人使用後提了bug，根本不看不管，這些都會導致用你的項目的人越來越少，看看Vue.js的成功經驗，就是作者常年在一線issues中摸爬滾打，這也是一個優秀項目必經之路，當然我有時候也死在這一步上。

誤區七：

酒香也怕巷子深

很多人寫了非常牛逼的代碼，做了非常完善的測試和文檔，但是就是好於面子，根本不宣傳，總覺得別人能夠搜索到，其實並不是的，好的項目配套好的運營才能讓更多人使用和接受，口口相傳才是王道，如果你自己都不推廣自己的項目，還怎麼好意思讓別人幫你宣傳。

優秀的項目不怕被分享，該去發文章該去找用戶這些都是一個成功開源前端項目的必經之路！

ok，以上7點都是我根據我的live大綱總結提煉出來的，這篇文章只是預熱，到底如何避免和操作這幾大誤區，我的live本周六晚上，我針對以上幾大誤區和我的個人經驗，會再一一詳細解答。

希望上面的這些內容能夠吸引你走進開源的世界，也歡迎分享我的live：知乎 Live - 全新的實時問答