如何閱讀程序源代碼？

01-03

方法？工具？技巧？

閱讀源代碼的第一個工具，就是你手中的code base。把它編譯出來，運行它，加log，試著修改一些數據和代碼，看看有什麼變化。

第二個重要的工具就是debugger，而debugger最重要的功能是獲取call stack。在你感興趣的use case里pause一下，在你不知道有什麼用的函數里加個斷點，顯示出來的call stack都能讓你對系統有更清晰的認識。

一個軟體系統就是一個小宇宙。別期待有什麼高明的文檔。要把自己當成探求自然真理的物理學家。

必須找好切入點。你要解決什麼問題。是要fix bug；還是要把這個系統和其它模塊集成；還是要增加新功能。物理學家沒有上來就研究整個宇宙的，必須選好分支。
如果你有一個猜想，但是又和你的目標關聯不太大，那就堅持這個猜想，直到出現明顯反例。物理學有很多這樣的例子，和數學不同，為了旁支猜想投入過多研究是不明智的。
如果有明顯證據證明你的某個旁支猜想大錯特錯，你就要放棄主要目標，暫時把解決旁支猜想作為主要目標。比如，你本來以為某個結構是LRU的cache，結果發現怎麼做都不對，那就先放棄原來的目標，專門研究這個結構的用途。
對於旁支猜想的不斷切換，要做好自己的task stack保留。在旁支猜想解決之後，要根據結論儘快回到上次中斷的任務。

複雜的軟體系統更像一個動物，待久了你會了解它的脾性。有些是通過邏輯，有些是通過感覺。玩車的尚且有這種感覺，我們玩的東西比車複雜上萬倍，就更不能對它缺乏感情投入。（這也是我不愛做企業開發的原因，我不愛養個爬行類當寵物，還是貓貓狗狗的親切。）

在cnblog上看到一篇日誌《如何看懂源代碼--(分析源代碼方法)》

主要分六個部分

（ 1 ）讀懂程式碼，使心法皆為我所用。

（a）讀懂別人寫的程式碼，讓你收穫滿滿

（b）先了解系統架構與行為模式，再細讀

（c）熟悉溝通語言與慣例用語

（d）掌握程式碼撰寫者的心態與習慣

（ 2 ）摸清架構，便可輕鬆掌握全貌。

（a）閱讀程式碼的目的，在於了解全貌而非細節

（b）由上而下釐清架構後，便可輕易理解組成關係

（c）了解架構，必須要加上層次感

（d）探索架構的第一件事：找出系統如何初始化

（ 3 ）優質工具在手，讀懂程式非難事。

（a）善用文字編輯器或IDE中，加速解讀程式碼

（b）grep按（讀者：推薦來源透視）是一個基本而極為有用的工具

（c）gtags可建立索引，讓搜尋更有效率

（d）再搭配htags製作的HTML文件，更是如虎添翼

（ 4 ）望文生義，進而推敲組件的作用。

（a）好的說明文件難求，拼湊故事的能力很重要

（b）探索架構的第一步─ ─找到程式的入口

（c）系統多會採用相同的架構處理插件程式

（d）隨著實務經驗，歸納常見的架構模式

（e）善用名稱可加速了解

（ 5 ）找到程式入口，再由上而下抽絲剝繭。

（a）展開的同時，隨手記錄樹狀結構

（b）無法望文生義的函式，先試著預看一層

（c）根據需要了解的粒度，決定展開的層數

（ 6 ）閱讀的樂趣，透過程式碼認識作者。

（a）閱讀程式碼是新時代程式人必備的重要技能

（b）好的名稱能夠摘要性地點出實體的作用

（c）轉換立場，理解作者的思考方式

（d）從程式碼著手認識作者獨有的風格，進而見賢思齊

如果你方便調試的話，最好就是在調試過程中進行閱讀。在你想要重點閱讀的地方加上斷點，然後進行調試。在調試過程中可以清晰看到調用過程以及變數的變化。不過你最好應該先對整個程序有一個大體了解，不然看到調用棧（call stack）里一堆不熟悉的方法或者函數，也夠頭大的。

如果不方便調試，比如linux內核，你可以使用一些源代碼閱讀工具。比較有名的是source insight，或者Understand for c++,它們共同的特點是通過為函數啊變數啊建立符號存檔來快速定位瀏覽，並且支持顯示某一個函數的調用過程。總之source insight真的是一個很強大的軟體，你可以試用一下。

不過不管哪種方式，先看一下程序的總體說明，源碼的組織結構等都是很有用的事情。

希望會對你有幫助

1.先搞清程序的流程和整體框架。模糊的地方可以嘗試進行修改看效果，有debug工具的話最好。

2.定位。找到需要了解的具體功能實現模塊。工具方法也可如上。

3.分析。對需要的具體的代碼進行詳細分析。搞清變數的意義和關聯關係，搞清實現的邏輯和演算法。好的代碼，此處最需要注釋。

平時都是用到了去找一個類似的程序，然後把裡面的部分代碼直接抄下來改一改。今天心血來潮，放棄了自習，在宿舍對著電腦看一份源代碼。

這是我在網上下載的一個用Qt寫的遊戲，準備好好從頭到尾研究一下。然而打開後發現...配置文件寫的有錯啊，程序不能編譯，於是自己就給改了改。OK了可以開心看代碼了吧，看著看著發現不對啊，雖然項目不大，但是幾千行的代碼沒注釋.../(ㄒoㄒ)/~~後來就想那就邊Debug邊看，然後發現我的Qt Creator一直沒成功配置過調試器.../(ㄒoㄒ)/~~那算了，硬著頭皮看吧，於是從主函數看是看，遇到自定義的類去瞄一眼.../(ㄒoㄒ)/~~可是你沒注釋就算了，變數命名簡直隨心所欲...但是我也不想再找一份代碼了，就自己改改數據然後編譯一下看看。把整個程序的整體流程看了一下，界面的代碼手動調了調，最後終於把它看完了。。。

所以看代碼最重要的是！！！找一份有文檔的代碼，沒有文檔也要找一份有注釋的代碼！！！真的！

閱讀代碼要做的第一件事情是收集所有和項目相關的資料。比如你要做一個項目的售後服務，那麼你首先要搞明白項目做什麼用的，那麼調研文檔、概要設計文檔、詳細設計文檔、測試文檔、使用手冊都是你要最先搞到手的。如果你是為了學習那麼盡量收集和你的學習有關的資料，比如你想學習linux的文件系統的代碼，那最好要找到linux的使用手冊、以及文件系統設計的方法、數據結構的說明。(這些資料在書店裡都可以找到)。

　　材料的種類分為幾種類型

　　1.基礎資料。

　　比如你閱讀turbo c2的源代碼你要有turbo c2的函數手冊，使用手冊等專業書籍，msc 6.0或者java 的話不但要有函數手冊，還要有類庫函數手冊。這些資料都是你的基礎資料。另外你要有一些關於uml的資料可以作為查詢手冊也是一個不錯的選擇

　　2.和程序相關的專業資料。

　　每一個程序都是和相關行業相關的。比如我閱讀過一個關於氣象分析方面的代碼，因為裡邊用到了一個複雜的數據轉換公式，所以不得不把自己的大學時候課本找出來來複習一下高等數學的內容。如果你想閱讀linux的文件管理的代碼，那麼找一本講解linux文件系統的書對你的幫助會很大。

　　3.相關項目的文檔資料

　　這一部分的資料分為兩種，一個相關行業的資料，比如你要閱讀一個稅務系統的代碼那麼有一些財務/稅務系統的專業資料和國家的相關的法律、法規的資料是必不可少的。此外就是關於這個項目的需求分析報告、概要設計報告、詳細設計報告，使用手冊、測試報告等，盡量多收集對你以後的代碼閱讀是很重要的

　　知識準備

　　了解基礎知識，不要上來就閱讀代碼，打好基礎可以做到事半功倍的效果

　　留備份,構造可運行的環境

　　代碼拿到手之後的第一件事情是先做備份，最好是刻在一個光碟上，在代碼閱讀的時候一點不動代碼是很困難的一件事情，特別是你要做一些修改性或增強性維護的時候。而一旦做修改就可能發生問題，到時候要恢復是經常發生的事情，如果你不能很好的使用版本控制軟體那麼先留一個備份是一個最起碼的要求了。

　　在做完備份之後最好給自己構造一個可運行的環境，當然可能會很麻煩，但可運行代碼和不可運行的代碼閱讀起來難度會差很多的。所以多用一點時間搭建一個環境是很值得的，而且我們閱讀代碼主要是為了修改其中的問題或做移植操作。不能運行的代碼除了可以學到一些技術以外，用處有限。

　　找開始的地方

　　做什麼事情都要知道從那裡開始，讀程序也不例外。在c語言里,首先要找到main()函數，然後逐層去閱讀，其他的程序無論是vb、delphi都要首先找到程序頭，否則你是很難分析清楚程序的層次關係。

　　分層次閱讀

　　在閱讀代碼的時候不要一頭就紮下去，這樣往往容易只見樹木不見森林，閱讀代碼比較好的方法有一點象二叉樹的廣度優先的遍歷。在程序主體一般會比較簡單，調用的函數會比較少，根據函數的名字以及層次關係一般可以確定每一個函數的大致用途，將你的理解作為註解寫在這些函數的邊上。當然很難一次就將全部注解都寫正確，有時候甚至可能是你猜測的結果，不過沒有關係這些註解在閱讀過程是不斷修正的，直到你全部理解了代碼為止。一般來說採用逐層閱讀的方法可以是你系統的理解保持在一個正確的方向上。避免一下子扎入到細節的問題上。在分層次閱讀的時候要注意一個問題，就是將系統的函數和開發人員編寫代碼區分開。在 c, c++，java ,delphi中都有自己的系統函數，不要去閱讀這些系統函數，除非你要學習他們的編程方法，否則只會浪費你的時間。將系統函數表示出來，註明它們的作用即可，區分系統函數和自編函數有幾個方法，一個是系統函數的編程風格一般會比較好，而自編的函數的編程風格一般比較會比較差。從變數名、行之間的縮進、注解等方面一般可以分辨出來，另外一個是象ms c6++會在你編程的時候給你生成一大堆文件出來，其中有很多文件是你用不到了，可以根據文件名來區分一下時候是系統函數，最後如果你實在確定不了，那就用開發系統的幫助系統去查一下函數名，對一下參數等來確定即可。

　　寫註解

　　　　寫註解是在閱讀代碼中最重要的一個步驟，在我們閱讀的源代碼一般來說是我們不熟悉的系統,閱讀別人的代碼一般會有幾個問題，1搞明白別人的編程思想不是一件很容易的事情，即使你知道這段程序的思路的時候也是一樣。2閱讀代碼的時候代碼量一般會比較大，如果不及時寫註解往往會造成讀明白了後邊忘了前邊的現象。3閱讀代碼的時候難免會出現理解錯誤，如果沒有及時的寫註解很難及時的發現這些錯誤。4不寫註解有時候你發生你很難確定一個函數你時候閱讀過，它的功能是什麼，經常會發生重複閱讀、理解的現象。

　　好了，說一些寫註解的基本方法：

1.猜測的去寫，剛開始閱讀一個代碼的時候，你很難一下子就確定所有的函數的功能，不妨採用採用猜測的方法去寫註解，根據函數的名字、位置寫一個大致的註解，當然一般會有錯誤，但你的註解實際是不但調整的，直到最後你理解了全部代碼。

2.按功能去寫，別把註解寫成語法說明書，千萬別看到fopen就寫打開文件，看到fread就寫讀數據，這樣的註解一點用處都沒有，而應該寫在此處開發參數配置文件(****。dat)讀出系統初始化參數。。。。。，這樣才是有用的註解。

3.在寫註解的使用另外要注意的一個問題是分清楚系統自動生成的代碼和用戶自己開發的代碼，一般來說沒有必要寫系統自動生成的代碼。象delphi的代碼，我們往往要自己編寫一些自己的代碼段，還要對一些系統自動生成的代碼段進行修改，這些代碼在閱讀過程是要寫註解的，但有一些沒有修改過的自動生成的代碼就沒有必要寫註解了。

4.在主要代碼段要寫較為詳細的註解。有一些函數或類在程序中起關鍵的作用，那麼要寫比較詳細的註解。這樣對你理解代碼有很大的幫助。

5.對你理解起來比較困難的地方要寫詳細的註解，在這些地方往往會有一些編程的技巧。不理解這些編程技巧對你以後的理解或移植會有問題。

6.寫中文註解。如果你的英文足夠的好，不用看這條了，但很多的人英文實在不怎麼樣，那就寫中文註解吧，我們寫註解是為了加快自己的理解速度。中文在大多數的時候比英文更適應中國人。與其寫一些誰也看不懂的英文註解還不如不寫。

　　重複閱讀

　　一次就可以將所有的代碼都閱讀明白的人是沒有的。至少我還沒有遇到過。反覆的去閱讀同一段代碼有助於得代碼的理解。一般來說，在第一次閱讀代碼的時候你可以跳過很多一時不明白的代碼段，只寫一些簡單的註解，在以後的重複閱讀過程用，你對代碼的理解會比上一次理解的更深刻，這樣你可以修改那些註解錯誤的地方和上一次沒有理解的對方。一般來說，對代碼閱讀3，4次基本可以理解代碼的含義和作用。

　　運行並修改代碼

　　如果你的代碼是可運行的，那麼先讓它運行起來，用單步跟蹤的方法來閱讀代碼，會提高你的代碼速度。代碼通過看中間變數了解代碼的含義,而且對以後的修改會提供很大的幫助

　　用自己的代碼代替原有代碼，看效果，但在之前要保留源代碼

　　600行的一個函數，閱讀起來很困難，編程的人不是一個好的習慣。在閱讀這個代碼的時候將代碼進行修改，變成了14個函數。每一個大約是40-50 行左右.

最近在看 Libgdx 的源代碼，說一說自己的感受吧。

其實以前就有看過 Libgdx 源代碼，但是一直沒看懂，而且眾所周知的原因，大部分資料都是英文的，國內有幾個人寫過博客，但看了之後感覺不甚理解。

-------------------------------------------------以上為背景-----------------------------------------------------------------

1. 首先你得找本入門資料，最好是中文的，這樣可以了解基本術語，知道變數的意思是啥，這樣閱讀代碼里注釋時方便快速理解。

2. 有一個好的調試工具，Libgdx 可以導入Eclipse或者Android Studio，因此我一直用Eclipse看代碼，方便快速定位方法和變數。

3. 每個源代碼里基本都有demo 和 WIKI，將demo運行起來，結合WIKI 不斷的修改裡面的方法和變數，這樣就清楚的知道每個API的作用。這絕對是幫你快速入門、了解API作用的不二法門。

4. 了解API之後自己寫簡單的demo，加速自己對框架的理解和記憶。

5.現在我們要深入源碼，根據步驟 3 進入每一個源文件，先閱讀注釋，然後看每個API實現方法。（其實要不自己寫框架，只需要理解API具體做什麼就可以了）了解框架所用的數據結構，最好再去看具體的實現步驟，這個真是太難了^^

6. 根據步驟自己寫一個教程/筆記，這個過程是一個查漏補缺的過程，也方便你加深記憶。目前我正在寫一個關於Libgdx的教程: Libgdx教程目錄

7. 最後一點，但是也是很重要的一點，必須具備一些額外相關知識：要掌握Libgdx的源碼最好知道設計模式的相關知識，了解OpenGL的知識更好了，我就因為不懂，導致走了很多彎路。

一般閱讀非自己寫的代碼都是關注某一部分代碼塊，比如某一條流程線。如果這份代碼讓你看的眼花繚亂，條件允許的話最有效地方法就是進行debug調試。一步一步的跟進調試會讓你很流暢的根據代碼的執行步驟了解代碼的邏輯。如果無法debug調試的話，我會從最淺層的代碼層入手，理清思路，先不去關注深層的邏輯或者函數，需要使用到得時候在去仔細查看。

聲明:本經驗只適用於大量大碼學習。

邊看代碼邊畫圖，當你把所有的代碼都能轉化成設計圖時，你必然對代碼足夠了解。

Java源碼初接觸 如果你進行過一年左右的開發，喜歡用eclipse的debug功能。好了，你現在就有閱讀源碼的技術基礎。我建議從JDK源碼開始讀起，這個直接和eclipse集成，不需要任何配置。

可以從JDK的工具包開始，也就是我們學的《數據結構和演算法》Java版，如List介面和ArrayList、LinkedList實現，HashMap和TreeMap等。這些數據結構里也涉及到排序等演算法，一舉兩得。面試時，考官總喜歡問ArrayList和Vector的區別，你花10分鐘讀讀源碼，估計一輩子都忘不了。

然後是core包，也就是String、StringBuffer等。如果你有一定的Java IO基礎，那麼不妨讀讀FileReader等類。我建議大家看看《Java In A Nutshell》，裡面有整個Java IO的架構圖。Java IO類庫，如果不理解其各介面和繼承關係，則閱讀始終是一頭霧水。 Java IO 包，我認為是對繼承和介面運用得最優雅的案例。如果你將來做架構師，你一定會經常和它打交道，如項目中部署和配置相關的核心類開發。

讀這些源碼時，只需要讀懂一些核心類即可，如和ArrayList類似的二三十個類，對於每一個類，也不一定要每個方法都讀懂。像String有些方法已經到虛擬機層了(native方法)，如hashCode方法。

當然，如果有興趣，可以對照看看JRockit的源碼，同一套API，兩種實現，很有意思的。如果你再想鑽的話，不妨看看針對虛擬機的那套代碼，如System ClassLoader的原理，它不在JDK包里，JDK是基於它的。JDK的源碼Zip包只有10來M，它像是有50來M，Sun公司有下載的，不過很隱秘。我曾經為自己找到、讀過它很興奮了一陣。

Java Web開發源碼 在閱讀Tomcat等源碼前，一定要有一定的積累。我的切實體會，也可以說是比較好的階梯是： 1、寫過一些Servlet和JSP代碼。注意，不是用什麼Struts，它是很難接觸到Servlet精髓的。用好Struts只是皮毛。 2、看過《Servlet和JSP核心編程》 3、看過Sun公司的Servlet規範 4、看過http協議的rfc，debug過http的數據包如果有以上基礎，我也不建議你開始讀Tomcat源碼。我建議你在閱讀Tomcat源碼前，讀過Struts源碼，Struts源碼比WebWork要簡單得多。這個框架是可以100%讀懂的，至少WebWork我沒有100%讀懂。我曾經因為讀懂了Struts源碼，自己寫過一個Web框架。

當然，在讀Struts框架前，最好看過它的MailReader等demo，非常非常不錯的。如果你做過一些Struts項目，那麼讀它時就更得心應手了。在讀Struts前，建議看看mvnforum的源碼，它部分實現了Struts的功能，雖然這個BBS做得不敢恭維。

如果你讀過Struts，再開始考慮Tomcat源碼閱讀吧。不過，我還是不建議直接讀它，先讀讀onJava網站上的系列文章《How Tomcat Works》吧，它才是Tomcat的最最簡易版。它告訴你HttpServletRequest如何在容器內部實現的，Tomcat如何通過Socket來接受外面的請求，你的Servlet代碼如何被Tomcat容器調用的(回調)。學習JSP，一定要研讀容器將JSP編譯後的Servlet源碼。為什麼我總是稱呼Tomcat為容器，而不是伺服器？這個疑問留給大家吧。

如果你一定要讀Tomcat，那麼就讀Jetty吧。至少它是嵌入式，可以直接在eclispe裡面設置斷點debug。雖然Tomcat也有嵌入式版本。

Java資料庫源碼閱讀 我建議，先讀讀Sun的JDBC規範。我想你一定寫過JDBC的代碼，那麼這時候可以開始閱讀源碼了。如果了解JDBC規範(介面)，那麼它的實現，JDBC Driver就一定要開始了解，我的建議是，讀讀mysql的jdbc驅動，因為它開源、設計優雅。在讀mysql的JDBC驅動源碼時，建議看看mysql的內幕，官方正好有本書，《Mysql Internals》，我五年前讀過一部分。比如你可以知道mysql的JDBC驅動，如何通過socket數據包(connect、query)，給這個C++開發的mysql伺服器交互的。

通過上面的閱讀，你可以知道，你的業務代碼、JDBC規範、JDBC驅動、以及資料庫，它們是如何一起協作的。如果你了解這些內幕，那麼你再學習Hibernate、iBatis等持久化框架時，就會得心應手的。

讀過JDBC驅動，那麼下一步一定要讀讀資料庫了。而正好有一個強大的資料庫是用Java開發的，Hsqldb。它是嵌入式資料庫，比如用在桌面客戶端軟體里，如Mail Client。我四年前為此寫過一篇小文，就不介紹了。

Java通訊及客戶端軟體 我強烈推薦即時通訊軟體wildfire和Spark。你可以把wildfire理解成MSN伺服器，Spark理解成MSN客戶端。它們是通過XMPP協議通訊的。我曾經在一個項目中，定製過Spark，當然也包括服務端的一些改動。所以它們的源碼我都讀過。我之所以推薦它們。是因為： 1、XMPP夠輕量級，好理解 2、學習Socket通訊實現，特別是C/S架構設計 3、模塊化設計。它們都是基於module的，你既可以了解模塊化架構，還可以了解模塊化的技術支撐：Java虛擬機的ClassLoader的應用場景。 4、Event Driven架構。雖然GUI都是Event驅動的，但Spark的設計尤其優雅

這麼說吧，讀它們的源碼，你會為做一名程序員而自豪，因為無論是他們的架構設計還是代碼,都太漂亮了。

Java企業級應用 當然了，就是Hibernate、Spring這類框架。在讀Spring源碼前，一定要先看看Rod Johnson寫的那邊《J2EE Design and Development》，它是Spring的設計思路。注意，不是中文版，中文版完全被糟蹋了。在讀Hibernate源碼前，一定要讀讀Gavin King寫的那本《Hibernate in Action》，同時，應該再讀讀Martin Fowler寫的《企業應用架構模式》，它專門談到持久化框架的設計思路。當你覺得這兩本書讀透了,再去看它們源碼吧。而且，在讀源碼前，你會發現它們用到很多第三方Jar包，二三十個，你最好把那些Jar包先一個個搞明白。

說到企業應用，一定會涉及到工作流。我當年讀過jBPM的源碼，網上有介紹jBPM內核的文章(銀狐)。我感覺它的內核也就兩千行，不要害怕。我曾經閱讀jBPM源碼的博客。當然了，讀工作流源碼，前提是一定要對其理論模型有深入的了解，以及寫過一些demo、或做過一些項目。

我上面介紹的這些，是我自己讀過的，也適合一般人閱讀。我也讀過一些非Java源碼，感覺不錯，也推薦給大家： dojo源碼 它的架構設計得很優雅，仿Java的import和extends。但實際應用起來一塌糊塗。我們當年基於這個開發了自己的框架，不過我不是主力。

Flex源碼 Flex 08年底剛剛開源後，我就用它做過一個中型項目，應該說是國內的技術先行者。當時市面沒有有深度的書，也沒有開源項目。我純粹是看Flex的Help文檔和源碼，把項目搞定的。兩三年過去了，現在覺得系統設計得蠻優雅的。

下載源代碼，建工程編譯，讀系統的概要涉及，大體了解各模塊的功能。

從單元測試入手，可以幫助你更快掌握代碼。

首先聲明，我看到源代碼都是面向對象語言的。下面是我讀源代碼的方式：

1 從這個軟體最核心的API開始，先使用UML里的類圖建立靜態結構，分析出類與類之間的關係（繼承，組合，實現，依賴，關聯等等）

2 使用UML里的活動圖，配合IDE工具分析核心業務流程，理解軟體是如何工作的。

3 從設計模式角度思考這個軟體為什麼要這麼設計

4 自己寫unit test來調試源代碼（這一步其實可以和1,2,3並行執行）

1 看最基礎的，從入口開始看，一行行，一個函數一個函數，一個文件一個文件的看

2 跑有疑問了運行一下程序，或者修改一下運行，看看結果和你預期的一致不，證明/反正你自己的想法

3 問實在不懂了就問，Google、so、論壇、group，多搜多問，還有就是看參考書。

閱讀源碼對於可直接編譯調試的代碼更改添加log 編譯運行看效果是最佳途徑

對於代碼框架前人的文檔也是不錯的參考若沒有那麼各個IDE的call tree生成功能也是很方便的.

對於邏輯冗雜的代碼代碼摺疊功能也是分析利器

中文注釋也是方便記憶回溯整合的利器便於統籌理解可惜的是公司大部分要求英文注釋

Java面向對象這種語言的話建議先看看設計模式，設計模式是套路

源代碼一般會是個大且複雜的系統，首先不要想能一口吃掉它。

最好有當次閱讀目標。為了解決/理解一個什麼問題而看源代碼（也可以在記事本上寫下問題列表）。一次一個問題，目標明確，不容易暈菜。

當次閱讀所遇到代碼的數據結構（介面/數據類），有時間的話可以理清楚。

一張大紙，一支多色筆，草圖。

理解源代碼就像是理解一幫子有性格的人，代碼沒有完美的，不要老想著為了理解而去修改既有代碼，理解是理解，重構是重構，兩碼事兒。

遇到「大」、「長」、「亂」的方法，不要煩躁，可以嘗試先找這個方法的輸入輸出，然後從輸出往前，尋找重點代碼，一步步分析。

要在項目中看源代碼，之後開始理解，分析最有效果，平時專門看源代碼我認為還是比較枯燥的，有的實際的場景，進行debug，看他的執行過程。之後就會發現，原來如此！

先找到軟體功能需求，也就是這個軟體包是幹什麼的，然後找到合適的IDE，編譯查看效果。最後就是從主函數開始一點一點往下看了唄，遇到封裝的函數語句就看進去怎麼實現的。

抽絲剝繭