hello大家好，我是小樓，
流量真是個讓人捉摸不透的東西，有時候寫了一篇自己感覺牛的不行的文章，結果閱讀資料慘淡，有時候覺資料可能沒那么好的文章，實際資料卻出乎意料，
之前的文章《慘，給Go提的代碼被批麻了》就是這樣，我以為就一般吧吧，沒想到卻“火了”，
這篇文章截止目前，發表的20天時間里，在掘金閱讀量突破1w，知乎閱讀量突破1.8w，頭條閱讀量破1.7w，微信公眾號的閱讀加上被轉載的閱讀也有1w，就連公司內網的閱讀都有3k，
可以說這個資料是我從寫公眾號以來最好的了，但我并不覺得它是我寫得最好的文章，所以就很迷，
好了，以上只是寫技術文程序中的一點點驚喜，這樣的驚喜是我繼續寫好文章的最大動力，所以動動你們的小手，點贊+在看+轉發安排起來，
今天我就順著這篇文章來聊聊大家可能都比較感興趣的話題，開源，本文會結合自己的一些看法，從參與開源專案的收益和如何參與開源專案兩個方面展開，
參與開源專案的好處
首先要明確，為什么要參與開源專案？總得對我有點好處吧，每個人可能追求不一樣，所以我這里就列舉一下我知道的好處，看看有沒有戳中你的點，
- 小禮品
這點可能是被很多人忽略的點，因為太小了，但確實也算得上一個好處，如果你掌握了一些技巧，每年從開源社區拿點小（薅）禮（羊）物（毛）是很easy的，尤其是國內的社區，T恤、杯子、背包等等是很容易拿到的，
比如這兩年Nacos、Dubbo社區送我的一些杯具：
據我觀察，阿里的開源專案只要每年都去提一個PR，很大概率會送你禮物，不管這個PR是大是小，可以大到貢獻一點原始碼，也可以小到format一下代碼、修改檔案中的一些錯誤、增加一個單元測驗等等，所以是不是學到了薅羊毛的技巧？
- 朋友圈素材
這點只是滿足一下虛榮心，其實并沒有什么卵用，但還是提一嘴，比如下面這些素材，是發朋友圈裝x的利器：
- 裝飾簡歷
如果你有參與開源專案的經歷，寫到簡歷上一般是個加分項，說一般情況是因為我在面試的時候遇到過候選人在簡歷上這樣寫：
參與貢獻過上萬star的專案，（后面還貼上了專案地址）
一看這句描述就有貓膩，為啥強調上萬star卻不說出專案名稱？于是我打開后面的github地址發現，原來這個上萬star的專案是個聚合在線學習資料的專案，
不能說參與這樣的專案不好，只是簡歷上這句話讓我感覺在打擦邊球，所以不但沒有加分，反而減分了，
一般來說對專案有過貢獻，無論大小，都可以稱之為Contributor，貢獻達到一定程度則稱為Committer，達到多少貢獻才能稱為Committer一般每個社區都有自己的衡量標準，比如Nacos社區有明確的規定：
翻譯下就是：至少有8個PR，團隊協作能力，理解專案的代碼風格，能寫出優秀的代碼，當然也有很多社區沒有明文規定，總之就是貢獻越多越有可能成為Committer，
所以在簡歷中如果你是某個專案的Committer就很厲害了，一詞勝千言，退一步就算不是Committer，如果你有一些比較重要或者核心的代碼提交，也可以寫上，附上具體的issue，如果只是代碼的format、增加一些單元測驗，我建議簡歷上就不要提了，
- 能力提升
通常開源專案的代碼、設計、規范都是比較優秀的，和優秀的人一起共事能成長更快，
一般我們在參與開源專案時，都是使用英文來交流，所以對你的英文書寫能力是個提升，
其次代碼規范、測驗能力、考慮事情的全面性都將得到鍛煉，
以我個人的感受來說，雖然嘴上說寫代碼要規范，但在公司寫代碼的時候，有時候就不太注意，都是以快速完成任務為目標，但開源專案不一樣，你寫的每一行代碼都要被眾多的大佬一行一行地review，只要有一點點不滿意都會要求你修改，
測驗也是如此，你寫的每一行代碼都將被代碼測驗，單元測驗、集成測驗，開源專案更相信用代碼測驗，所以這也鍛煉了你寫測驗和寫代碼的能力，寫出代碼不難，寫出容易測驗的代碼還是比較困難的，
- 提升影響力
這是更高層級的追求，當你想在技術上走的遠的時候，需要一些業界影響力，這時，參與開源是個不錯的選擇，能結識更多的圈內牛人，也讓大家能認識你，你的圈子、人脈就會擴張，
提升影響力有什么作用呢？最直接的是，讓別人知道你的存在，下一次機會來臨時，說不定你會被看中或者推薦，
當然我離這個層次還很遠，只是說一點自己的理解，
如何參與開源專案
- 參與開源的方式
上文其實也提到了，參與開源專案不一定是直接的貢獻原始碼，也可以是對檔案的撰寫或修正、寫一些單元測驗或者測驗用例、也可以寫一些開源專案相關的文章，
比如我在去年寫《Dubbo為什么要用Go重寫？》這篇文章時，就順手把Dubbo-go專案的README改了
還有比如在寫《使用dubbo-go搭建dubbo介面測驗平臺》這篇文章時，把這篇文章投稿給了Dubbo-go官方網站，也被收錄進去
這些都算是對開源的一種貢獻，當然如果你有代碼的直接貢獻是最好的，這也是獲得技術成長最快的方式，
- 從哪里開始
如果我們平時作業中用到什么開源專案，沒事的時候可以把原始碼下載下來翻一番，可以按照檔案跑起來，打上斷點看看是否跟自己想的一樣，這時我們便有了一些基礎，可以去github上的issue找找，一般的專案會把issue分類，可以從標了good first issue或者bug標簽的issue看起，看看有沒有自己能解決的，再結合代碼，一步一步除錯，
這種方式目的性比較強，我就是沖著提交代碼去的，而且比較有時間去研究，目前我還沒用過這種方式，我更多的是下面提到的這種方式，
另外一種是如果我在使用開源專案的程序中發現了一個bug，或者一個可以優化的點，可以去github上提個issue先討論討論，如果社區的人也認可你的觀點，可以把你的修復或者修復作為一個PR提交上去，
這個方式我在Dubbo/Sentinel/Nacos/Skywalking/Go中都是這么干的，都是平時遇到的一些問題，反哺到社區，
發現問題往往比解決問題更困難，開源專案也是如此，
等等，在你想提交代碼前，我建議你好好看看開源專案的規范，一般位于專案的README或者官網中，他對issue有什么要求，對代碼有什么要求，對commit message等等都有什么樣的要求，如果不按照這些規范來提交，可能你的下場會和我一樣，一個字「慘」，
- 提交代碼流程
這一步網上資料比較多，我這里只說個大概的流程，具體到每一步我相信你能在網上找到更詳細的教程：
- 提issue討論（不是必須，有些專案可以直接提代碼）
- fork代碼倉庫
- 在fork的代碼倉庫拉一個分支，并把代碼提交到這個分支上
- 簽署Contributor License Agreement（簡稱CLA）
- 在這個倉庫上向原倉庫發起一個PR
- 等待代碼Review反饋，并按照反饋修改
- Merge進代碼倉庫，貢獻完成
最后說一句
萬事開頭難，往往第一個PR是最難提交的，如果嘗試著提交了，我相信你會打開新世界的大門，
對了，雖然我參與到開源專案的經驗不夠多，但可以給你一點參考，有正例也有反例
- https://github.com/golang/go/pull/50023
- https://github.com/dubbogo/dubbogo.github.io/pull/7
- https://github.com/apache/dubbo/pull/8066
- https://github.com/apache/dubbo/pull/7929
- https://github.com/alibaba/nacos/pull/2403
- https://github.com/alibaba/Sentinel/pull/1045
- https://github.com/alibaba/Sentinel/pull/104
- https://github.com/apache/skywalking/pull/2930
- https://github.com/apache/skywalking/pull/2874
好了，今天的分享到此為止，我們下期再見！
搜索關注微信公眾號"捉蟲大師"，后端技術分享，架構設計、性能優化、原始碼閱讀、問題排查、踩坑實踐，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/453841.html
標籤：其他
上一篇：紫書第三章習題 個人題解