各位程式師兄弟姐妹們， 當你在看密密麻麻的代碼的時候， 當你試圖從其中找出Bug的時候， 當你面對大段函數的時候， 是不是有種暈頭轉向，
挺住， 表哭！今天， 小編就來和大家一起get高效讀代碼技能！
在我們閱讀面前的代碼時， 無非有一下幾種目的：
1、純粹學習；2、添加新功能；3、重構舊代碼；4、修復他人的Bug
修復實際工作中幫別人修復Bug這種情形， 十有八九你要遇到，
為了學習去讀源碼， 這是最愉快的最放鬆的。 設定可檢驗的目標才會有收穫， 否則就會像走到大街上看見一美女擦肩而過那樣， 驚豔一下下， 過後嘛關係嘛收穫也沒了。
其他的目的， 重構舊代碼、添加新功能， 因為帶有創造性， 創造性的活動能給人帶來強烈的愉悅， 所以雖然這兩種目的也有很多讓人不爽的部分， 不過想到我可以讓一棵老樹煥發青春， 不爽也就慢慢弱下去了。
磨刀不誤砍柴工， 在閱讀代碼之前， 我們需要備好必要的工具， 以提高讀碼效率！小華推薦以下工具：
1、SourceInsight， 最好的源碼流覽工具， 它能維護符號庫， 動態顯示上下文， 還能繪製調用關係圖， 最好的， 沒有之一。
2、紙質筆記本，
3、記事本、Notepad++、有道雲筆記、為知筆記等， 記錄閱讀源碼過程中的關鍵點、心得體會、分析過程
4、Visio， 用於繪製簡單的框圖， 表述源碼的模組劃分、層次結構等
5、StartUML， 用於最後繪製類圖、時序圖等， 方便交流
6、掃描全能王（CamScanner）， 一款可以通過拍照達到掃描效果的App， 可以用它掃描你在紙質筆記本上寫下的文字， 繪製的框圖， 分享給其他人， 如果你懶得用軟體繪製圖示， 那手繪之後掃描成電子檔就最適合你了。
主要方法：
1、做好知識準備
前戲很重要， 準備好了後面會有不斷水到渠成的快感！
業務基礎， 每一份有實際意義的源碼都離不開業務， 必須先對業務有概念
技術基礎， 這個源碼用什麼語言， 什麼框架， 什麼協力廠商模組， 都需要先有所瞭解
文檔， 儘量找到業務、需求、概要、詳細等文檔， 幫助會很大， 然而， 我們經常面臨的情況是， 只有源碼， 只有源碼， 只有源碼， 片言隻字的文檔也無， 所以只好堅信——源碼是最好的文檔。
人， 搞明白哪個程式師維護過這份代碼，
2、建立層次和結構
看代碼不是看小說， 不會那麼順暢。 為了理解代碼， 需要在腦子裡建立起原始程式碼背後的層次和結構映射。 因此， 在開始分析項目支出， 就要明確代碼的子項目， 包， 類的層次和結構， 主要由哪些包構成， 每個包大致做什麼用。 主要的類有哪些， 各自的大致職責是什麼。 主要的類裡面， 又有哪些主要的方法。
3、要抓住主幹
提綱挈領， 對做很多事情都是提高效率的方式， 很多代碼是用來做一些瑣碎的， 事務性的事情的。 要高效理解和把握代碼， 就必須抓住主幹。 對於代碼中的一些主要方法， 或者流程， 可以梳理出它們的主要步驟， 次要的東西可以忽略不管，需要的時候再關注。
4、要形成文檔
好記性不如爛筆頭，勤快動腦同時也勤快動手，看代碼會容易很多。在我們分析這些東西的同時，用一種有效的方式，把分析的結果記錄下來，既保存了工作成果，更重要的是，幫助我們更容易進行分析，向深挖的時候，知道現在自己在哪裡，向回退的時候，又退得出來，不至於迷路。類圖，序列圖，都是有用的文檔形式，也可以用自己定義的更靈活的圖表。
可以選擇適合自己的記錄方式，小本本、軟體皆可。用軟體（Notepad++、有道筆記、為知筆記等）來記錄有個壞處——必須切換螢幕，會在形式上中斷代碼閱讀過程。
盡可能詳細的記錄，但不必看到什麼記錄什麼，要間隔性的記錄，比如弄明白了某個子模組的邏輯、某個類的作用、某些函數的調用關係時再記錄，否則記錄這個動作本身會打斷思考。
每天工作結束，記錄進度（弄明白的部分），記錄疑問，記錄第二天要弄明白什麼東西，這樣你的工作狀態就入棧了，第二天來了很容易出棧，快速進入工作狀態。記錄看到的優秀設計，提高審美，見賢思齊，自我成長。
5、要合理運用各種可用手段
靜態分析，當然是分析代碼的基本手段；但是除了靜態分析，如果你的代碼也是可以運行的，運行它，觀察它的調用堆疊，LOG，或者用調試工具進行跟蹤。對於那些主要的方法，流程，有必要用動態跟蹤的方式，弄清楚它的過程。這也會比靜態分析更直接，更快地告訴你它到底走過哪些路徑，執行了哪些方法。
6、不斷學習程式設計技巧
其實，這一點是大家都知道的，讀代碼讀的慢無非是對常用函數和常用庫，一些程式設計技巧不熟悉，就像讀做英文閱讀理解時，不認識單詞，不懂語法一樣，讀得那個費勁啊！所有熟悉了常用庫和程式設計技巧之後，很多代碼掃一眼就明白了，思路不會被不懂得的語法或者程式設計技巧打斷，一直停留在程式的邏輯上。
最後，小編不得不說：最好的方法還是要多看，多讀，技巧方法再多，不讀的話都是沒用的，看了幾十萬個行規模的系統後再看其他系統就自然如履平地啦！所以，小夥伴們，要想讀得快，現在就去讀吧！加油！
4、要形成文檔
好記性不如爛筆頭，勤快動腦同時也勤快動手，看代碼會容易很多。在我們分析這些東西的同時，用一種有效的方式，把分析的結果記錄下來，既保存了工作成果，更重要的是，幫助我們更容易進行分析，向深挖的時候，知道現在自己在哪裡，向回退的時候，又退得出來，不至於迷路。類圖，序列圖，都是有用的文檔形式，也可以用自己定義的更靈活的圖表。
可以選擇適合自己的記錄方式，小本本、軟體皆可。用軟體（Notepad++、有道筆記、為知筆記等）來記錄有個壞處——必須切換螢幕，會在形式上中斷代碼閱讀過程。
盡可能詳細的記錄，但不必看到什麼記錄什麼，要間隔性的記錄，比如弄明白了某個子模組的邏輯、某個類的作用、某些函數的調用關係時再記錄，否則記錄這個動作本身會打斷思考。
每天工作結束，記錄進度（弄明白的部分），記錄疑問，記錄第二天要弄明白什麼東西，這樣你的工作狀態就入棧了，第二天來了很容易出棧，快速進入工作狀態。記錄看到的優秀設計，提高審美，見賢思齊，自我成長。
5、要合理運用各種可用手段
靜態分析，當然是分析代碼的基本手段；但是除了靜態分析，如果你的代碼也是可以運行的，運行它，觀察它的調用堆疊，LOG，或者用調試工具進行跟蹤。對於那些主要的方法，流程，有必要用動態跟蹤的方式，弄清楚它的過程。這也會比靜態分析更直接，更快地告訴你它到底走過哪些路徑，執行了哪些方法。
6、不斷學習程式設計技巧
其實，這一點是大家都知道的，讀代碼讀的慢無非是對常用函數和常用庫，一些程式設計技巧不熟悉，就像讀做英文閱讀理解時，不認識單詞，不懂語法一樣，讀得那個費勁啊！所有熟悉了常用庫和程式設計技巧之後，很多代碼掃一眼就明白了，思路不會被不懂得的語法或者程式設計技巧打斷，一直停留在程式的邏輯上。
最後，小編不得不說：最好的方法還是要多看，多讀，技巧方法再多，不讀的話都是沒用的，看了幾十萬個行規模的系統後再看其他系統就自然如履平地啦！所以，小夥伴們，要想讀得快，現在就去讀吧！加油！