第一步前期知識儲備：前期知識的儲備對每一個程式設計師來說很重要，只有準備好了，後面學習才能事半功倍；技術方面我們需要知道這份原始碼採用了哪種語言，利用了哪些框架；接下來就是文件，儘可能來根據文件來理解原始碼；

第二步對待原始碼需要有分層的概念：如果遇見一份優秀的程式碼，我們可能會更加容易去讀懂。但是如果遇見一份差的或者是不堪入目的程式碼，我們更多時候能夠更好去為了理解程式碼，需要在腦子裡建立起原始碼背後的層次和結構對映。

第三步找出主幹內容：有點像是閱讀文章時找出這篇文章的中心句，對待程式碼也是一樣，提綱挈領，對做很多事情都是提高效率的方式，很多程式碼是用來做一些瑣碎的，事務性的事情的。要高效理解和把握程式碼，就必須抓住主幹。

相信每一個程式設計師都有讀別人程式碼的經歷，尤其是半路加入專案組，或者是半路接手同事未完成的專案。同時我也相信每個程式設計師都有過讚歎別人程式碼的經歷，也有過鄙視別人程式碼經歷，但是不管怎麼說讀別人程式碼總歸是程式設計師繞不開的一件事情。

讀別人程式碼分為幾種情況，一種情況是讀整體程式碼，另一種情況是讀某個模組，這主要取決於你參與專案的階段和參與的程度。通常情況下，讀別人程式碼都有一個基本的思路，我以自己的經驗來描述一下這個過程。

在讀別人程式碼之前首先要了解一下專案的整體功能，通常情況下專案都有比較詳細的方案規劃，要先把方案看一下。這個步驟是建立自己程式碼實現思路的過程，程式設計師在閱讀方案的時候會有自己的一系列常規解決方案，如果待讀的程式碼是其中的一種方案，那麼恭喜你，你可能很快就能完成程式碼的梳理。

方案有的寫的比較詳細，有完整的設計圖和流程圖，那麼這個時候再讀程式碼就比較容易了，因為知道了入口和出口，細節看起來就比較好理解。而有的方案寫的比較籠統，或者是中間經過多次調整，這些調整可能並沒有體現在方案中（實際專案中比較常見），這個時候需要做很多標記，必要的時候要跟專案經理或者架構師做一個詳細的溝通。

現在的程式開發基本上都是按照角色進行任務劃分的，所以程式設計師在讀別人程式碼的時候大部分情況下不存在技術上的障礙，也就是說基本上採用的程式語言和框架都是統一的。這種情況下讀程式碼實際上就是讀思路，而思路是建立在功能模組劃分上的，所以瞭解專案的功能模組劃分就比較重要了。

通常情況下方案並不會把每個實現模組都完整描述清楚，這個時候需要讀程式碼的程式設計師自己完成功能標記。專業的程式設計師會寫註釋，有的註釋寫的非常清晰，這個對讀程式碼的人來說絕對是件賞心悅目的事情。所以說寫程式碼的時候寫好註釋對程式設計師非常重要，開玩笑的說這是一個積攢人品的過程。

這個階段就是開始進行程式碼的細節分析了，有的程式碼量比較小的程式可以直接進行這個步驟。當讀到每個類實現的階段時，我比較喜歡為每個方法加一個標註，然後讓程式跑一下，這樣基本上就知道核心引數的變化過程以及輸出的結果了。

當然，讀完程式碼之後一定要把標註去掉的，也不要輕易的去修改看似有問題的部分，因為任何一個不合理的設計背後都有可能是萬不得已而為的，你改了其中一個問題可能會引發一系列連鎖問題，一定要謹慎。

總之，讀別人程式碼有的時候是個學習的過程，有的時候是個鬱悶的過程（大部分的情況），不管怎麼說這就是程式設計師工作內容的一部分。

1.基本條件：語言能力，業務能力。首先要對所用程式語言瞭解，清楚語法語義。其次要對程式的業務知識瞭解，金融程式碼就要有金融知識，電子程式碼就要有電子知識，遊戲程式碼就要有遊戲知識。

2.根本條件：程式碼思想。緊緊把握住中心，段碼是做什麼的，實現什麼功能，用的是什麼演算法和結構，目的是什麼以及如何體現。

3.充要條件：抗干擾能力。沒錯，小編認為這是高效閱讀程式碼的充分必要條件！抗干擾主要指的是程式碼干擾，程式碼中的冗餘部分，錯誤部分，個性化部分，大神般精簡不易讀部分……抗干擾能力需要經驗，需要邏輯思維，需要輔助分析(例如參考文件，流程圖)，也許需要臨場惡補相關知識。