做好一個開源項目其實是一件比較費時費力費心的工作，它的最大難點除了代碼維護之外，還包括后期的維護和持續的跟進。我曾經做過不少開源項目，但是堅持下來的，目前有信心能夠持續維護的也只有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）充分的測試
代碼寫好了，上去就是干明顯就是挖坑。隨着項目的時間越長，代碼重構或者功能迭代就越需要測試的保障，而不是個人感覺或者編譯通過即可。
那么如何做好充分的測試呢？
-
完善的單元測試
每一次功能迭代或者Bug修復，均要完善好相關的單元測試。單元測試是代碼可靠程度的最基本的保障。
-
盡可能提高代碼覆蓋率
代碼覆蓋率作為一個指導性指標，可以一定程度上反應測試的完備程度，是軟件質量度量的一種手段。100%覆蓋的代碼並不意味着100%無bug的應用，代碼覆蓋率作為質量目標沒有任何意義，而我們應該把它作為一種發現未被測試覆蓋的代碼的手段。
通過代碼覆蓋率測試，我們可以了解測試過程中覆蓋和未覆蓋的地方，可能存在的風險。分析未覆蓋代碼，反推在測試設計是否充分，進一步明確測試設計階段的問題。
代碼覆蓋率測試也有助於我們發現測試死角、冗余代碼、歷史廢棄代碼，便於重構。
-
使用自動化測試來保障每次提交和驗證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等等。
