node.js學習總結之調式程式碼的方法_node.js

前言

你有沒有曾經調式某段程式碼時，總覺得世界上有鬼？

你有沒有曾經調式API時，總覺得是呼叫第三方的介面問題或是文件說明不對？

你有沒有曾經調式一個bug 時，總感覺問題的來源是使用的方式不對？

你有沒有在安裝一個服務時，總覺得文檔或環境不相符合？

相信過程和方法，切勿被結果誤導 ............

概述

調式代碼很多時候類似查案一樣，只是結果的重要性不同，警察查案為的是人民安穩，而我們調式則是為了系統的安穩。既然這樣我們就不要冤枉任何一段代碼和程序，以免他們受到不合理的懲罰。

以下的一些過程方法都來自於個人的總結，從個人角度說前人的一些方法都是經過長期的經驗積累，當然參考性理論性都比較強，而作為個人的方法，則可能更適合像我等DS 。

測試方法

程式碼過程式調式方法

程式碼調式首先要注意的是過程，你必須要理清楚導致最終結果的思路，也就是作案的過程，從作案過程中的一步步跟進得到作案結果。在作案過程分析中對於每一個疑點都必須打上標記（也就是程式碼中所提到的 log 資訊）。經過這樣的分析過程後，再進行黑盒測試，加入輸入，驗證結果。最終根據每一步的標記來驗證你的判斷，從而找到原因。

以上的方案是一種過程式的調式方式。這種方式的優點不言而喻，直接可以透過一個測試就可以分析清楚整個過程，但是這種方式很耗時間，理清楚自己的程式碼邏輯尚可，而想要理清楚他人邏輯程式碼則可要難於上青天。

單元測試調式方法

單元測試的基本目的是確保某個函數、類別或某個功能模組的正常運作，包括其異常情況的測試驗證。而身為程式設計師最喜歡的驗證方式莫過於「打樁」（打樁的意思就是提供假預設資料），這種方式調式起來非常方便，但是有一個不利的地方就是無法再利用，因為在我們驗證正常以後，許多開發人員都會將其註釋或刪除，因此如果我們在開發環境開發完成，但我們希望在測試環境驗證時，則必須又要重新寫一篇打樁邏輯，那麼這樣看，到現網時，則會更加的麻煩。既然這麼多不便，你可以試試下面的做法。

新增一個單元測試類，這個類需要控制其權限，只有透過後台登入或是命令列才可以執行，該類承載的作用就是對系統的關鍵邏輯進行檢測，並且做出相應的測試輸出結果。要相信所有的介面類別都是可以透過單元測試類別去完成測試的。很多時候程式設計師在質疑，這件事情是不是應該我們做？其實還真是需要我們去做，畢竟很多測試現在做的都是黑盒子測試。

這種調式方法適合在開發過程中，並且可以確保我們現網的程式碼發布後運作正常。希望大家在規劃開發時間時也能將流程並於開發階段。

快速定位法

前面兩個那麼複雜的過程太理想化了？我的程式碼就只有 100 行，系統也不複雜。如果是這樣的話，那麼就快速的進行定位分析。很多時候會遇到

1、輸入正常，輸出異常；

2、輸入正常，邏輯異常，輸出異常；

3、輸入異常，邏輯正常，輸出正常；

4、輸入異常，邏輯異常，輸出無。

在個人的開發過程中，我常常會遇到上面的某種類型的問題，例如在 Node.js 開發過程中，遇到 string.length 提示 string 沒有 length 方法。當時就昏頭的在問自己，為什麼其他 string 都有 length 方法，為什麼這就沒有呢？應該很多同學都知道問題就在於這個 string 根本就不是 string ，只是說你自己把它理想化為 string 了，也就是你輸入的本來就有問題。那麼定位這個問題的最好方法就是列印輸入，列印輸出即可。

可能其他的程式沒有這麼簡單，但是最基本的就是在主函數中的會遇到異常的函數都進行輸入輸出判斷，那樣就可以快速的定位。

切記：不要斷章取義，自以為是。

上面的方法以及過程都只是基於 PHP 或 Node.js 總結出來的，對於 C & C 可能存在相似或相異處。不喜勿噴，且看且珍惜吧。