靜態代碼分析方法

Question

您將使用什麼方法與靜態代碼分析工具？

何時何地運行分析？多頻繁？

如何在日常構建中將其集成到持續構建環境？只有每晚？

Answer 1

如果我在新的代碼庫上使用，那麼我將它們設置爲我想要的。如果我在現有代碼庫上使用它們，我會分階段啓用消息，以便報告特定類別的問題。一旦清除了特定類型的消息，我添加下一個類別。

我把靜態分析工具看作是編譯器的一部分。每個開發人員在每次構建時都會運行它們。如果可能的話，我也會把它們當作編譯器警告來對待 - 就像錯誤一樣。這樣，帶警告的代碼根本不會將其放到構建服務器上。如果您在特定情況下無法關閉警告，則會出現問題......並且只能通過協議關閉警告。

Answer 2

我的經驗是，一般來說，靜態分析應該在開發過程早期使用，最好（或理想情況下）在單元測試和代碼簽入之前使用。代碼審查過程中也可以使用來自靜態分析的報告。這使軟件開發人員能夠開發出健壯的代碼，並且在某些情況下編寫可以通過靜態分析工具更加準確地分析的代碼。

早期使用的挑戰是軟件開發人員必須接受充分的培訓以使用靜態分析工具並能夠有效地對獲得的結果進行分類。這樣，他們可以採取具體步驟來提高軟件的質量。否則，使用該工具減少或標記的問題將被忽略，靜態分析的使用會隨着時間的推移而減少。

實際上大多數開發組織在開發過程的後期使用靜態分析。在這些階段，質量或測試工程師使用靜態分析工具。在許多情況下，它與構建系統相結合，以產生質量指標並提供有關軟件安全性和可靠性的指導。但是，如果識別的問題累積並跨越多個代碼組件，則所有問題將被修復的可能性將會降低。因此，一般來說後期使用靜態分析可能需要更多的時間和資源來解決已確定的問題。

Answer 3

在檢查服務器中的源代碼之前，同時使用靜態分析工具建立代碼審查任務（由另一個開發人員進行同行代碼審查）也可能是一個好主意。所以這將有助於提高代碼質量並防止無用代碼行成爲一天無用的代碼。