原地址：http://blog.csdn.net/jysg9/article/details/24193181
在軟件研發過程中，我們經常碰到如下情況：許多學習開發的同學或在職的程序員都經常爲拿到一個大型程序後，在短時間內無法快速讀懂它而煩勞。當他們拿到一個大型程序後，他們便開始一句一句的閱讀分析，夜以繼日，就差懸樑刺股了，可結果依然不理想，往往進入以下狀態：
（1）花費了很長時間，也沒有多大進展，與當時預計的日期相差甚遠。
（2）由於週期較長，他們往往在重複閱讀分析最初的極小部分。就像有的童鞋讀書一樣，幾個月前讀的是前兩章，幾個月後還是那兩章，原地踏步踏。
（3）他們沒法弄清楚程序的結構，就像在雲裏露裏行走，看不清前方的路，後面已經走過的路也是迷惘模糊。
他們很痛苦，爲什麼會這樣呢？久而久之便形成膽怯心理，當接手一個新功能新程序後，在士氣上已經丟了幾會，漸漸地丟了那股初出茅廬時的勇氣。
（4）當拿到他人的程序後，都是想改的衝動，把它修改成自已風格的，即使還沒有搞明白它們，依然在改。
這樣的狀態對他們有深的影響：其一，任務不能如期完成，導致成本一再飆升。其二，不便於他們能力的提升，因爲要能力提供往往需要去更多的研究他們實現的系統或優秀的開源代碼。
下面說說如下快速讀懂一個大型程序，談一談鄙人的見解：
（1）先建好環境，讓程序能運行，玩一遍
當你拿到一個程序後，即使你不看代碼，你也應該知道它是幹什麼的吧！若它是幹什麼的都不知道，建議你不用看。因爲程序中肯定有些功能邏輯的實現，幹什麼都不知道，則肯定沒法看,放棄吧！
若你知道這個程序的大概功能。那麼你先不用看代碼，先把環境建立起來，想辦法讓程序運行一遍。在一般情況下，要做到這一點不難吧！
爲什麼我推薦將程序運行一遍呢？因爲建立好的運行環境，一方面可以初步驗證一下此程序的功能，以及正確性完整性，另一方面方面接下來的分析調試，通過加日誌斷點就可能了；同時面對這個大型程序，程序運行通了，能沒有成熟感嗎？能不愉悅嗎？
（2）看想辦法掌握程序的結構
對於開源項目，通過作者微博、Google、百度、PDSN、等找到程序的體系結構，通常情況下是能找到些資料的。即使情況差一點，也能找到星星點點，而這些星星點點對你的研究往往有很大的幫助。
若是公司內部的項目，則一般都有完整的文檔。不要捨棄文檔而便開始reading。我們看見許我程序員往往有這樣的通病：當他們拿到一個程序員，便迫不急待的找main/WinMain，接下來如坐禪般一坐幾個小時。
（3）先體系再細節；先平面再線點。
不要一開始便逐字逐句的看，這種方法是最低效的方法。這些童鞋想必在經前的做事過程中，往往是先了解各個點，再將點串也線，線串也面。他們直到最後纔看清楚程序的面目，可能經過幾個月才豁然開朗。整個過程如地獄般煎熬。
而有推薦的方法是：先整體再局部，先平面再線點。這樣不解更高效，而且輕鬆啊。
這也是爲什麼總有那麼幾個天才程序員很空閒的原因之一。
這裏要說的是"大膽猜測，小心求證"。在閱讀程序的過程中，我們往往對某一處或幾處邏輯不肯定，可能是這樣，也可能是那樣。在這個岔路口，這時許多小夥伴們往往不知道如何選擇了，停滯不前。其實這個時候不需要停留，大膽猜測，大膽往前走。走通了則證實你的猜測正確性。走不通則返回走另外一條路就可以了。
（4）斷點調試、日誌調試。
因爲在最初我們已經將環境建立好了，那麼當遇到一些難於理解的問題啊，結合斷點調試便迎刃而解了。看見許多小夥伴經常在QQ問這問那，一些再簡單不過的問題，break一下,
demo一下，答案便出來了。
即然想做有前途的程序員，爲什麼不多動動你聰明的大腦，不多動動你高貴的雙手呢。
（5）忽略細節，先前不要關注分支（支線）。
這一點很重要啊。許多小夥伴一開始就有不求甚解的精神（叫"潔癖"或更爲恰當）。
他們的做法是從Main開始一字一句的解讀，遇到一個問題，直到他認爲這個問題已經處理不再是個問題的時候，才進行下一步。
這是一個做事方法問題：這樣無疑會導致整個進度的延緩。若我們一開始只關注整體結構（一個宏觀的大概的流程），而忽略掉那些細支末節，則很有利。
那些可以忽略呢？
如有些函數一看函數名便知道是幹什麼的，沒有要一開始便深入。
有些系統中的分支（如某此特殊場景下才執行的邏輯）、不重要的功能，則一掃而過。
先整體再局部，先宏觀再微觀，先流程再細節。
（6）其它
善用搜索引擎，試試切換不同的關鍵字，往往有意外的收穫。
還有許多其它方法，有時間再擴展。