以前有寫過兩篇文章來簡單聊過如何做開源的事情，最近我自己組了一個社區(qū)里面也有不少朋友對開源感興趣，于是我便根據(jù)自己的經驗系統(tǒng)的梳理了一些關于開源的事情。

• 新手如何快速參與開源項目
• 手把手教你為開源項目貢獻代碼

有興趣的可以先看看之前這兩篇。

??如何找到自己感興趣的開源項目

首先第一步先想清楚自己搞開源的目的是什么：

• 參考社區(qū)大佬的代碼，提升技術
• 豐富個人履歷，提高面試通過率
• 更功利一點就是想成為某個項目的 Committer/PMC
• 單純喜歡分享，熱愛開源，認可開源改變世界??。

我人為前面三種都是一個目的，提升自己獲得后續(xù)的好處；最后一種則是妥妥的純熱愛。

以我個人來說，我兩者都沾一點；我相信大部分人都是前面三類的目的，到這里我可能要先澆點冷水。

往往一個開源項目從你熟悉它開始到提第一個 PR 然后到合并中間經歷的時間可能是大大超出你的預期的。

特別是越大型越專業(yè)的項目（我相信你也是想加入這類有一定知名度的項目）。

因為開源社區(qū)大部分都是執(zhí)行異步溝通，與即時通訊的快速反饋不同，甚至還有不少 reviewer 處于不同的時區(qū)。

所以一開始就想做好心理預期，不要指望著我給某個項目提交一個很牛逼的功能，然后他們快速 review 合并，然后給你 commit 權限。

而且有不少開源項目是由某一個公司主導的，比如（Pulsar、Golang、Kafka），他們可能對于外部社區(qū)來的新手并不那么上心，一個 PR 晾在那里幾個月沒人理都是很正常的。

所以我建議一開始選擇的項目有以下幾個篩選標準：

• 盡量是自己日常在用，熟悉的項目。
• 最近有在及時更新維護的項目。
• 對社區(qū)新人的接納程度是否足夠包容。
• 這點可以在 Github 里查找標簽為 help want/contribution welcome 的 issue 或者是 PR。
• 查看這些 issue/ PR 最近的活躍時間，貢獻者是否為新人。
• 往往一個包容度較高的項目以上信息都是很活躍的。
• 項目主要維護者是否來著不同的公司，是否足夠活躍。

推薦幾個我認為比較符合我剛才提到的條件的項目：

• https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/7195
• https://github.com/apache/pulsar-client-go/issues?q=is%3Aopen+label%3Atype%2Ffeature+sort%3Aupdated-desc
• https://github.com/apache/hertzbeat/

??如何快速上手一個開源項目

如果找到了自己想貢獻的項目，如果自己還不太熟悉的話，那就可以嘗試以下步驟來快速上手它。

?單元測試

首先第一個就是單元測試，單元測試是一個非常不錯的方式來上手一個新的開源項目，但重點不是去看現(xiàn)有的單測，而是自己去寫??。

寫過單元測試的小伙伴就知道，如果要達到 90% 以上的覆蓋率時需要對自己寫的每一行代碼都得了解，甚至在寫的過程中會發(fā)現(xiàn)部分代碼是不是沒有必要，從而再幫助自己梳理一遍業(yè)務。

所以寫單測確實是快速熟悉某個項目的方法，但這針對于一些邏輯簡單的項目；對于一些業(yè)務復雜的項目建議還是快速跑通官方推薦一個功能。

??以 Pulsar 為例

以 Apache Pulsar為例，那就先跑一個消息的生產者和消費者 demo；跑通了之后再嘗試看看它客戶端已有的單測代碼，然后嘗試改一些斷言，此時就會發(fā)現(xiàn)預期值為什么會這么定義。https://github.com/apache/pulsar/blob/631b13ad23d7e48c6e82d38f97c23d129062cb7c/pulsar-broker/src/test/java/org/apache/pulsar/client/impl/BrokerClientIntegrationTest.java#L1077

比如這里的一個 consumer 取消訂閱兩次時候就會拋出異常，此時我們就可以根據(jù)異常的地方找到源碼里對連接狀態(tài)的判斷條件。

就可以得知：當客戶端取消訂閱時會修改連接狀態(tài)。

??HertzBeat

下面以 Apache HertzBeat為例來看看當時我是如何貢獻單元測試的。

通過官方的架構圖可以得知 HertzBeat 是通過一個 collector 去直連目標采集數(shù)據(jù)的。

比如通過 Redis 的客戶端去獲取監(jiān)控數(shù)據(jù)，然后再存放到自己的時序數(shù)據(jù)庫中進行展示。

所以這個采集的過程就是比較核心的邏輯，我們可以看看他的接口定義。

一共就三個接口，分別是：

• collect采集接口：在 Metrics 中定義了采集的目標信息（地址、端口等）
• 采集完后的數(shù)據(jù)寫入到 Builder 供后續(xù)的寫入存儲
• preCheck：提前做一些參數(shù)校驗
• supportProtocol：返回定義的協(xié)議類型，通過這個類型找到對應采集器

然后就交由不同的實現(xiàn)類去采集不同的指標。

這里我以 RedisCommonCollectImpl為例，主要的單測邏輯就是模擬 Redis 客戶端的返回數(shù)據(jù)，然后在 Collect 的代碼里查看不同的處理邏輯，其實就是要覆蓋各種分支以及異常的情況。

最后再斷言采集到的數(shù)據(jù)與預期是否匹配即可，貼一段核心邏輯：

至于應該返回什么預期結果，有些 collector 可能會在代碼注釋里寫清楚，但這個 Redis 沒有寫。

不過也有辦法，我們可以把代碼在本地跑起來之后進入管理臺查看內置的監(jiān)控模版。

這里是用于定義會監(jiān)控哪些字段的地方，這樣我們就可以在代碼預先生成好預期返回值了。

具體的單測代碼請看這里：https://github.com/apache/hertzbeat/blob/master/collector/src/test/java/org/apache/hertzbeat/collector/collect/redis/RedisClusterCollectImplTest.java#L46

??總結

參與一個成熟社區(qū)的開源有一點一定要記住，就是要仔細閱讀貢獻者文檔。

里面往往會寫清楚如何構建代碼、代碼規(guī)范、提交規(guī)范等信息，這些都捋清楚后提交的 PR 才更容易被社區(qū)接受。

后面會繼續(xù)更新集成測試與 e2e 測試等內容。

本文節(jié)選自我的知識星球：