牛人教你如何閱讀源碼

 

一、騰訊IMWEB負責人說：

首先，搞清楚本身要讀懂他們的緣由和動機。
其次，能夠先看下這些優秀框架或者庫的設計文檔和架構圖，這樣會讓你宏觀上對一些概念有些認識。 
而後，從你最感興趣的一個點，開始設置斷點，跟進去看發生了哪些事情。 和架構設計哪一塊是match的。

有人補充：最快，最易懂方法。斷點單步調試。
如：jQuery中 $.fn.show 源碼是如何實現的。
本身寫個 $('#test').show()，打上斷點、單步調試、那麼你能夠看到jquery中每一步發生了什麼事情。分析便可。

 

二、知乎匿名：

我會先簡單瞭解手上JS代碼的依賴，這能夠從閱讀package.json或者bower.json看出來，也能夠用靜態分析工具好比 https://jsanalyse.codeplex.com/
我會用編輯器自帶的靜態分析功能， 好比自動解析出function定義，而後利用編輯器搜索功能瞭解代碼調用關係
若是是客戶端JS，我會用Chrome Devtools的斷點調試功能去深刻理解程序執行的脈絡
若是是後端JS，則是找到HTTP handler或者Socket的定義部分，而後從那裏用

 

三、csdn你們發言：

1）source insight 看代碼
EA 反工程看uml 類圖

 

四、匿名發言：

1）、一邊閱讀代碼一邊寫註釋。這是我用過的最好的方法，對代碼理解得更深刻，看一些重要代碼或者特別難懂的代碼時挺有用。更況且，註釋也是一種文檔嘛。

2）、一邊閱讀代碼一邊繪製UML。這個方法適用於類之間的關係較複雜和調用層次較深的狀況，我通常都是先繪製順序圖，而後爲順序圖中的類繪製關係圖。

3）、經過Debug來跟蹤程序的主要執行過程，這樣就能夠分清主次了，閱讀的時候更有針對性。

4）、類的快速閱讀。先弄清楚它在繼承鏈中的位置，看看它的內部狀態，也就是成員變量，通常來講，類的對外接口都是對成員變量的訪問、加工、代理等，而後看看它的對外接口，也就是公有成員函數，識別核心的一個或多個函數，這時候你應該能夠大概瞭解這個類的職責或做用了。可能這個類是某個設計模式中的一個組成部分，因此，設計模式的掌握對代碼的快速閱讀也是頗有幫助的。
5）、帶着問題去閱讀。好比想了解Android中的消息機制，那麼看看Looper、Handler、MessegeQueue這幾個類就能夠了，其餘的不要去看，要否則就跑題了。


  下面列幾個閱讀源碼時所處的情景，在特定場景下用哪些方法：
     不太熟悉業務邏輯，還不是很清楚它是幹啥的，能夠用三、5。
     代碼量很大，有幾十萬行，甚至百萬行，能夠用二、三、5。
     你沒法看見程序的運行過程，好比沒有用戶界面，也有多是沒法運行的，能夠用三、5。
     設計複雜，用了大量的設計模式，調用鏈很深，能夠用一、二、三、四、5。
     時間有限，沒有那麼多時間讓你看源碼，能夠用三、5。

 

五、知乎上面匿名回答：

1）讀代碼最忌諱的是不抓結構抓細節，只見樹木不見森林

2）首先應該先了解代碼的功能業務，在瞭解業務邏輯的狀況下，進行代碼閱讀以爲是事半功倍的，可以先多用用列跑起來，看看功能。

3）閱讀代碼有兩種模式：top-down 和 bottom-up。

Top-down 模式，就是先設定一個 use case，好比說打開一個文件。而後靜態跟着代碼看，或者用 debugger 跟着看。每次出現函數調用的時候，把函數的執行層次紀錄下來。大體以下：
func1( )
   func2(  )
       func(  )
   func3(  )


這種圖表很隨意，你能夠根據本身的須要增長信息。好比我有時會把重要的「實際參數」一直標下來，這樣閱讀深層次代碼不用再回頭查形式參數到底指什麼。這個圖的基本做用是防止在閱讀深層次代碼時忘記整體執行層次。

Top-down 模式進行到必定層次，每每會發現雖然圖畫了出來，但仍是沒法瞭解程序再幹什麼。這時須要轉入 bottom-up 模式，一直深刻到最底層，給能瞭解做用的底層函數一個一個的寫文檔。固然這時的文檔是徹底底層的觀點。

而後就是不斷在兩個模式之間轉換，不斷的細化兩種模式的理解。

4）「代碼閱讀方法與實踐」推薦這本書

 

六、網頁中如何閱讀人家的源代碼呢，網易前端攻城獅回答：

用Chrome打開開發者工具，切換到Sources選項卡，而後選擇感興趣的代碼文件，並使用'Pretty Print'功能格式化代碼。而後觀察代碼，打斷點，調試一鼓作氣。

補充：

Chrome，按F12
看Sources
而後再看看 Network 由於有的JS是動態加載，sources裏面會看不到

總結來講：

一、帶着問題讀

二、對它先產生初步映像

三、使用source insight工具

四、使用debugger模式

五、作好註釋

 

chrome中如何debug呢？

 

你是怎麼調試 JavaScript 程序的？最原始的方法是用 alert() 在頁面上打印內容，稍微改進一點的方法是用 console.log() 在 JavaScript 控制檯上輸出內容。嗯~，用這兩種土辦法確實解決了不少小型 JavaScript 腳本的調試問題。不過放着 Chrome 中功能愈加強大的開發者工具不用實在太惋惜了。本文主要介紹其中的 JavaScript斷點設置和調試功能，也就是其中的 Sources Panel（之前叫 Scripts）。若是你精通 Eclipse 中的各類 Java 調試技巧，那麼這裏的概念都是相似。寫做本文時使用的 Chrome 版本爲 25.0.1364.172。

基本環境

 

SourcesPanel 的左邊是內容源，包括頁面中的各類資源。其中，又分 Sources 和 Content scripts。Sources 就是頁面自己包含的各類資源，它是按照頁面中出現的域來組織的，這是咱們要關注的。異步加載的 js 文件，在加載後也會出如今這裏的。Content scripts 是 Chrome 的一種擴展程序，它是按照擴展的ID來組織的，這類擴展實際也是嵌入在頁面中的資源，它們也能夠讀寫DOM。編寫、調試這類擴展的開發者纔要關心它們，若是你的瀏覽器沒安裝任何擴展，那麼Content scripts 就看不到任何東西。

Sources Panel 的中間主區域用於展現左邊資源文件的內容。

Sources Panel 的右邊是調試功能區，最上面的一排按鈕分別是暫停/繼續、單步執行、單步跳入、單步跳出、禁用/啓用全部斷點。下面是各類具體的功能區。稍後介紹。

注意，左右兩邊的區域默承認能收縮在兩側沒有顯示出來，點擊兩側的伸縮按鈕展現出來。左邊區域展現出來時默認是自動收縮狀態，點擊旁邊的 pin 按鈕就不會縮回去了。

最下面還有一些功能按鈕頗有用。

這幾個按鈕的意思：

第一個：按照代碼運行順序，一步一步往下走，直到走完位置。（最經常使用）

第二個：下一步，能夠進入下一個函數棧。（看複雜源碼必備神器）

第三個：退出當前函數或向上找函數棧並退出。（不經常使用）

在源代碼上設置斷點

經過左邊的內容源，打開對應的 JavaScript 文件，鼠標點擊文件的行號就能夠設置和刪除斷點。添加的每一個斷點都會出如今右側調試區的 Breakpoints 列表中，點擊列表中斷點就會定位到內容區的斷點上。若是你有多個文件、多個斷點的話，利用Breakpoints 列表中的斷點快速定位很是方便。

對於每一個已添加的斷點都有兩種狀態：激活和禁用。剛添加的斷點都是激活狀態，禁用狀態就是保留斷點但臨時取消該斷點功能。在Breakpoints 列表中每一個斷點前面都有一個複選框，取消選中就將禁用該斷點。斷點位置的右鍵菜單中也能夠禁用斷點。也能夠在右側功能區上面按鈕臨時禁用全部已添加的斷點，再點一下恢復原狀態。

條件斷點：在斷點位置的右鍵菜單中選擇「Edit Breakpoint...」能夠設置觸發斷點的條件，就是寫一個表達式，表達式爲 true 時才觸發斷點。查看斷點的環境調用棧（Call Stack）：在斷點停下來時，右側調試區的 Call Stack 會顯示當前斷點所處的方法調用棧，好比有一個函數 g() 其中又調用了函數 f() ，而我在 f() 中設置了一個斷點，那麼我在 console 中執行函數 g() 的時候會觸發斷點，其調用棧顯示以下：

最上面是 f()，而後是 g()。調用棧中的每一層叫作一個 frame，點擊每一個 frame 能夠跳到該 frame 的調用點上。

此外，還能夠在 frame 上用右鍵菜單從新開始執行當前 frame，也就是從該 frame 的開始處執行。好比在函數 f() 的 frame 上 Restart Frame， 斷點就會跳到 f() 的開頭從新執行，context 中的變量值也會還原。這樣結合變量修改和編輯代碼等功能，就能夠在當前 frame 中反覆進行調試，而不用刷新頁面從新觸發斷點了。查看變量

Call Stack 列表的下方是 Scope Variables 列表，在這裏能夠查看此時局部變量和全局變量的值。執行選擇的代碼

在斷點調試時，能夠用鼠標選擇想要查看的變量或表達式，而後右鍵菜單執行「Evaluate in Console」，就能夠看到該表達式的當前的值了。中斷下次要執行的 JavaScript 語句右側調試區的上面的「中斷/繼續」按鈕還有一個功能，在沒有觸發斷點時，點一下這個按鈕就會進入「準備」中斷的狀態，頁面下一次執行 JavaScript 語句時會自動中斷，好比觸發了一個點擊動做時會執行的代碼。臨時修改 JavaScript 代碼一般咱們在調試代碼時習慣：修改代碼→刷新頁面→從新檢查，這麼一個循環。但其實 Chrome 中能夠臨時修改 JS 文件中的內容，保存（Ctrl+S）就能夠當即生效，結合 Console 等功能就能夠當即從新調試了。但注意這個修改是臨時的，刷新頁面修改就沒了。

異常時斷點

在界面下方能看到按鈕，它是設置程序運行時遇到異常時是否中斷的開關。點擊該按鈕會在3種狀態間切換：

默認遇到異常不中斷

遇到全部異常都會中斷，包括已捕獲的狀況

僅在出現未捕獲的異常時才中斷

主要解釋一下狀態2和狀態3的區別

try{
throw 'a exception';
}catch(e){
console.log(e);
}

上面 try 裏面的代碼會遇到異常，可是後面的 catch 代碼可以捕獲該異常。若是是全部異常都中斷，那麼代碼執行到會產生異常的 throw 語句時就會自動中斷；而若是是僅遇到未捕獲異常才中斷，那麼這裏就不會中斷。通常咱們會更關心遇到未捕獲異常的狀況。

在 DOM 元素上設置斷點

有時候咱們須要監聽某個 DOM 被修改狀況，而不關心是哪行代碼作的修改（也可能有多處都會對其作修改）。那麼咱們能夠直接在 DOM 上設置斷點。

 

如圖所見，在元素審查的 Elements Panel 中在某個元素上右鍵菜單裏能夠設置三種不一樣狀況的斷點：子節點修改自身屬性修改自身節點被刪除選中以後，Sources Panel 中右側的 DOM Breakpoints 列表中就會出現該 DOM 斷點。一旦執行到要對該 DOM 作相應修改時，代碼就會在那裏停下來，以下圖所示。

XHR 斷點

右側調試區有一個 XHR Breakpoints，點擊+ 並輸入 URL 包含的字符串便可監聽該 URL 的 Ajax 請求，輸入內容就至關於 URL 的過濾器。若是什麼都不填，那麼就監聽全部 XHR 請求。一旦 XHR 調用觸發時就會在 request.send() 的地方中斷。

按事件類型觸發斷點

右側調試區的Event Listener 列表，這裏列出了各類可能的事件類型。勾選對應的事件類型，當觸發了該類型的事件的 JavaScript 代碼時就會自動中斷。

調試快捷鍵

 

全部開發工具中的快捷鍵均可以在界面右下角的設置中查到。斷點調試時通常用的是 F八、F十、F11或 Shitf+F11，但在 Mac OS 上 F10 等功能鍵可能與系統默認的快捷鍵衝突。不要緊，它們分別能夠用 Cmd+/ 、Cmd+'、Cmd+; 、Shift+Cmd+; 代替。//@ sourceURL 給 eval 出來的代碼命名有時候一些很是動態的代碼是以字符串的形式經過 eval() 函數在當前 Javascript context 中建立出來，而不是做爲一個獨立的 js 文件加載的。這樣你在左邊的內容區就找不到這個文件，所以很難調試。其實咱們只要在 eval 建立的代碼末尾添加一行 「//@ sourceURL=name「就能夠給這段代碼命名（瀏覽器會特殊對待這種特殊形式的註釋），這樣它就會出如今左側的內容區了，就好像你加載了一個指定名字的 js 文件同樣，能夠設置斷點和調試了。下圖中，咱們經過 eval 執行了一段代碼，並利用sourceURL 將它命名爲dynamicScript.js ，執行後左側內容區就出現了這個「文件」，而它的內容就是 eval 的中的內容。 還能夠看看這個給動態編譯出來的CoffeeScript 代碼命名的 示例：

 

var coffee = CoffeeScript.compile(code.value)+ "//@ sourceURL=" + (evalName.value || "Coffeeeeeeee!");
eval(coffee);

實際上，//@ sourceURL 不只僅能夠用在 eval 的代碼中，任何 js 文件、甚至是 Javascript Console 輸入的代碼均可以用，效果同樣！格式化代碼（Pretty Print）按鈕用於把雜亂的代碼從新格式化爲漂亮的代碼，好比一些已被壓縮的 js 文件基本無法看、更無法調試。點一下格式化，再點一下就取消格式化。

美化前

美化後參考資料：Chrome Developer Tools 官方文檔