以Linux內核源代碼爲例：
使用工具source insight
首先建立源代碼工程，source insight會幫助你建立一個庫
它能夠幫助我們在看一段源碼的時候，跟蹤函數、變量的定義、聲明、調用等情況
能夠識別多種文件，基本上常見的都能識別
看源碼的順序，個人以爲：
1）看源代碼的目錄結構，大致瞭解各個目錄下都有些什麼，可能是什麼，有的源代碼中
有readme或者其他文檔可以告訴我們源代碼的目錄結構
這時候有兩種不同的順序看源碼了：
第一種：
大致看一下Makefile，如果對make很熟的話，就可以知道源代碼是如何編譯的，可以知道程序的入口是什麼
這裏可能需要掌握一些gcc編譯工具相關的知識，可以在gnu.org上找到manual文檔，隨時翻閱
然後，從程序的入口開始看起，看程序初始化了一些什麼，最後是否進入一個主程序，主循環
再然後，可以分模塊看了，可以根據初始化流程中的初始化順序看各個模塊，也可以根據主程序中用到的關鍵
模塊開始看
第二種，與上面正好相反
首先看各個模塊的實現，大致瞭解之後，看這些模塊是如何被串起來運行的
基本上在看源代碼的過程中，上面的一些方法可能會重複、反覆，
從粗略到細緻，逐步細化的看比較好
如果一上來就陷到代碼細節中，會感覺比較鬱悶
還有一種，就是帶着問題看源代碼
你對源代碼的哪個部分感興趣，那就專門看那個部分
比如想看Linux中的slab算法，那麼就專門看slab.c等相關文件
這時候，要先看關鍵數據結構，如kmem_cache_s，slab_t等
圍繞數據結構看：
1）數據結構什麼時候會被實例化
2）實例化的數據結構是什麼時候，如何被初始化的，從而可以瞭解slab算法的初始化過程
3）哪些接口會對數據結構進行操作，並導致數據結構中的關鍵數據項（或者你所關心的數據項）發生變化
從而可以瞭解slab的分配和回收，或者其他你所關心的算法細節
4）如果其他模塊想使用slab，那麼應該如何使用，這就需要尋找一個使用的實例
在上述過程中，source insight的追蹤功能將會被使用的比較多
剛開始我也被閱讀代碼的問題所困擾，在公司接受一個換了4個開發團隊，沒有任何文檔的代碼。我閱讀的經驗是：
1.首先將代碼編譯，多運行幾遍目標程序，瞭解業務流程。
2.自己編輯一個數據字典，不求完全和系統一樣，以後的閱讀過程中再改進。
3.從main.cpp（類似的項目，通常有一個主文件）開始閱讀，注意全局變量，因爲很稀爛的班子開發的代碼裏，會有很多全局變量。
4.用簡單流程圖和E-R圖把代碼裏比較複雜的邏輯記錄下來。