學習開源專案的若干建議

　　隨著國內開源社群和專案的不斷髮展，學習、應用、貢獻開源專案的開發人員越來越多。最近，研究過多個開源專案(包括KVM/QEMU、libvirt、OpenStack、Ceph、Zabbix等)的業內專家章宇在其部落格中分享了學習開源專案的若干建議，值得讀者借鑑。

　　章宇認為，學習開源專案，可以劃分為五個層次，分別是：

1. 瞭解專案的基本概念、基本用途、邏輯結構、基本原理、產生背景、應用場景等基本知識。這個層次的基本定位其實就是“科普”。如果對於一個專案只需要有些基本瞭解，且短期內並不需要上手進行實際技術工作，則學習到這個層次也就可以先應付一下了。
2. 掌握專案的基本安裝流程和使用方法。這個層次的基本定位是“入門”，以便對這個專案獲得直觀認識，對其安裝和使用獲得親身體驗。如果只是需要以as-is方式使用這個專案，則初步學習到這個層次即可。
3. 瞭解程式碼的組織，找到各個主要邏輯/功能模組與程式碼檔案之間的對應關係，通過程式碼分析走通幾個關鍵的、有代表性的執行流程。這個層次的基本定位是“深入”，開始理解這個專案的實際實現，能夠真正將專案的功能、工作原理和程式碼實現對應起來，獲得對這個專案工作過程的直觀認識。這個層次是學習開源專案程式碼的真正開始。如果希望基於這一專案進行應用開發，或者針對與這一專案密切相關的其他專案進行工作時，則對專案本身的程式碼進行這一層次的理解，會很有幫助。
4. 瞭解該專案所有程式碼模組、程式檔案的作用，走通所有主要執行流程。這個層次的基本定位是“掌握”，能夠比較全面、系統地理解這個專案的設計和實現，並且熟悉專案各個部分的程式碼。如果希望對專案進行深度定製修改，或者對社群有所貢獻，則應當以達到這個層次作為目標。
5. 鑽研、領悟該專案的各種設計思想與程式碼實現細節。這個層次的基本定位是“精通”，精益求精，學無止境。這是大神們追求的境界。如果希望成為專案社群的重要貢獻者乃至核心貢獻者，則應當以這個層次作為努力的目標。

　　學習開源專案，必須要掌握一些基礎知識，章宇指出了三點：

• 該專案涉及的技術領域的背景知識。舉例而言，分析Linux Kenrel，則應該瞭解作業系統原理；學習OpenStack，則應該知道什麼是雲端計算。如果沒有這些背景知識作為基礎，上來就死磕原始碼，只能是事倍功半。
• 該專案開發使用的語言及其各種開發除錯工具。
• 英語。很遺憾，目前為止真正流行的開源專案大部分不是起源於國內。因此，除了學習個別極其流行、文件完備的專案之外，大家還是需要自行蒐集閱讀英文資料參考。學好英語很重要。

　　有了學習的目標和基礎知識，接下來就是學習的思路和過程，章宇總結了一套由表及裡、逐漸深入的學習方法。

在剛開始接觸一個專案的時候，我們看到的其實就是一個黑盒子。根據文件，我們一定會發現盒子上具有若干對外介面。通常而言，這些介面可以被分為三類：

• 配置介面：用於對盒子的工作模式、基本引數、擴充套件外掛等等重要特性進行配置。這些配置往往是在盒子啟動前一次性配好。在盒子的工作過程中，這些配置或者不變，或者只在少數的情況下發生改變。
• 控制介面：用於在盒子的工作過程中，對於一些重要的行為進行操縱。這是盒子的管理員對盒子進行控制命令注入和狀態資訊讀取的通路。
• 資料介面：用於盒子在工作過程中讀取外部資料，並在內部處理完成後向外輸出資料。這是盒子的使用者真正關心的資料通路。

因此，在分析一個開源專案的程式碼時，可以圍繞重要的配置、控制、資料介面展開分析工作，特別應該注意理解一個關鍵的介面背後隱藏的操作流程。例如，針對資料介面，至少應當走通一條完整的資料輸入輸出流程，也即在程式碼中找到資料從輸入介面進入盒子後，經過各種處理、轉發步驟，最終從輸出介面被傳輸出去的整個執行過程。一旦走通了這樣一條流程，則可以將與資料處理相關的各個主要模組、主要步驟貫穿起來，並將邏輯模組圖上和文件中的抽象概念對應到程式碼實現之中，可以有效推進對於專案的深入理解。

在實踐這一思路的過程中，筆者建議可以優先從控制介面和資料介面中各自選擇一二重要者進行背後的執行流程詳細分析，力爭找到其中每一步的函式呼叫及資料傳遞關係（對於一些系統、應用庫提供的底層函式可以先行跳過以節省時間）。這一工作完成之後，則第三層次的學習目標即可初步達成。

配置介面在不同的專案中的重要程度不同。對於一些架構極為靈活、配置空間甚大的專案（如OpenStack的Ceilometer），則可以適當多花些時間加以研究，否則簡單瞭解即可。

　　作者以“OpenStack Cinder”為例，講述瞭如何學習開源專案：

1. 首先，想對Cinder進行分析，一定要了解若干相關的基礎知識。什麼是雲端計算？什麼是塊儲存？什麼是OpenStack？Cinder在OpenStack裡的作用？等等等等。如果對這些東西沒有概念，則後續學習是很難開展下去的。
2. 在此基礎上，如果有條件，則最好能夠親自部署和實際操作一下Cinder（包括必要的其他OpenStack元件），以便對Cinder獲得一個直觀的認識和體驗，為後續分析提供一些參考。此處假定Cinder使用的後端是Ceph，而OpenStack上執行的虛擬機器是KVM。
3. 然後，應該從概念上對我們要分析的系統的邏輯框架有個理解。從總體的範疇上講，應該瞭解Horizon和Nova各自的邏輯模組結構，以及它們和Cinder的協同工作方式、關係。這部分與Cinder的控制介面及執行路徑分析密切相關。此外，還應該瞭解Cinder和KVM/QEMU、Ceph之間的相互關係。這對於真正理解Cinder很有幫助。從Cinder自身而言，應該瞭解其內部邏輯模組構成、各自的功能、相互間的控制、資料連線關係等。
4. 在完成上述準備之後，則可以開始對Cinder的程式碼進行分析了。如前所述，應該考慮在控制介面和資料介面中各自選擇一兩個關鍵的、有代表性的加以分析。至於配置介面，假定其實現了某一配置即可，暫時不需要過多花費時間。Cinder的核心功能其實是OpenStack上的volume管理。至少在Cinder+Ceph方案中，Cinder自身並不在資料傳輸關鍵路徑上。因此，控制介面的分析就是Cinder原始碼分析的重中之重。就入手階段而言，則有兩個介面及其對應執行流程可以作為Cinder分析的起點，即volume的create和attach操作。如果能夠徹底打通這兩個操作的執行流程（至少要看到Cinder與Ceph通過librbd互動的層面），則對於真正理解Cinder的功能與實現大有幫助。雖然基於KVM的虛擬機器在通過QEMU訪問Cinder建立的、Ceph提供的volume時並不通過Cinder，也即，這一部分的原始碼其實已經超出了Cinder原始碼學習的範疇，但是，如果希望真正徹底地理解Cinder，則對於這一部分知識還是應該有所涉獵，至少應該有概念上的瞭解。