參與開源專案很難嗎？

捉蟲大師發表於2022-03-31

hello大家好，我是小樓。

流量真是個讓人捉摸不透的東西，有時候寫了一篇自己感覺牛的不行的文章，結果閱讀資料慘淡，有時候覺資料可能沒那麼好的文章，實際資料卻出乎意料。

image

之前的文章《慘，給Go提的程式碼被批麻了》就是這樣，我以為就一般吧吧，沒想到卻“火了”。

這篇文章截止目前，發表的20天時間裡，在掘金閱讀量突破1w，知乎閱讀量突破1.8w，頭條閱讀量破1.7w，微信公眾號的閱讀加上被轉載的閱讀也有1w，就連公司內網的閱讀都有3k。

可以說這個資料是我從寫公眾號以來最好的了，但我並不覺得它是我寫得最好的文章，所以就很迷。

好了，以上只是寫技術文過程中的一點點驚喜，這樣的驚喜是我繼續寫好文章的最大動力，所以動動你們的小手，點贊+在看+轉發安排起來。

今天我就順著這篇文章來聊聊大家可能都比較感興趣的話題，開源。本文會結合自己的一些看法，從參與開源專案的收益和如何參與開源專案兩個方面展開。

參與開源專案的好處

首先要明確，為什麼要參與開源專案？總得對我有點好處吧。每個人可能追求不一樣，所以我這裡就列舉一下我知道的好處，看看有沒有戳中你的點。

  • 小禮品

這點可能是被很多人忽略的點，因為太小了，但確實也算得上一個好處。如果你掌握了一些技巧，每年從開源社群拿點小（薅）禮（羊）物（毛）是很easy的。尤其是國內的社群，T恤、杯子、揹包等等是很容易拿到的。

比如這兩年Nacos、Dubbo社群送我的一些杯具：

image

image

據我觀察，阿里的開源專案只要每年都去提一個PR，很大概率會送你禮物，不管這個PR是大是小，可以大到貢獻一點原始碼，也可以小到format一下程式碼、修改文件中的一些錯誤、增加一個單元測試等等，所以是不是學到了薅羊毛的技巧？

  • 朋友圈素材

這點只是滿足一下虛榮心，其實並沒有什麼卵用，但還是提一嘴，比如下面這些素材，是發朋友圈裝x的利器：

image

image

image

  • 裝飾簡歷

如果你有參與開源專案的經歷，寫到簡歷上一般是個加分項，說一般情況是因為我在面試的時候遇到過候選人在簡歷上這樣寫：

參與貢獻過上萬star的專案。（後面還貼上了專案地址）

一看這句描述就有貓膩，為啥強調上萬star卻不說出專案名稱？於是我開啟後面的github地址發現，原來這個上萬star的專案是個聚合線上學習資料的專案。

不能說參與這樣的專案不好，只是簡歷上這句話讓我感覺在打擦邊球，所以不但沒有加分，反而減分了。

一般來說對專案有過貢獻，無論大小，都可以稱之為Contributor，貢獻達到一定程度則稱為Committer，達到多少貢獻才能稱為Committer一般每個社群都有自己的衡量標準，比如Nacos社群有明確的規定：

image

翻譯下就是：至少有8個PR，團隊協作能力，理解專案的程式碼風格，能寫出優秀的程式碼。當然也有很多社群沒有明文規定，總之就是貢獻越多越有可能成為Committer。

所以在簡歷中如果你是某個專案的Committer就很厲害了，一詞勝千言。退一步就算不是Committer，如果你有一些比較重要或者核心的程式碼提交，也可以寫上，附上具體的issue。如果只是程式碼的format、增加一些單元測試，我建議簡歷上就不要提了。

  • 能力提升

通常開源專案的程式碼、設計、規範都是比較優秀的，和優秀的人一起共事能成長更快。

一般我們在參與開源專案時，都是使用英文來交流，所以對你的英文書寫能力是個提升。

其次程式碼規範、測試能力、考慮事情的全面性都將得到鍛鍊。

以我個人的感受來說，雖然嘴上說寫程式碼要規範，但在公司寫程式碼的時候，有時候就不太注意，都是以快速完成任務為目標，但開源專案不一樣，你寫的每一行程式碼都要被眾多的大佬一行一行地review，只要有一點點不滿意都會要求你修改。

測試也是如此，你寫的每一行程式碼都將被程式碼測試，單元測試、整合測試。開源專案更相信用程式碼測試，所以這也鍛鍊了你寫測試和寫程式碼的能力，寫出程式碼不難，寫出容易測試的程式碼還是比較困難的。

  • 提升影響力

這是更高層級的追求，當你想在技術上走的遠的時候，需要一些業界影響力，這時，參與開源是個不錯的選擇，能結識更多的圈內牛人，也讓大家能認識你，你的圈子、人脈就會擴張。

提升影響力有什麼作用呢？最直接的是，讓別人知道你的存在，下一次機會來臨時，說不定你會被看中或者推薦。

當然我離這個層次還很遠，只是說一點自己的理解。

如何參與開源專案

  • 參與開源的方式

上文其實也提到了，參與開源專案不一定是直接的貢獻原始碼，也可以是對文件的編寫或修正、寫一些單元測試或者測試用例、也可以寫一些開源專案相關的文章。

比如我在去年寫《Dubbo為什麼要用Go重寫？》這篇文章時，就順手把Dubbo-go專案的README改了

image

還有比如在寫《使用dubbo-go搭建dubbo介面測試平臺》這篇文章時，把這篇文章投稿給了Dubbo-go官方網站，也被收錄進去

image

這些都算是對開源的一種貢獻。當然如果你有程式碼的直接貢獻是最好的，這也是獲得技術成長最快的方式。

  • 從哪裡開始

如果我們平時工作中用到什麼開源專案，沒事的時候可以把原始碼下載下來翻一番，可以按照文件跑起來，打上斷點看看是否跟自己想的一樣，這時我們便有了一些基礎，可以去github上的issue找找，一般的專案會把issue分類，可以從標了good first issue或者bug標籤的issue看起，看看有沒有自己能解決的，再結合程式碼，一步一步除錯。

這種方式目的性比較強，我就是衝著提交程式碼去的，而且比較有時間去研究，目前我還沒用過這種方式，我更多的是下面提到的這種方式。

另外一種是如果我在使用開源專案的過程中發現了一個bug，或者一個可以優化的點，可以去github上提個issue先討論討論，如果社群的人也認可你的觀點，可以把你的修復或者修復作為一個PR提交上去。

這個方式我在Dubbo/Sentinel/Nacos/Skywalking/Go中都是這麼幹的，都是平時遇到的一些問題，反哺到社群。

發現問題往往比解決問題更困難，開源專案也是如此。

等等，在你想提交程式碼前，我建議你好好看看開源專案的規範，一般位於專案的README或者官網中，他對issue有什麼要求，對程式碼有什麼要求，對commit message等等都有什麼樣的要求，如果不按照這些規範來提交，可能你的下場會和我一樣，一個字「慘」。

  • 提交程式碼流程

這一步網上資料比較多，我這裡只說個大概的流程，具體到每一步我相信你能在網上找到更詳細的教程：

  1. 提issue討論（不是必須，有些專案可以直接提程式碼）
  2. fork程式碼倉庫
  3. 在fork的程式碼倉庫拉一個分支，並把程式碼提交到這個分支上
  4. 簽署Contributor License Agreement（簡稱CLA）
  5. 在這個倉庫上向原倉庫發起一個PR
  6. 等待程式碼Review反饋，並按照反饋修改
  7. Merge進程式碼倉庫，貢獻完成

最後說一句

萬事開頭難，往往第一個PR是最難提交的，如果嘗試著提交了，我相信你會開啟新世界的大門。

對了，雖然我參與到開源專案的經驗不夠多，但可以給你一點參考，有正例也有反例

好了，今天的分享到此為止，我們下期再見！

搜尋關注微信公眾號"捉蟲大師"，後端技術分享，架構設計、效能優化、原始碼閱讀、問題排查、踩坑實踐。

相關文章