博文轉自：https://blog.csdn.net/jysg9/article/details/24193181，部分內容略有改動。

引言

本篇文章為了探討如何快速上手一個大型專案。針對經驗尚淺需要快速接手一個專案的開發人員。

當他們拿到一個大型程式後，他們便開始一句一句的閱讀分析，夜以繼日，懸樑刺股。可結果依然不理想，往往進入以下狀態：

1、花費了很長時間，也沒有多大進展，與當時預計的日期相差甚遠。

2、由於週期較長，他們往往在重複閱讀分析最初的極小部分。就像有的童鞋讀書一樣，幾個月前讀的是前兩章，幾個月後還是那兩章，原地踏步。

3、他們沒法弄清程式的結構，雲裡霧裡，看不清前方的路，也記不住走過的路。久而久之便形成膽怯心理，當接手一個新功能後，在士氣上已經失敗了，漸漸地丟了那股初出茅廬時的勇氣。

這樣的狀態對他們產生極負面的影響：

其一，任務不能如期完成，導致成本一再飆升；其二，不便於他們能力的提升，因為要能力提升往往需要去更多的研究他們實現的系統或優秀的開源專案。

解決辦法

以下是如何快速理清程式脈絡，業務流程的方法建議：

1、先建好環境，讓程式跑起來

當你拿到一個程式後，即使你不看程式碼，通過交接人的介紹、專案經理的介紹、其他同事的介紹，也應該知道它是幹什麼的。然後，知道了大致功能後，把環境建立起來，想辦法讓程式執行一遍。在一般情況下，要做到這一點不難。

為什麼推薦首先執行程式呢？因為建立好的執行環境，一方面可以初步驗證一下此程式的功能，以及正確性完整性；另一方面方便接下來的分析除錯，為斷電除錯和日誌除錯提供了可能。

2、掌握程式的結構

如果是開源專案，那就想辦法找到作者提供的WiKi設計說明等。

如果是企業內部開發專案，則一般都會有完整的文件，不要捨棄文件閱讀程式碼，這樣一定沒有什麼好果子吃，其實程式都是在試圖對業務流程進行“程式碼解釋”，即將業務流程轉化為if-else，尊重文件的作用至關重要。

3、先整體，再區域性

整體是相對的，所以，我們以相對的整體來說，將大致的整體邏輯理清，再去研究細節實現。

不要一開始便逐字逐句的閱讀程式碼，這種方法是最低效。這些童鞋往往是先了解各個點，再將點串也線，線串也面。他們直到最後也不一定看清楚程式的真面目，或經過幾個月才豁然開朗。整個過程如地獄般煎熬。

而推薦的方法是：先整體再區域性，先平面再線點。這樣不僅更高效，而且輕鬆。

4、大膽猜想，小心求證

在閱讀程式的過程中，我們往往對某一處或幾處邏輯不肯定，可能是這樣，也可能是那樣。

當處在這種狀態下，我們往往不知道如何選擇，停滯不前。

其實這個時候不需要顧慮太多，大膽猜想，將自己的假設帶入到邏輯分析中去，看看是否可以得到驗證。那麼需要注意的就是，需要保持一個客觀的角度去驗證我們的猜想，此時也需要小心謹慎，避免過度猜想，以免走偏。

5、除錯程式

我們可以通過斷電除錯和日誌除錯來進行程式碼邏輯的追蹤，或日誌分析。

6、忽略細節

這個方法可以參考 “先整體，再區域性” 的原則，將主線看做是整體，分支看做是區域性，理清主線後再去研究分支和細節實現。

7、程式千百套，我來問度娘

高超的問題搜尋技巧是在千百次搜尋中鍛煉出來的。

百度作為國內的搜尋引擎代表，可以為我們提供豐富的查閱資料庫。我們要做的，就是不斷的提煉我們的關鍵字，以最少的搜尋次數定位我們最需要的搜尋結果。