如何參與一個頂級開源項目

前言

最近我的事情比較多（搬家、換工做、短暫休息）因此一直也沒有顧得上博客更新，剛好最近收到一封郵件提醒了我。

也是時候寫一篇文章來聊聊參與開源項目的事（最近也確實進入了筆荒期）。

ps:第一次收到這樣的中秋節禮物，加上 Dubbo 社區的活躍及阿里的重視度，還在作 RPC 或微服務技術選型的朋友能夠考慮 Dubbo。

參與開源

如今具體來聊聊參與開源的事；

平常幾乎全部的開發者都會享受到開源項目所帶來的便利甚至是收益，受限於環境早在十幾年前甚至幾年前開源活動一直都是有國外開發者主導。

但這幾年國內互聯網公司逐漸國際化擴大影響力也很大程度的提升了咱們的開發水平，以 BAT 爲首出現了許多優秀的開源項目。

如今甚至參與開源項目還能另闢蹊徑的拿到大廠 offer，因此其實很多朋友都想參與其中，可能這事給人的第一感受就不太容易，因此如今還卡在第一步。

具體步驟

如下是以我我的經驗總結的幾大步驟：

• 發現問題或自薦 feature 。
• fork 源碼。
• 本地開發、自測。
• 發起 pull request 。
• 等待社區 Code Review 。
• 跟進社區意見調整代碼。
• 審覈經過，合併進 master 分支，完成本次貢獻。

下面我會結合最近一次參與 Dubbo 的流程來具體聊聊。

發現問題或自薦 feature

首先第一步天然要搞清楚本身本次貢獻的內容是什麼？一般都是解決某個問題或者是提交一個新的 feature ；前者相對起來更加容易一些。

固然這個問題能夠是本身使用過程當中發現的，也能夠是 Issues 列表中待解決的問題。

以本次爲例，就是我在使用過程當中所發現的問題，也提交了相關 Issue 並寫了一篇文章記錄並解決了該問題：What？一個 Dubbo 服務啓動要兩個小時！

值得注意的是在提交 Issue 以前最好是先在 Issue 列表中經過關鍵字檢索下是否已經有相關問題，避免重複。

同時提交以後也許社區會進行跟進，被打上 invalid 標籤認爲不是問題，或者是使用姿式不對也是有可能的。

fork 源碼，本地開發

當肯定這是一個待修復的問題時就能夠着手開發了。

首先第一步天然是將源碼拷貝一份到本身倉庫中。

接着只須要 clone 本身倉庫中的源碼到本地進行開發。

先回顧下我遇到的這個問題。

簡單來講就是啓動 Dubbo 服務很是緩慢，通過定位是 main 線程阻塞在了獲取本機 ip 處。

因此當時我提出的方案是：在獲取本機 ip 時加上超時時間，一旦超時便拋出異常或者是再次重試，但起碼得有日誌方便用戶定位問題。

問題是主線程會一直阻塞在此處 InetAddress.getLocalHost().getHostAddress()，但又須要知道它阻塞了多久纔好判斷是否超時。

因此只能再額外開啓一個線程，定時去檢測 main 線程是否已經完成任務了，如下即是我第一次 pr 的內容。

此次的重點不是討論這裏具體的技術細節，因此簡單說下步驟：

• 額爲聲明瞭大小爲 1 的線程池。
• 再聲明瞭一個 volatile 標誌用於判斷主線程是否有完成任務。
• 聲明瞭一個 condition 用於新線程作等待。
• 最後只須要運行這個線程用於判斷這個標誌便可。

如何自測

開發完成後下一步就是自測，因爲這類項目是做爲一個基礎包依賴於其餘的項目才能運行的，因此一般咱們還得新建一個項目來配合作全流程測試（單測除外）。

這裏我以爲仍是有幾個小技巧值得注意。

第一個是版本號；由於在本地測試，因此須要使用 mvn clean install 將包安裝到本地才能在其餘項目中依賴進去進行測試。

但因爲咱們從官方拉出來的代碼版本都已經發布到了 maven 中央倉庫中（不論是 release 仍是 snapshot），因此咱們本地倉庫中確定已經存在這幾個版本的 jar 包。

一旦咱們執行 mvn clean install 將本身修改的代碼安裝到本地時，大機率是會出問題的（也多是我姿式不對），這樣就會致使新建的項目中依賴不了本身新增的代碼。

因此我一般的作法是修改版本號，這個版本號是歷來沒有被官方發佈到中央倉庫中的，能夠確保本身新增的代碼會以一個全新版本安裝到本地，這樣咱們再依賴這個版本進行測試便可。

不過再提交時得注意不要把這個版本號提交上去了。

發起 pull request

自測完成後即可發起 pull request 了，不要大意，這裏還得有一個地方須要注意，那就是代碼換行符的問題。

一旦換行符與源倉庫的不一致時，git 會認爲此次修改是刪除後重來的，這樣會給 code review 帶來巨大的麻煩。

就像這樣，明明我改動的行數並很少，但 git 確認爲你是推翻了重來，致使審覈起來根本不知道你改了哪些地方。

最簡單的方法就是設置本身 git 的全局配置，能夠參考這裏。

# 提交時轉換爲LF，檢出時轉換爲CRLF
git config --global core.autocrlf true

# 提交時轉換爲LF，檢出時不轉換
git config --global core.autocrlf input

# 提交檢出均不轉換
git config --global core.autocrlf false

確認沒問題後即可點擊這裏發起 pull request，後面按照引導執行便可。

固然各個項目之間還會有本身定製的貢獻流程，最好就是查看官方的貢獻指南。

http://dubbo.apache.org/en-us/docs/developers/contributor-guide/new-contributor-guide_dev.html

Code Review

pr 發起後即可等待社區審覈了。

在這過程當中要充分和社區進行交流，有可能你的方案和社區的想法並不一致。

好比像我此次：

最終經過溝通加上本身後面的思考以爲仍是社區的方案更加輕便合理一些，達成一致以後社區便將此次 pr 合併進 master 中。

其實整個過程我以爲最有意義的即是 code review 的過程，全部人均可以參與其中頭腦風暴，其中也不乏技術大牛，不知不覺便能學到很多東西。

相似案例

雖然我以前的方案沒有被採納，但相似的用法（一個線程監控其餘線程）仍是很多，正好在 Dubbo 中也有用到。

即是其中核心的服務調用，默認狀況下對使用者來講這看起來是一個同步調用，也就是說消費方會等待 RPC 執行完畢後纔會執行後續邏輯。

但其實在底層這就是一個 TCP 網絡包的發送過程，自己就是異步的。

只是 Dubbo 在你不知道的狀況下作了異步轉同步，這樣看起來就像是一個同步方法。

如圖中的紅框部分，Dubbo 自身調用了 get() 方法用於同步獲取服務提供者的返回結果。

邏輯其實也挺簡單，和我上文的方案相似，只是這裏的 isDone() 函數返回的是是否已經拿到了服務提供者的返回值而已。

總結

本次總結了參與開源的具體步驟，其實也挺簡單；就如官方所說哪怕是提個 Issue，修改一個錯別字都算是參與，因此不要想的太難。

最後還簡單分析了 Dubbo 調用過程當中的異步轉同步的過程，掌握這些操做對本身平時開發也是頗有幫助的。

你的點贊與分享是對我最大的支持