如果你問開發團隊，他們的主要目標是什么，三個最常見的答案可能包括：

• 編寫無錯誤的代碼。
• 符合設計規范。
• 規避安全問題。

那么，團隊如何審查代碼以確保這三個主要目標都得到滿足?

答案很簡單，是代碼分析。但它應該是靜態代碼分析?還是動態代碼分析?或者兩者結合?

不妨看看靜態代碼分析和動態代碼分析如何在開發中發揮重要作用，以及它們的差異如何有助于規范代碼。

靜態代碼分析和動態代碼分析有何不同?

靜態代碼分析檢查代碼，以識別邏輯和技術中的問題。動態代碼分析則運行代碼和檢查結果，這還需要測試代碼可能存在的執行路徑。

即使采用最基本的方式，當開發團隊測試代碼時，他們是在執行動態分析。而當程序員審查代碼時，則是在執行靜態分析。無論使用哪種工具，開發人員和程序員都在執行分析，最終有助于創建更好的代碼。

靜態代碼和動態代碼本身都不是理想的選擇，這意味著團隊應優化兩者。開發團隊不能將靜態代碼分析和動態代碼分析視為非此即彼的關系，而是應將它們視為互補和共生的關系。

代碼審查類似靜態分析

如果由于某種原因，團隊決定略過靜態代碼分析，那其實意味著團隊計劃不審查代碼。代碼審查和靜態代碼分析好比是相關的術語。代碼審查有助于發現代碼問題，無需進行費時又費錢的動態測試。在代碼審查環境下進行的靜態代碼分析是開發和維護優秀軟件的第一步，也是最重要的一步。

大多數靜態代碼分析是使用旨在評估代碼，查找錯誤或不推薦的技術和實踐的工具完成的。將靜態代碼分析視為代碼審查要素的組織可能會先進行正式的代碼審查，然后運用靜態代碼分析工具，最后借助選擇的代碼審查流程審查結果。

如果機構決定先與程序員和導師一起審查代碼，它們可能會考慮先使用靜態代碼分析。這種方法可能會揪出至少 85% 的代碼錯誤，為專家省下識別錯誤的寶貴時間。

靜態代碼分析和審查特別適合快速開發和 GitOps 環境：在這種環境下，常常對單個組件進行更改。比如說，如果軟件設計適當地隔離了組件行為，靜態分析可以揪出大部分代碼錯誤。

為什么進行動態分析呢?

簡而言之，靜態分析無法揪出每個代碼缺陷。

解決復雜的多組件應用程序中的問題時，靜態分析尤其受到限制。當您想要衡量性能或測試用于擴展及(或)負載均衡的策略時，它幾乎失去價值。面對這些限制，動態代碼分析就有了用武之地。

協調動態分析和靜態分析

正如開發團隊已經經常使用靜態代碼分析——即使這種分析不是正式規定或管理的，他們也使用動態代碼分析。常規軟件測試和運行軟件以驗證修正版或驗證初始實現機制是動態代碼分析的幾種形式。

因此，這不是靜態代碼分析與動態代碼分析兩者擇其一的問題。團隊可能已經使用了兩者。問題變成了如何有效地使用兩者。

靜態代碼分析最好與代碼審查結合使用。動態代碼分析適用于某種形式的自動化測試和測試數據生成。

團隊應先將動態代碼分析的重點放在靜態分析可能無效的方面，比如組件性能、應用程序性能、應用程序邏輯、安全驗證和跨組件邊界。比如說， Redgate SQL Data Generator 和DTM Data Generator (僅舉幾例)等自動化測試數據生成工具可模擬應用程序在滿負荷下的操作、驗證所有邏輯路徑，并測試這些點是否存在安全漏洞。一些機構可能已經在使用這些工具，但重要的是，它們可以用來測試靜態分析極有可能遺漏的特定方面。

使用唾手可得的工具和實踐很容易實現性能和負載測試的自動化。面對任何形式的生成數據自動化測試，設置邏輯和安全驗證比較困難。團隊需要強調測試設計，并認真選擇具有特定字段值約束的數據生成工具，以運行識別潛在問題的測試。在安全驗證方面，團隊應將測試數據范圍值擴大到正常操作之外，以確保它們不會帶來潛在的問題。

靜態代碼分析與動態代碼分析之爭表明了許多注重單個步驟而不是整個過程的開發策略存在缺陷。靜態代碼分析和動態代碼分析都扮演重要的角色，它們都是整體的開發和部署流程的一部分。少了任何一方，另一方都不可能獨立完成。

原文標題：Static and dynamic code analysis: Complementary techniques，作者：Tom Nolle