工作七年以來，陸陸續續向社群提交了一些原始碼貢獻，即Pull Request，簡稱PR。對於一個熱愛技術的開發人員來說，能讀懂被業界廣泛使用的開源框架裡的程式碼，甚至回饋社群，將是一件莫大的榮耀。下面簡單聊聊這件大事，可能限於知識水平有些不足或片面的地方，希望多多理解。
一、我目前的社群貢獻
以下列出的內容都滿足如下條件：被社群merge；在業界足夠知名
1、Presto
（1）14007
使kudu connector支援kerberos認證，且在續期有效期過了後能自動獲取新票據
（2）14422
刪除聯結器時新增清理PlanOptimizerProvider，修復核心模組的bug，為以後新增動態載入聯結器功能打下了基礎
2、Flink
（1）12442、12789
官方文件的flink事件時間章節
（2）12748
官方文件的資料型別章節
（3）12794
官方文件的使用者自定義函式章節
（4）14938
Flink將資料寫進es時處理異常資料支援併發，由自己發現bug，同事提交
二、重要性
1、對公司業務
我們在大資料系統中使用的絕大部分基礎設施都是基於開源軟體的，很多開源軟體都具有版本更新快、文件不充分的特點，如果能讀懂原始碼，我們便能做到知其然更知其所以然，小到可以充分理解某配置引數的含義從而優化系統效能，大到可以修改原始碼新增、優化功能以滿足公司業務場景的需求。所謂外行看熱鬧，內行看門道，在軟體行業尤其是大資料領域，那些ppt、營銷包裝過的數字其實並沒有多大意義，反而是對開源社群的貢獻可以體現一個公司的技術價值，在立足於以技術贏得市場的行業裡，做好開源或技術文件輸出是非常重要的，有助於爭取到話語權。
2、對自身技術發展
我相信對每一個立志做技術的從業人員來說，都不想滿足於只做個sql boy或crud boy，想提升自己的技術架構水平，那怎麼辦，按大牛們常說的把《深入理解計算機系統》、《java程式設計思想》這類有名的大部頭經典讀一遍嗎？不盡然，至少對我來說不是。在我看來，程式設計技術首先是一門實踐型的技術，搞懂一個知識點對我的刺激遠比不上自己的程式碼解決了一個個具體的業務場景，看著自己的程式碼執行在眾多的機器向很多人提供高效安全的服務，我想這就是我作為一個技術人的浪漫，在其中我能感受到高層次的多巴胺，那是一種強烈而持久的快樂。而想得到這種快樂，最好的辦法就是向業界某些關鍵領域如流計算、OLAP裡最流行的開源社群輸出自己的貢獻，當然即使發現社群已經足夠完善難以進行貢獻，閱讀這些開源社群的程式碼本身就像攀登高山一樣，不斷地磨礪自己的心智，提升自己的技術水平。
三、方法
1、把握技術架構和關鍵特性，熟悉擴充套件機制
技術架構和關鍵特性是我們閱讀原始碼時要遵循的基本思路，比如得知一個開源框架是Master/Worker架構，在看系統載入執行的原始碼時要有目的地去看Master、Worker相關的程式碼。
官方文件一般會講解有關擴充套件開發相關的內容，這部分內容要重點去看，比如Presto官方提供了SPI文件，有一些介紹和示例，可以幫助我們快速掌握擴充套件方法
2、切忌追求完全看懂，多用跳躍式思維
當然這個跳躍式思維不是說看不懂了就跳過，而是看懂基本的意思即可，或者合理腦補出晦澀難懂的部分，然後跳到下一部分
每個開發人員的思維習慣、技術優勢都是不一樣的，這就導致同一種功能在不同人手上會有千差萬別的實現方式，如果我們一旦陷入這種差異而無法脫身，將會很大程度拖延進度，也可能丟了西瓜撿了芝麻走上彎路，更可能產生強烈的挫敗感以至知難而退。
更可取的方式是領會作者的意圖即可，不用過分深究實現方式，領會程式碼的編寫框架和意圖是核心，有以下方法：
- 方法、介面、變數名都一般蘊含了意圖的概要資訊
- 註釋資訊包含了大量的詳細解釋
- 若一個功能有示例實現，可以重點看這個示例，遮蔽了很多技術細節，便於理解
- 程式碼一般是由少到多、由簡單到複雜，可以看看老版本的實現
- 查這個功能相關的pull request，裡面會有作者一些開發思路和意圖
3、敢於動手，大膽驗證想法
當我們有了一個想法時，不要停留在思想層面，可能這就是一個很好的靈感，大膽在原始碼上進行修改、編譯後驗證自己的想法，若沒達到預期，這很正常，從執行日誌裡找問題原因，排錯後解決問題，或者開啟debug執行模式，看函式跳轉的邏輯和關鍵值的變化。一步步靠近想要的結果
4、分解任務，循序漸進
不要追求一蹴而就，可能最終要實現一個很複雜的功能，但可以先將這個複雜功能分解為核心功能、附加功能、優化功能
比如要實現presto kudu資料來源的kerberos認證功能，核心功能是kerberos認證，附加功能是配置kerberos連線資訊讓presto可以感知到，優化功能是可在不重啟presto的情況下感知到kerberos連線資訊的變更