溫故知新：靜態(tài)分析
代碼在計算機上運行，但用途并不限于此，同樣是用來閱讀和理解的。不易理解的代碼不能輕易地維護或改進，代碼庫的復雜性與其缺陷率之間存在著相關性。理解大型的代碼庫是困難的，因此需要各種工具和技術來協助。
靜態(tài)代碼分析（簡稱靜態(tài)分析）工具，是由程序或算法組成的，從一個程序的源代碼中提取事實，而不需要執(zhí)行有問題的程序，通常作為日常軟件開發(fā)過程中的一個特定階段。通過使用工具進行靜態(tài)分析，有機會使用分析中產生的事實來進一步理解、評估和修改相關的代碼?？梢詮脑创a中提取的數據目標可以分為很多類，例如，安全漏洞的分析會提取程序中的函數和庫信息，而代碼布局的分析則會關注語法結構的位置。常見的目標還包括無用代碼檢測，是否使用了不安全的 api，識別和監(jiān)視可能被惡意數據污染的值， 競爭條件檢測，確保對數組或內存位置的訪問在預期的范圍之內，等等。
靜態(tài)分析和動態(tài)分析常常同時使用。動態(tài)分析從程序的運行時提取事實數據，檢查并驗證程序的正確性。靜態(tài)分析的一個好處是，通?？梢圆僮鞒绦蛑兴锌赡艿膱?zhí)行分支，而動態(tài)分析只能訪問當前正在執(zhí)行的代碼路徑。然而，動態(tài)分析有關于數據在運行程序內存中的布局和位置的具體信息，而靜態(tài)分析則必須猜測給定的語言、編譯器、操作系統(tǒng)和計算機體系結構將如何表示特定的數據。另外，二者有一定程度的重疊，例如動態(tài)分析和靜態(tài)分析都可以檢測 c 語言中未初始化變量的使用。
靜態(tài)分析在軟件工程中的使用非常普遍，例如 scan-build 是 LLVM 項目提供的一種分析工具，目標是 C、 Objective-C、 C + + 和 Swift; Python 的?black或 Go 的?gofmt?是代碼格式化的工具;??Rust-analyzer是Rust 的模塊化編譯器。
靜態(tài)分析也是其他幾個領域的核心。例如，編譯器設計，大多數編譯器在生成代碼之前和之后運行許多單獨的靜態(tài)分析。實際上，可以將編譯器大體上看作一個靜態(tài)分析工具，這個工具生成的數據包括可執(zhí)行程序以及調試信息。然而，靜態(tài)分析一般指的是可以與編譯器或構建系統(tǒng)一起使用的外部工具。
靜態(tài)分析有著基本的限制，其局限性意味著靜態(tài)分析常常局限于逼近程序的真實行為。盡管如此，一個近似值在實踐中是非常有用的。
靜態(tài)分析的過去
靜態(tài)分析工具是一個程序，通常獨立于程序執(zhí)行機制(如解釋器或編譯器) ，在獨立工具出現之前，靜態(tài)分析是作為現有程序的一部分出現的。
類型推斷算法的第一次發(fā)展出現在1958年，這些算法既可以檢查程序中聲明的值類型，也可以在沒有明確聲明的情況下推斷值的類型。接下來，大量關于分析的研究聚焦于編譯器的優(yōu)化。今天的靜態(tài)分析工具是在20世紀70年代發(fā)展起來的。最早的分析工具是Lint，寫于1978年，1979年伴隨著 Unix 而發(fā)布，用于檢查 c 程序的錯誤。那時的 C編譯器執(zhí)行的正確性檢查遠遠低于現在的編譯器，lint 引入了一些流行的分析方式，例如關于可疑類型轉換的告警、不可移植的結構、未使用或未初始化的變量等等，這些告警現在通常已經是 c 編譯器本身的一部分了。Lint 的影響力巨大，它的名字已經成為許多編程語言靜態(tài)分析工具的一部分。
隨著時間的推移，靜態(tài)分析已經成為了許多軟件開發(fā)方法的基本部分。
靜態(tài)分析的發(fā)展
因為語言之間在語法和語義上有很大的差異，大多數靜態(tài)分析工具都是針對單一語言的。語言的特性對相關分析工具的行為和需求都有著巨大的影響，例如，面向支持字符串運行時代碼求值(eval ())的語言如 JavaScript 和 Python，必須要考慮到這些特性。在沒有 eval ()的語言中，就不需要考慮這一點。另外，針對高級語言的分析不需要考慮低級內存訪問的風險。
如今，有許多方法可以在代碼庫中引入靜態(tài)分析。許多版本控制軟件服務，無論是免費的還是商業(yè)的，都提供了一個集成的靜態(tài)分析工具平臺，當新代碼被推送到倉庫時，就可以按需執(zhí)行分析。靜態(tài)分析工具還與持續(xù)集成服務協助，如果分析工具報告有意外結果，則構建過程就會失敗。使用現有的分析框架擴展，我們可以編寫自己的靜態(tài)分析工具，例如，scan-build 提供了一個 API，使最終應用能夠掛接到 LLVM 的內部進程，并利用 LLVM 的工具鏈來遍歷和分析程序的語法樹。
靜態(tài)分析及其相關語言之間的影響是雙向的，靜態(tài)分析的發(fā)展推動了編譯器和相關工具的發(fā)展，例如Swift語音的出現。Objective-C 內存管理最初是手動引用計數，與 C 編譯器相關聯的靜態(tài)分析可以檢查是否正確保留和釋放內容。ARC的引入，使Objective-C 成為了具有正式內存管理策略的語言，為Swift 的誕生鋪平了道路。類似地，類型推理分析促進了 ML 語言家族的發(fā)展，并將類型推理引入到缺乏類型推理的語言中，例如C ++ 。
靜態(tài)分析的應用
靜態(tài)分析在應用中有幾種方式，最直接的分析方法是在其本地的機器上運行分析。許多流行的文本編輯器和 IDE自動集成了靜態(tài)分析工具，在我們開發(fā)軟件時直接向提供分析反饋。靜態(tài)分析一般集成到開發(fā)和構建過程中。然而，許多靜態(tài)分析是看不見的，例如一個編譯器本身就是一個靜態(tài)分析，數十個單獨的靜態(tài)分析聯接在一起，生成一個可由計算機執(zhí)行的程序。甚至，文本編輯器也執(zhí)行自己的分析，幾乎所有的編輯器都使用了語法高亮，這也是一種靜態(tài)分析，可以產生關于程序中使用的標識符和關鍵字的語義信息。此外，在開發(fā)過程中使用的大部分軟件都是靜態(tài)分析的，包括操作系統(tǒng)乃至 CPU 的微代碼。
并非所有的分析在實踐中都是可行的。代碼庫越大，解析和遍歷所需的時間就越長。因此，靜態(tài)分析和被分析的代碼庫之間是一種軍備競賽。隨著代碼庫變得越來越大，程序員需要更加復雜且高效的分析。
采用靜態(tài)分析工具的一個障礙是要求人們改變自己的行為，以解釋發(fā)現的問題和出現的告警。自從 lint 出現以來，工程師一直在努力消除與誤報結果相關的告警，通常是在代碼中插入”魔法注釋”。然而，手工插入這些指令很乏味，工程師通常會選擇不使用會產生太多誤報的靜態(tài)分析工具。工程師通過仔細配置給定工具來避免假陽性，而假陰性更難發(fā)現，一般通過同時使用多個靜態(tài)分析工具來降低風險。
靜態(tài)分析的未來
現代的靜態(tài)分析工具為代碼庫提供了強大的洞察力。例如，Linux 內核團隊開發(fā)了Coccinelle，用于搜索、分析和重寫 C的源代碼，由于 Linux 內核包含2700多萬行代碼，因此靜態(tài)分析工具對于發(fā)現 bug 以及對其許多庫和模塊進行自動更改都至關重要。針對 C語言家族的另一個工具是 Clang scan-build，它提供了許多有用的分析，并為程序員編寫自己的分析提供了一個 API。
基于云的工具集成了現有的構建和發(fā)布過程，并且可以跨多種編程語言工作。與靜態(tài)分析有關的高級協議也出現了，語言服務器協議(Language Server Protocol)是一套通用的定義，標準化了分析工具與文本編輯器(如 Emacs 和 VS Code)的接口，確保了分析工具可以與工作流集成。同樣，SARIF (Static Analysis Results Interchange Format)為靜態(tài)分析工具生成的輸出提供了一個標準，而以檢測安全漏洞為目標的靜態(tài)分析持續(xù)吸引著大家的關注。
隨著新的平臺、操作系統(tǒng)和編程語言的出現，軟件生產的機制變得更加復雜。事實上，軟件的復雜性增長速度通?？煊诠こ處煿芾磉@種復雜性的能力，這是軟件工程和計算機科學面臨的主要挑戰(zhàn)，而靜態(tài)分析是最有效的武器之一，產生我們這些從業(yè)者應得的知識和洞察力。
【關聯閱讀】