如何找到並快速上手一個開源專案

以前有寫過兩篇文章來簡單聊過如何做開源的事情，最近我自己組了一個社群裡面也有不少朋友對開源感興趣，於是我便根據自己的經驗系統的梳理了一些關於開源的事情。

• 新手如何快速參與開源專案
• 手把手教你為開源專案貢獻程式碼

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

🔎如何找到自己感興趣的開源專案

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

• 參考社群大佬的程式碼，提升技術
• 豐富個人履歷，提高面試透過率
  • 更功利一點就是想成為某個專案的 Committer/PMC
• 單純喜歡分享，熱愛開源，認可開源改變世界💪。

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

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

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

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

因為開源社群大部分都是執行非同步溝通，與即時通訊的快速反饋不同，甚至還有不少 reviewer 處於不同的時區。

所以一開始就想做好心理預期，不要指望著我給某個專案提交一個很牛逼的功能，然後他們快速 review 合併，然後給你 commit 許可權。

而且有不少開源專案是由某一個公司主導的，比如（Pulsar、Golang、Kafka），他們可能對於外部社群來的新手並不那麼上心，一個 PR 晾在那裡幾個月沒人理都是很正常的。

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

• 儘量是自己日常在用，熟悉的專案。
• 最近有在及時更新維護的專案。
• 對社群新人的接納程度是否足夠包容。
  • 這點可以在 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/

🖐如何快速上手一個開源專案

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

✅單元測試

首先第一個就是單元測試，單元測試是一個非常不錯的方式來上手一個新的開源專案，但重點不是去看現有的單測，而是自己去寫✍️。

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

所以寫單測確實是快速熟悉某個專案的方法，但這針對於一些邏輯簡單的專案；對於一些業務複雜的專案建議還是快速跑通官方推薦一個功能。

🌟以 Pulsar 為例

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

比如這裡的一個 consumer 取消訂閱兩次時候就會丟擲異常，此時我們就可以根據異常的地方找到原始碼裡對連線狀態的判斷條件。

就可以得知：當客戶端取消訂閱時會修改連線狀態。

💓HertzBeat

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

透過官方的架構圖可以得知 HertzBeat 是透過一個 collector 去直連目標採集資料的。

比如透過 Redis 的客戶端去獲取監控資料，然後再存放到自己的時序資料庫中進行展示。

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

一共就三個介面，分別是：

• collect採集介面：在 Metrics 中定義了採集的目標資訊（地址、埠等）
  • 採集完後的資料寫入到 Builder 供後續的寫入儲存
• preCheck：提前做一些引數校驗
• supportProtocol：返回定義的協議型別，透過這個型別找到對應採集器

然後就交由不同的實現類去採集不同的指標。

這裡我以 RedisCommonCollectImpl為例，主要的單測邏輯就是模擬 Redis 客戶端的返回資料，然後在 Collect 的程式碼裡檢視不同的處理邏輯，其實就是要覆蓋各種分支以及異常的情況。

最後再斷言採集到的資料與預期是否匹配即可，貼一段核心邏輯：

至於應該返回什麼預期結果，有些 collector 可能會在程式碼註釋裡寫清楚，但這個 Redis 沒有寫。

不過也有辦法，我們可以把程式碼在本地跑起來之後進入管理臺檢視內建的監控模版。

這裡是用於定義會監控哪些欄位的地方，這樣我們就可以在程式碼預先生成好預期返回值了。

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

📝總結

參與一個成熟社群的開源有一點一定要記住，就是要仔細閱讀貢獻者文件。

裡面往往會寫清楚如何構建程式碼、程式碼規範、提交規範等資訊，這些都捋清楚後提交的 PR 才更容易被社群接受。

後面會繼續更新整合測試與 e2e 測試等內容。