成為hbase社群國内第20個committer

為什麼寫這篇文章

過去2、3年無意間看到過幾篇關于成為committer的文章，有的找不到了，還能找到的我放在了文章末尾(在此表示感謝)，這些文章對于我了解社群、訂立成為committer的目标以及最終實作，有很大的幫助，是以我也打算寫點東西，希望能夠薪火相傳，給其他人以鼓勵；

hbase社群概況

contributor目前是300個左右，committer是90個左右，一年前的這個時候要更少一些，當時我和團隊的小夥伴都很是意外，比我們預期的數字少了好幾倍，原因是hbase很早就是知名項目了，在國内有很廣泛的應用，難以相信就是這麼點人在開發維護，而且裡面有很多人實際上早就不活躍了；

comitter數量按時區來看的話，其它：印度(+5)：中國(+8)：美國(-8)大概是1：1：2：4，與各國的軟體實力基本一緻，從中多少也印證了歐洲的IT産業相對于其經濟政治地位來說，是有一些低迷的；

大概過程

2019年2月份送出了第一個patch，和大多數committer一樣，是從對文檔的修改開始，雖然改動比較簡單，但是意義不小，它一定程度上消除了我對開源社群貢獻的神秘感，從此有一個issue的編号與自己的id關聯在了一起；

2019年8月份送出了一個較大的patch，總共200多行，是根據線上實際碰到的問題，對bucketcache進行的優化，曆時一個多月，送出了優化前後的性能測試和分析文檔，以及實際生産環境中的運作度量資料，這個issue最後的成功合入，極大的增強了信心，自此便堅信成為committer隻是時間問題；

随着對hbase的功能特性和原理源碼越來越熟悉，發現問題的頻率和解決問題的效率都有了不小的提高，2020年3月到9月這半年密集送出了大量patch，也順利在9月中旬收到社群邀請成為committer；

參與社群的好處

深入掌握技術元件

這些年随着大資料技術生态蓬勃發展，很多公司的架構圖都越來越像蜘蛛網，這其中，有一些是因為要應對各種各樣的業務場景，不得已而為之，也有一些實際上隻是對技術元件本身還不夠熟悉，不能充分發揮其作用，碰到新問題就傾向于引入新技術，但技術棧越是複雜，維護成本就越高，就越是沒有時間精力去深入，進而陷入惡性循環；

我所在的團隊自去年起就有了這方面的一些反思，平常在使用的技術元件衆多，列出來會有挺長一排，但多數都不夠深入，一旦出問題往往不能夠快速定位和解決，有不少時候就隻好祭出重新開機、重導資料甚至重新安裝等這些終極手段，相信不少團隊也跟我們差不多；

是以，精簡技術棧并各自選擇方向進行深入研究成為團隊共識，也正是在這個大背景下，個人才有機會能夠專注于hbase這項技術；

得到的好處很明顯，一方面對hbase的持續優化大幅度降低了tp999的延遲，原本服務層和hbase之間有一層redis用來加速，目前已經簡化掉，另一方面碰到問題可以追根溯源，上文提到的bucketcache的那個問題，會造成regionserver每次老年代gc時出現長停頓，如果熟悉源碼或社群，就可以通過自行修改或者引入社群更新檔來進行修複，而前段時間有一位找我咨詢問題的同學所在的公司，便疑似因為這個問題，而使用了jdk13，嘗試用新的zgc來避免停頓，非穩定的特性加上非廣泛使用的版本，很可能又會帶來新的問題；

提高規範性

社群對代碼的品質要求很高，除了基本的命名、格式這些之外，一個很重要的特點就是必須要有單元測試，這個根據情況，有時是新增用例，有時是修改現有用例，hbase的代碼量據說有80多萬行，個人目測單元測試代碼跟主目錄代碼至少有1比1，這些測試用例很大程度上保證了一個複雜的分布式系統能夠持續進行疊代更新，另外，如果patch涉及到性能影響，還需要有充分的性能測試結果；

對于單元測試，我在這麼多年的工作過程中，越來越能感受到它的重要性，一方面便于疊代之後進行回歸測試，另一方面也便于團隊其它人員通過了解測試點并調試來了解子產品核心邏輯，但就我了解，大部分團隊并沒有寫單元測試用例的習慣，很多人也是以根本不知道如何去寫，而通過參與社群可以對這方面有很大提升，無論是技能還是認知；

還有就是代碼review，在社群裡面，即使是committer，也不能直接commit，必須至少獲得另外一個committer的贊同，并且沒人反對，review的過程是異步的，雖然顯得節奏有點慢，但是可以確定reviewer能夠充分的了解patch的内容，這一點至關重要，有不少團隊做review是定好時間找會議室一起看代碼，這種方式的問題是每個人的工作進度不同，難以保證都能夠在會議前充分閱讀過别人的代碼，臨時去看的話其實很難提出有價值的問題，這種情況次數多了，大家就會認為投入這個時間的意義不大，是以放棄review這個過程；

代碼review這裡稍微發散一下，個人覺得裡面的核心問題有2個，1是動力問題，與coding相比，review經常不被當做一個有價值的工作任務，是以缺少動力，2是方式問題，上述提到過，需要異步進行，團隊工作跟系統運作一樣，異步帶來高效；

據說有一些大廠已經在推行類似社群的開發模式，控制commit的權限，來提高代碼品質和相關過程的規範性，這無疑是很有意義的嘗試；

豐富相關技術的使用經驗

開源項目的複雜度往往高于公司裡的各種系統，其參與者也大多經驗豐富，是以對于一些常用的工具，比如git、maven、jenkins等這些，即使你平時也有在用，但也一定會從中學到不少新的東西，而這些東西對于内部應用系統的開發也帶來幫助；

成就感

借助于開源項目，自己寫出的代碼能夠運作在成千上萬的裝置上，還是很有成就感的；

如何成為committer

首先是源碼的學習，我的方法主要是畫圖和寫文章，過去一年多，在processon上面畫了至少幾十張圖，包含類圖、流程圖、序列圖等，整理的文章也有十多篇，另外就是訂閱郵件清單，閱讀郵件以及裡面涉及到的issue，逐漸試着去看懂裡面談論的内容；

然後是勇敢嘗試，從文檔或注釋開始嘗試送出issue，第一步非常重要；

最後就是堅持，需要記住一點，社群貢獻是隻會加分不會減分的一個過程，隻要能夠持續，到達目标是遲早的事情；

• 一程式員在阿裡HBase團隊的所感所悟( http://www.woshipm.com/it/38942.html)
• 成為HBase Committer後( https://zhuanlan.zhihu.com/p/24001780)
• 如何從小白成長為 Apache Committer( https://ververica.cn/developers/how-to-be-committer/)
• 開源項目沒有那麼遙遠( http://servicecomb.apache.org/cn/docs/opensource-project-is-not-so-far-away/)