本文所述的思想大都是網上各大家總結出來，僅供參考，我覺得這因人而異，如果作為一手來說，不妨借鑑以下方法：
看法一：

作者：網事如風

連結：http://www.zhihu.com/question/23503544/answer/24852187
來源：知乎
1.先搞明白這個專案做什麼用的，都有哪些功能。可能有的人覺得這是廢話，不過有的是人這個專案能做啥都不知道就開始看程式碼….此處可以留下一些疑問，比如想知道某些功能是怎麼實現的。
2.仔細看文件，瞭解專案結構，此處可能解決一些步驟1留下的疑問，比如說某個功能用到了哪種技術，但應該增加更多的疑問，這些疑問一般就是具體實現了。當然這得看文件寫的怎麼樣了。
3.把專案編譯通過，找一個好的IDE，比如VS，方便看程式碼，更重要的是方便除錯和改程式碼，如果專案本身沒有你想用的IDE的工程，試著自己把它改成自己常用的IDE可以編譯的專案。如果專案太大，這個一般不太現實，不過一兩萬行的程式碼應該還是可以的。
4.看程式碼。邊看邊註釋，可以從main函式開始看，如果在看文件和編譯的時候就對某部分非常感興趣的話，可以不用從main開始，直接看感興趣的部分。如果對某段程式碼理解不透，可以在這裡下斷點，除錯執行專案，看什麼更能會觸發這個斷點，然後通過呼叫堆疊看從什麼地方呼叫的或者跟進相關的函式看看他做了什麼，也可以試著把它註釋掉並且讓專案可以編譯通過，然後執行看看他對程式的影響。好的IDE的查詢引用的功能可以幫你快速的瞭解某個函式或者類在什麼地方用到了，方便你更好地理解它。這也是為啥要用一個好的IDE。
5.自己動手改這個專案。這一步要看有沒有必要做得這麼深入了。紙上得來終覺淺，不把這個專案改的面目全非，你是不可能完全理解這個專案的；不能把這個專案改的符合自己的要求，也就沒啥必要去看他了。
另外在此期間你會遇到各種稀奇古怪的問題，這時候就需要靠搜尋引擎或者其他方法去解決
看法二：

1. 編譯執行通過
2. 從main入口開始瞭解整個程式框架
3. 嘗試修改、增減功能
4. 閉上眼，仔細回想整個專案
作者：藍色
連結：http://www.zhihu.com/question/23503544/answer/24777267
來源：知乎
針對很多人所述說的文件，領域知識之類，而且還說什麼這是沒有什麼工作經驗的說法，我也表示直接反對，所以更新資訊。
第一：無論你領域知識、文件看的多順，你不能編譯執行起來，那我們什麼都別說了，這是第一步驟，也是最重要的一步，而且也是切身經驗之談。在我參與的C++編譯器專案中，是有很多文件給我，而且編譯原理的書籍也多如牛毛，但是我加入開發的時候，我自己完全無法編譯執行我們小組的C++編譯器（不要認為就是什麼點一個按鈕，或者敲一行命令就行了），因為涉及到的許可權與配置環境的複雜度都很多。OK，那我文件與編譯原理看的再順，有個P用。理解了一大堆詞法分析、語法分析、什麼First集合和Follow集合，弄的滾瓜爛熟，你編譯執行不通過，看不到效果，有什麼用？
第二：有些專案的文件完全跟不上程式碼（更別說很多題主所述的專案，還有可能沒有文件），那麼這個時候，你最能依靠的只有程式碼。在我離職IBM的時候，Leader曾經向我詢問過如今編譯器存在的問題與建議，我曾經有過一條反饋就是文件跟不上程式碼，很多過於陳舊。而Leader也說的很直接，文件很重要，我們也知道，而且編譯器組還有專門的文件團隊，但是那隻能是寫給外面使用者的，編譯器內部的文件只能工程師寫。但是編譯器每天都交很多程式碼，還跨國跨地區，誰能總結得了？這時候的武器依然只能是程式碼。而團隊的Mentor當初也很直白的說，你只能是找到程式的入口，然後跟進去，然後逐步摸清楚門路（IBM編譯器專案已經有幾十年的歷史，你可以想象這個規模有多麼的龐大，即使龐大如斯，也只能這樣做）。也許你有看不懂的地方，沒有關係，看不懂的地方找你的Leader（老師），然後如果這是缺乏的領域知識，那你就去自行補足。
你能依靠的就是程式碼，以程式碼驅動你去學習與補足知識。我還是那句，你不能執行起來專案，什麼都別說了，說那麼多有個P用。
看法三：
作者：長生
連結：http://www.zhihu.com/question/23503544/answer/24830632
來源：知乎
一般來說，新接觸的專案第一步應是快速深入瞭解整個專案。快速而深入瞭解一個專案的第一選擇永遠是閱讀專案文件。一上來就看程式碼無異於盲人摸象。
你首先應從專案文件裡面對整個專案有一個整體的認識，包括：
1.專案的目的
2.專案的環境
3.專案的功能模組劃分
4.各功能模組的業務流程（或執行結果）
瞭解了以上資訊之後，再去對應著各功能模組去看程式碼。
對於一般專案來說，程式碼上基本沒有難度，演算法研究類的另當別論。
看法四：
作者：遠的樹洞
連結：

http://www.zhihu.com/question/23503544/answer/25418479
來源：知乎
這是一個迭代的過程。我覺得文件和程式碼都重要 一起看才能理解的最快，前提是有充足的文件，如果沒有就另說咯。不過很多細節程式碼是最直接的，程式碼不會欺騙你，對就對，錯就錯，再複雜的演算法，邏輯，都要在程式碼體現，所以在文件和程式碼迭代不同步的專案上，程式碼才是唯一可信的。不同步的文件有時候還要誤導程式設計師。
以我現在的專案為例子，科學計算的專案，整個專案6W＋行C／C＋＋程式碼。因為涉及演算法比較多所以文件很重要，理解數學公式要花60％的時間，程式碼實現只需40％時間，所以這種專案的功能模組理解很依賴文件。沒文件和公式基本看不懂。但如果要理解整個專案就不需要理解每個功能模組的細節，只需要分析清模組輸入輸出輸出就OK了。主要看懂程式的流程，其實就是資料的輸入輸出。
我比較認同第一個答案，那些說從main開始看下去是菜鳥的，我表示強烈反對，難道不從頂層看起，還從底層看起，你從底層看懂了，也只懂一個功能而已，程式的主體流程，業務，你是一點也沒懂的，根本就談不上理解這個專案。
最後還是覺得看專案，還是個迭代的過程，多自己動手看，修改修改，編譯輸出，以實際檢驗自己的猜測。說不定還能檢查出BUG呢。
看法五
作者：一羞合上
連結：http://www.zhihu.com/question/23503544/answer/24986774
來源：知乎
讀程式碼這事兒吧，我以為，該自頂向下的讀。先看文件，從需求分析到設計，與明白人溝通，搞明白這東西是做什麼的，業務流程怎麼來怎麼去，有哪些場景，有哪些狀態，各種狀態間以什麼觸發變化等等等等。就是說，要把“讀程式碼”這個動作儘量的往後放。在正式“讀程式碼”之前，儘可能的做到“除了程式碼沒看過，別的都看過了差不多也都明白了”。最後就是讀程式碼了。
怎麼讀呢？在讀程式碼之前，已經摸清了大部分場景了，就以場景為單位，帶入做白盒測試，程式碼走讀。儘量不要糾結於某些細節，能夠從比較高的抽象層次大概瞭解流程、結構最好。讓“瞭解細節”這個動作儘量的靠後，最好是在“瞭解細節”這個動作發生時，已經大致瞭解了整個程式的結構以及主要功能模組。最後嘛，是否要“瞭解細節”視情況而定。如果老大要你動某塊程式碼，再深入瞭解也來得及。
說了這麼多，實際上就是一個原則，在任何時候，都要控制自己正在處理的資訊的複雜度，儘可能的降低複雜度。以面向物件的思想來講，就是控制抽象的邊界。邊界範圍過大，會導致大腦同時處理的資訊過多，複雜度偏高會超出大腦的處理能力。大腦擅長做的工作不是處理大量的細節，而是分而治之。
比較基礎的方法
1.執行編譯成功
2.專案文件如果有，一定要看，特別是ReadMe文件，裡面一般有各個模組的解析，如果熟悉了就清楚了
3.找到入口函式，單步除錯，一步步單步除錯，弄清每一步的意圖

仁者見仁，智者見智，如果自己有看法可以在下面評論，大家一起學習