如何找到并快速上手一個開源項目
如何找到自己感興趣的開源項目
首先第一步先想清楚自己搞開源的目的是什么：
- 參考社區大佬的代碼，提升技術
- 豐富個人履歷，提高面試通過率
更功利一點就是想成為某個項目的 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 測試等內容。
