放棄 console.log 吧!用 Debugger 你能讀懂各種源碼

很多同學不知道爲什麼要用 debugger 來調試,console.log 不行麼?

還有,會用 debugger 了,還是有很多代碼看不懂,如何調試複雜源碼呢?

這篇文章就來講一下爲什麼要用這些調試工具:

console.log vs Debugger

相信絕大多數同學使用 console.log 調試的,把想看的變量值打印在控制檯。

這樣能滿足需求,但是遇到對象的打印就不行了。

比如我想看 webpack 源碼裏的 compilation 對象的值,我打印了一下:

但你會發現對象的值也是對象的時候不會展開,而是打印一個 [Object] [Array] 這種字符串。

更致命的是打印的太長會超過緩衝區的大小,terminal 裏會顯示不全:

而你用 debugger 來跑,在這裏打個斷點來看就沒這些問題了:

 

有的同學可能會說,那打印一個簡單的值的時候用 console.log 還是很方便呀。

比如這樣:

真的麼?

那還不如用 logpoint:

代碼執行到這裏就會打印:

而且沒有污染代碼,用 console.log 的話調試完之後這個 console 不也得刪掉麼?

但是 logpoint 不用,它就是個斷點的設置,不在代碼裏。

當然,最重要的是 Debugger 調試是可以看到調用棧和作用域的!

首先是調用棧,它就是代碼的執行路線。

比如這個 App 的函數組件,你可以看到渲染這個函數組件會經歷 workLoop、beginWork、renderWithHooks 這些流程:

你可以點開調用棧的每一幀看下都執行了啥邏輯,用到啥數據。比如可以看到這個函數組件的 fiber 節點:

再就是作用域,點擊每一個棧幀就可以看到每個函數的作用域中的變量:

 

用 Debugger 可以看到代碼的執行路徑,每一步的作用域信息。而你用 console.log 呢?

只能看到那個變量值而已。

拿到的信息量的差距不是一點半點,調試時間長了,別人會對代碼的運行流程越來越清晰,而你用 console.log 呢?還是老樣子,因爲你看不到代碼執行路徑。

所以,不管是調試庫的源碼還是業務代碼,不管是調試 Node.js 還是網頁,都推薦用 Debugger 打斷點,別再用 console.log 了,就算想打印日誌,也可以用 LogPoint。

而且在排查問題的時候,用 Debugger 的話可以加一個異常斷點,代碼跑到拋異常的地方就會斷住:

可以看到調用棧來理清出錯前都走了哪些代碼,可以通過作用域來看到每一個變量的值。

有了這些東西,排查錯誤不就很輕鬆了麼!

而你用 console.log 呢?

啥也沒,只能自己猜。

由於本篇文章都是gif動圖,今天上傳太累了,要看全文,請點擊以下鏈接:

開發者網站----放棄console.log吧!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章