如何作好一個開源項目（一）

作好一個開源項目實際上是一件比較費時費力費心的工做，它的最大難點除了代碼維護以外，還包括後期的維護和持續的跟進。我曾經作過很多開源項目，可是堅持下來的，目前有信心可以持續維護的也只有Magicodes.IE。這裏請容許我來一波硬廣：

Magicodes.IE

導入導出通用庫，支持Dto導入導出以及動態導出，支持Excel、Word、Pdf、Csv和Html。已加入NCC開源組織。

• Github：https://github.com/dotnetcore/Magicodes.IE
• 碼雲（手動同步，不維護）：https://gitee.com/magicodes/Magicodes.IE

如何打造一個好的開源項目？

咱們迴歸正題。如何作好一個開源項目呢？接下來來講道說道：

1）有一個好的理念和創意

若是你們都在作重複的事情，可是又沒有合適的輪子的時候，那麼咱們就能夠創造一個。

若是輪子不少，可是沒有好用的，或者不夠通用，那麼咱們就能夠動手寫一個。

Magicodes.IE就是在這種狀況下誕生的。導入導出是一個很是廣泛的場景，相關的組件也不少，好比就拿導出Excel來講，主流的就有EPPlus、NPOI等等庫。那麼爲何咱們還須要再造輪子呢？由於咱們發現，在大部分場景下使用這些庫咱們都須要進行一些重複性的編碼以及特定針對Excel的操做的編碼才能知足咱們的需求，那麼有沒有更合適的作法？因此就有了Magicodes.IE，經過設置Dto就能知足大部分導入導出的場景，而且還支持除了Excel以外的其餘導入導出格式。

2）寫好代碼

代碼規範，易於閱讀這些都是必不可少的。尤爲是在多人遠程協做的狀況下，代碼審閱，按期重構也很是有必要。不然你們就算是想貢獻代碼，可是也要看得懂不是？

3）充分的測試

代碼寫好了，上去就是幹明顯就是挖坑。隨着項目的時間越長，代碼重構或者功能迭代就越須要測試的保障，而不是我的感受或者編譯經過便可。

那麼如何作好充分的測試呢？

1. 完善的單元測試

   每一次功能迭代或者Bug修復，均要完善好相關的單元測試。單元測試是代碼可靠程度的最基本的保障。

2. 儘量提升代碼覆蓋率

   代碼覆蓋率做爲一個指導性指標，能夠必定程度上反應測試的完備程度，是軟件質量度量的一種手段。100%覆蓋的代碼並不意味着100%無bug的應用，代碼覆蓋率做爲質量目標沒有任何意義，而咱們應該把它做爲一種發現未被測試覆蓋的代碼的手段。

   經過代碼覆蓋率測試，咱們能夠了解測試過程當中覆蓋和未覆蓋的地方，可能存在的風險。分析未覆蓋代碼，反推在測試設計是否充分，進一步明確測試設計階段的問題。

   代碼覆蓋率測試也有助於咱們發現測試死角、冗餘代碼、歷史廢棄代碼，便於重構。

3. 使用自動化測試來保障每次提交和驗證PR

   開源項目有不少DevOps的服務能夠選擇，咱們能夠基於其打造本身的自動化測試來保障開源項目的質量，以針對每次提交、PR進行驗證，而且做爲資源發佈的參考依據。

4）友好的文檔

文檔一直是開源項目運做的一個難題：

• 代碼寫的歡，文檔難產。
• 本地化文檔（中文文檔）沒問題，其餘語言文檔（英文文檔）難以編寫。
• 文檔的更新永遠跟不上代碼的更新，版本的迭代。

友好的文檔一直是開源項目吸引用戶的首要標準，因此文檔是必須的。

Magicodes.IE的文檔也在積極補充和完善之中，但願你們可以多多支持。

 

5）版本規劃和管理

對於開源項目來講，版本規劃和發佈版本也不該該是一件隨意的事情。畢竟錯誤的版本可能會給用戶帶來災難性的問題。不合理的規劃，也可能會將項目帶入溝渠。

這裏分享幾個經驗：

• 版本規劃咱們經過收集反饋來進行規劃。如Magicodes.IE就經過Issue收集用戶反饋、討論以推出新的版本：

• 資源發版提供詳細的版本日誌，以供用戶參考和追蹤：

• 測試版預先發布Beta版的包，如上圖中的2.2.0-beta2。

6）作好推廣

其實也就是讓可能須要他、真正須要他的人知道他的存在。從技術人的角度建議以下：

• 和技術社區合做，分享乾貨，不水羣，不瞎聊
• 加入知名開源組織，好比Magicodes.IE就加入了NCC開源組織
• 不要理會噴子。幹本身認爲有價值的事情，不要理會那些只會噴可是啥也不會作的麻瓜。對於開源做者傷害最大的其實就是噴子和嘴炮，你們都是利用業餘精力去支持和付出，爲社區作貢獻，不圖你支持，可是但願你別圖一時嘴快！不愛用那你就滾啊，很差用那你寫個更好用的分享出來啊！

7）關注反饋，持續更新

• 從Issue中來，到代碼中去。

  在開源項目達到必定規模時，社區就會給出很是多的反饋。這是單兵做戰確定是不適合的，那麼適時組成本身的開源團隊或者開源管理委員會就很是有必要了。同時，社區反饋的不少問題每每都是過於偏具體業務的需求，這時就須要咱們去抽取出通用的需求了。

• 歡迎PR，及時處理PR！

  開源項目在前期每每均只能利用業餘精力運做，那麼每個PR都是很是寶貴的，團隊必定要及時驗證並處理。先以功能優先，再適當重構。

• 大小版本提早規劃，小版本快速迭代！

開源項目既須要有長期的規劃，以確保長期的方向，也須要有短時間的計劃和目標。這樣對團隊對用戶都是有幫助的。同時小版本規劃或者考慮的功能也能夠經過Issue的方式和用戶探討：

最後

本篇僅是筆者結合Magicodes.IE講解如何作好一個開源項目的第一篇，接下來，咱們會講解如何基於開源項目完成徽章、DevOps等等。