為什麼要看原始碼如何看原始碼，高手高階必看

由於專案的需求，最近花了較多的時間來看開源專案的**，在本文中，簡單總結一下對為什麼要看原始碼、如何看原始碼這兩個問題的思考。

看原始碼只是一種方法、手段，而不是目的。我也曾經給自己制定過「閱讀***原始碼」的目標，現在看起來真的很蠢，一點不smart（specific、measurable、attainable、relevant、time-bound）。

只有搞清楚了閱讀**的目標，才能有的放矢，抓住重點，高效達成任務。

看原始碼的意義總結起來包含但不限於以下幾點：

只要是**，就會有bug，只是說bug的多與少、深與淺罷了。現在大家都喜歡發布、使用開源專案，不同的開源專案社群成熟度、**質量又會有較大的差異，遇到bug就不足為奇了。

我在[如何學習新技術、團隊技術選型時要注意些什麼][link 1]裡面提到過，如果我們需要將乙個開源專案用到自己的專案中，那麼就必須了解這項專案的優缺點，並深知原理，對部分細節（尤其是專案的優勢、feature）進行深入研究。

如果是成熟的開源專案，遇到問題也許能google到很多答案；但如果是乙個處於快速發展中的開源專案，多了解其架構、核心原理，也能幫助快速定位問題。

另外，有的專案文件可能不那麼豐富，但又不得不使用，那麼如何以正確的姿勢使用呢？也得參考原始碼

看原始碼也是一種不錯的學習方式（雖然不一定不是最佳的方式），尤其對於比較優秀的開源專案，能讓人大開眼界。

即使是出於學習的目的，也是有很多側重的，比如

學習語言：**風格、規範、慣用法、高階語法。對於某個語言的新手，找乙個熟悉領域的開源專案來深入掌握這門語言，也是乙個不錯的注意。

學習設計：資料介面、框架、整體架構

學習理論：演算法、協議。比如我之前寫過的[raft協議][raft]，光看**是很枯燥的，而且演算法理論到工程實踐還是有一定的差距，這個時候結合開源專案([mongodb])實現往往更事半功倍。

一般來說，我們剛開始僅僅是使用乙個開源專案，但隨著使用的深入，會發現一些自己需要的功能並沒有很好的支援，向專案組提的issues也可能得不到快速的響應，這個時候就要自己開分支，改**，加功能了。

當然，比較好的是將自己分支比較好的新feature 給原專案提merge request，反哺開源專案，比如阿里的[blink]

他山之石可以攻玉，如果有需要重新開始自己造輪子，那麼參考一些已有的、優秀的輪子肯定是有好處的。

這一點，不應該作為我們閱讀原始碼的出發點，但是確實能在實際中對找工作、面試有加成，算是副產品吧。

看原始碼的目的很大程度上影響了看原始碼的方式、需要閱讀的**的範圍。比如說，如果是為了修乙個線上bug，那麼閱讀**的範圍就緊緊圍繞bug本身；而如果是為了了解某個分布式演算法，那就需要按大量的、可能執行在不同節點（程序）上的**，了解其互動原理、工作流程。

下面說一些通用的方法。

一般來說，文件是對**的高度凝練，乙個高質量的開源一般會包含tutorial、specification、api reference等documents，通過選擇性的略讀、精讀這些文件，就能大致了解專案的整體架構、設計原則

正確的路線是通過文件去認識這個專案，然乎通過閱讀**去驗證文件、深入細節，而不是通過直接啃原始碼來了解這個專案，以偏概全。

當需要看**的時候，不要找到乙個檔案就開始，先看看**組織，粗略看看檔名、類名，基本就能猜測到每一部分。比如redis的原始碼就組織得很好，基本上看檔名就可以快速定位每乙個command的實現位置。

看原始碼的目標決定了此時此刻的關注點，不管是解決遇到的bug還是學習某個演算法，都讓我們聚焦到乙個具體的問題，從這個具體的問題去追蹤**，忽略掉當前無需關注的細枝末節，步步深入，直達目標。

當然在解決乙個問題的時候，有可能會引發新的問題，尤其是學習的時候，此時只需記錄新問題（放到收集籃，不要立即發散），待之前追蹤的問題解決之後，再來看新發現的問題。

如果自己沒有問題，那麼就幫忙解決別人的問題，通常來說，開源專案都有許多待解決的issue，從中選擇乙個入手即可。

只要可以，一定先讓**編譯通過、跑起來，這樣不管是加log、列印呼叫棧還是斷點除錯都方便很多。尤其是對於像python這種動態型別**，不跑起來很難知道到底在幹啥。

如果某份源**的閱讀並不是一錘子買賣，日後還可能回顧、重新閱讀，那麼就一定要做好**注釋和筆記。筆記主要是框架圖、類圖、流程圖，目標是建立索引，方便日後快速回憶。

而注釋就是閱讀**時的細節，重新閱讀的時候看注釋（特別是函式的注釋）能節省很多時間。

為什麼要看原始碼 如何看原始碼，高手高階必看