Sarah Mount

測試之外的品質工具#

測試的價值從軟體開發旅程的早期就被灌輸給開發者。近年來，單元測試、測試驅動開發和敏捷方法的興起，更推動了在整個開發週期中充分利用測試的風潮。然而，測試只是提升程式碼品質的眾多工具之一。

靜態分析工具的歷史#

在早期，CPU 時間和記憶體都是稀缺資源。最初的 C 編譯器為了減少語意分析的遍數，移除了部分檢查，這意味著編譯時只能偵測到少量的錯誤。為了彌補，Stephen Johnson 寫了 lint 工具——它能從程式碼中移除「毛屑」，實作了部分被 C 編譯器移除的靜態分析。然而，靜態分析工具因大量**偽陽性（false-positive）**警告和不必要的風格規範建議而聲名不佳。

現代分析工具#

如今的情況已大不相同。記憶體和 CPU 時間相對便宜，編譯器能夠進行更多錯誤檢查。幾乎每種語言都至少有一個工具能檢查：

• 違反**風格指南（style guide）**的地方
• 常見的陷阱（gotcha）
• 有時甚至能捕捉到難以發現的錯誤，例如潛在的空指標解參考（null pointer dereference）

更進階的工具如 Splint（C 語言）或 Pylint（Python）是可配置的，你可以透過配置檔、命令列開關或 IDE 設定來選擇工具要發出哪些錯誤和警告。Splint 甚至允許你在程式碼註解中加入標註，以提供更好的分析提示。

自己動手打造#

如果現有工具無法捕捉到你需要的錯誤或違規，你也可以自行撰寫靜態檢查器。大多數語言（尤其是標記為 dynamic 的語言）都將**抽象語法樹（abstract syntax tree）**和編譯器工具作為標準函式庫的一部分公開。深入了解語言標準函式庫中較少使用的角落，往往能發現對靜態分析和動態測試都有用的隱藏寶藏。

不要讓測試成為品質保證的終點——善用分析工具，也別怕自己動手打造。