讀代碼這事，先要分是精讀還是泛讀。
從學習的目的來看，一定要精讀一定量的經典代碼。而精讀是指每行都讀懂，不看代碼腦子里就能勾畫出程序的基本結構。
這里有個很形象的狀態，精讀代碼時會滿腦子都是代碼，放不下，甚至睡覺前腦子里也是代碼。
但這一篇里主要不是關注如何精讀代碼的，而是關於如何在工作中掌握既有代碼的，等價於泛讀。
現存的很多系統往往很大，幾十萬行的可能也只算普通。
這時候一旦加入了這樣一個項目，那么如何去讀代碼？
下面說點個人體會。
讀這類代碼前，先得把規格大致弄清楚，而不能上來就讀，比如：對於應用型程序，你要先大致整清楚它的使用方法。
如果其中有涉及到領域知識，比如：流程、財會等，那也最好預先有些認識。這類東西從代碼里反推回來是不太可能的。
我個人感覺這對讀程序是個很大的障礙，你不知道編碼規則，卻去讀編碼的程序，總是會雲里霧里，這時候反倒不是因為程序難，
而是因為不知道程序中所包含的專業知識。
在這一步里，最好能抽取出來幾個典型的應用場景，這在后面有用。
一旦開始接觸代碼，那要先弄清楚代碼的基本靜態結構。如：包構成、類構成等。
這里涉及一個層次問題。一下子把層次探的太深，就容易盯在細節上出不來。
有設計文檔的項目，大致上可以通過包來界定這個層次。
沒設計文檔的就可怕了，只能靠自己划分，最好不要超過10個，超過了真記不住。
在靜態結構這步，要弄清楚每個部分的核心職責，可以簡單，最好能記住。
接下來就要用到上面的典型場景了。
要在典型場景下考察上面的靜態結構是如何發揮作用的。
典型場景下用到的接口往往就是關鍵的接口，要整清楚，他們的定義和作用。
也要整清楚，典型場景下數據流的變遷。
這步驟算是弄清楚代碼的時序。很像UML里的Sequence圖。
但牽涉到數據的時候，一般需要對數據的規格有所了解。
接下來要關注進程、線程的結構。比如：都是什么時候開始、什么時候結束的，在上述典型場景下都負責干什么。
上述四步（規格、靜態結構、典型場景、進程線程）完成后，對程序的第一次泛讀完成。
檢驗標准很簡單，這時應該能夠單靠紙筆描述出程序典型場景的Sequence圖。
干這事兒的時候，要抑制自己的求知欲，因為總是很想在調試器里通過call stack把一個功能的實現細節整清楚，
但至少在第一個層次里，可以先不要這樣。
第一次泛讀后，就要進入深掘的過程，針對的對象應該是自己會負責的部分。這部分功能往往會隱藏在某個接口之下。
這時候一般來講可以放過功能型的模塊，比如：XML解析的模塊等。其他部分可以認為是需要把之前所說的四個步驟再重復一下。
但這時候要關注細節和調用堆棧了。
不管是在那個讀代碼的層次，有兩個基本技巧總是需要的，一個是要掌握具體程序里內嵌的Log機制，要能看Log，必要時可能還得加Log；一個是基本調試方法。
調試很難展開，《軟件調試》一書寫了1000多頁。
但只停留在設個斷點等他停下來這個層次上還是會有點欠缺的。條件斷點、多線程調試、多進程時的調試還是要知道一點的。
程序類型太多，因此估計讀程序的方法也很多。上面只是個人的一點經驗，歡迎補充。
--------------------------------------------------------------
理想流 + 軟件 = 《完美軟件開發：方法與邏輯》
理想流 + 人生 = ??
理想流 + 管理 = ??
理想流 = 以概念和邏輯推演本質，追求真理。