是否想清理您的靜態分析實踐？首先，清除導致您難以將精力放在真正關注的問題上的混亂雜事。接下來，通過擴大活動范圍以增加對組織的價值來激發您的實踐。

您的開發團隊是否對靜態分析工具中越來越多的違規行為感到不知所措？您當前的靜態分析配置所產生的高水平噪聲是否使團隊對所有警報（包括那些您認為關鍵問題的警報）不敏感？

無論您使用哪種靜態分析工具，都可以通過以下10種方法來更新現有的靜態分析實現。

技巧1：針對您現在尚未解決的違規行為禁用靜態分析規則

檢查大量規則并不是通過靜態分析獲得最佳ROI的秘訣。實際上，在許多情況下，情況恰恰相反。如果您專注于最少但有意義的一組規則，則靜態分析實際上可以提供更好的結果。

當您執行靜態分析時，就好像您讓經驗豐富的開發人員站在沒有經驗的開發人員的肩膀上，并在編寫代碼時向他提供提示。如果有經驗的開發人員在每幾行代碼中不斷挑剔，那么經驗不足的開發人員將很快不知所措，并開始過濾掉所有好的和壞的建議。但是，如果有經驗的開發人員專注于他知道可能會導致嚴重問題的一兩個問題，那么經驗不足的開發人員就很可能會記住所給出的建議，開始編寫更好的代碼，并且很欣賞收到這種反饋。

靜態分析也是如此。如果您保持它的可管理性和意義，那么您最終將更多地教您的開發人員，并讓他們對流程的重新關注減少。您是希望遵循一小套規則，還是不遵循大套規則？如果您真的不希望開發人員在收到舉報后立即清除違規行為，那么您可能要認真考慮禁用該規則。

技巧2：禁用會引起過多噪音的靜態分析規則

如果特定規則屢次遭到違反，那么現在是重新評估您是否真的要繼續檢查該規則的好機會。過多的違規表示開發人員未按照規則要求的方式編寫代碼。說服他們改變其編碼習慣可能會遇到很大的阻力。

您如何確定解決問題是否值得努力？首先，嘗試記住為什么首先要檢查該問題。您選擇它是因為這似乎是解決您在現場遇到的問題的好方法？作為法規合規工作的一部分？還是僅因為供應商默認啟用了它？供應商通常在其規則說明中為每個規則提供參考。閱讀這些描述可以幫助您確定該規則是否確實適合您的項目和目標。

接下來，查看是否有其他方法可以達到預期的效果。還有其他更具體的規則嗎？有沒有一種方法可以微調規則參數，使其不會經常觸發？（有關技巧6的更多信息）。您甚至可以考慮編寫自己的更合適的規則，或者讓供應商為您創建自定義規則。

如果您在重新檢查了該規則的好處并探索其替代方法后仍然有興趣檢查此規則，請獲取一些開發反饋，以了解遵循此規則可能涉及的內容。然后，您可以使用此反饋來確定要求開發人員遵守此規則是否確實值得。如果看起來工作量很大，卻收效甚微，請繼續執行并禁用該規則。

技巧3：使用抑制功能在特定情況下允許違規

在某些情況下，您可能會遵守規則，但希望在某些情況下允許豁免。例如，也許您有一條規則，要求在代碼中執行一些額外級別的驗證。假設您有一種使用性能關鍵代碼的特定方法，該方法每分鐘被調用數百次，并且您已經驗證了在調用此特定方法之前已執行了適當級別的驗證。或者，假設基于流的分析正在警告您某個嚴重問題，即您認為100％確定無法在集成應用程序中使用它。這是抑制派上用場的地方。

對于需要檢查的情況，抑制是最理想的選擇，但是您不關心在特殊情況下報告的問題。使用抑制，您可以繼續檢查關鍵問題，而不會收到有關故意違反規則的重復消息。如果您不想因違反特定規則而收到錯誤消息，建議您完全禁用該規則（請參見第1點）。

通常，您可以從靜態分析工具GUI，配置文件或源代碼本身定義抑制。在源代碼中定義抑制時：

您確保在您或團隊成員分析該代碼時都應用相同的抑制。

您可以添加解釋每個抑制的代碼注釋，這樣當您或團隊成員查看或修改代碼時，每個抑制的原因總是很清楚。

您可以獲得對在文件，類或行級別強制執行哪些規則的細粒度控制。

通常，您可以禁止違反特定規則，多個規則或特定類別中的所有違規。您還可以將代碼的某些部分從所有靜態分析中免除（在此之后的更多內容中）。

技巧4：停止分析有問題的文件或代碼塊

有時，對某些文件（例如，自動生成的文件或您不打算接觸的舊文件）進行靜態分析只是沒有意義。在這些情況下，應防止對這些文件進行分析。這是確保您的結果不會因您不打算解決的一系列違規問題而混亂的另一種方法。

有幾種方法可以做到這一點。您可以設置路徑過濾器以排除您不想檢查的文件，或僅包括您想檢查的文件。或者，您可以配置工具以跳過包含特定注釋的文件，例如，注釋指示自動生成的代碼。

其他檢查重點包括：

• 添加標記以指示要在其他豁免文件中檢查的特定代碼塊。
• 排除文件中的某些方法，否則將對其進行分析。
• 僅檢查自某個截止日期以來未添加或修改的文件。
• 僅檢查在“截止日期”之后或特定天數內添加或修改的文件。

技巧5：將導致誤報的破壞規則通知靜態分析工具供應商

在基于模式的靜態分析中，誤報是違反規則的行為，當代碼實際遵循規則時會錯誤地報告這些錯誤。例如，如果規則說您擁有未關閉的資源（例如JDBC連接），則實際上該連接是關閉的，那么這是誤報。如果您確實要遵循這樣的規則，那么春季清潔是將其最終報告給供應商的好時機。

請注意，如果您沿著這條路走下去，則需要確定自己所看到的是誤報，而不是簡單地遵循自己不喜歡的規則。開發人員經常將消息稱為“誤報”，因為他們不喜歡該規則，或者感覺不到該規則在這種情況下適用。此類消息不是誤報，在這種情況下，您的供應商將無法為您提供幫助。

但是，如果您可以減少一個顯示特定規則實際上是如何獲得錯誤消息的簡單測試用例，則應該發現大多數供應商在糾正問題方面非常有幫助。

技巧6：自定義靜態分析規則參數以適合您的需求

降低噪聲因子的另一種方法是自定義規則參數。例如，假設您的團隊正在進行Android開發，而您正在檢查一條Android規則，該規則要求“確保窗口小部件的更新時間不要太長。”

使用默認設置時，此規則將識別將小部件設置為每天更新4次以上的代碼。它通過標記將標簽[appwidget-provider]中的元素[android：updatePeriodMillis]設置為小于21600000的數字的代碼來實現。

假設獲取更新的信息對于您的應用至關重要，因此您愿意為更頻繁的更新而犧牲一些電池電量。在這種情況下，您可能只希望每天更新超過8次才被警告。為此，您可以簡單地將“最長最大更新時間（以毫秒為單位）”規則參數從21600000 ms（6小時）更新為10800000 ms（3小時）。

如技巧2所述，如果規則沒有所需的參數，則可以編寫一個新的規則，也可以讓供應商（或顧問）為您編寫自定義規則。

技巧7：將靜態分析規則映射到您自己的術語

您是否已經厭倦了Security 123等同于ACME 3.1指南？Performance 987和Performance 567是否都與您的ACME 5.6準則相關？即使您的工具說線程123的嚴重性為4，您的組織仍認為違反該規則是非常嚴重的缺陷嗎？

如果是這樣，“春季大掃除”是映射供應商的靜態分析規則集以匹配團隊和/或組織定義的不同策略的好時機。大多數靜態分析工具可讓您自定義規則的嚴重性，ID和名稱，以及創建新的規則類別，以便已部署的規則與您自己的編碼策略文檔的內容精確匹配。

如果您的組織執行靜態分析作為合規性工作的一部分，這將使您的報告更加容易。

技巧8：重新檢查并闡明您的靜態分析策略

每個團隊都有一個政策，無論是否正式定義。您最好將過程編成代碼并將其正式化。畢竟，采用正式的政策比不采用書面政策來識別和診斷問題要容易得多。

理想情況下，您希望自己的政策與您當前遇到的問題（和/或致力于預防）直接相關。這樣一來，總體政策和具體實施方式都有著很好的依據。

考慮到這些目標，該政策應闡明：

• 哪些團隊需要執行靜態分析
• 哪些項目需要靜態分析
• 需要什么規則
• 要求達到什么程度
• 何時允許壓制
• 何時需要解決遺留代碼中的違規問題
• 是否附帶違反靜態分析的代碼

技巧9：擴大分析范圍

清除混亂情況后，您將可以使用團隊進行靜態分析了，報告的問題很少，而所報告的問題也得到了及時清理，您可以繼續進行下一步，并擴展檢查范圍。

擴大檢查范圍的一種方法是添加更多對項目和目標至關重要的規則。要對要添加的規則歸零，請考慮：

• 似乎有哪些規則可以防止占用大量團隊資源的現場報告問題？
• 如果您很快就要開始遵守特定于行業或組織的合規計劃，那么哪些規則可以幫助您快速開始工作？
• 首次創建或最后優化規則集時，您最不愿意刪除哪些規則？

增加檢查范圍的另一種方法是檢查其他代碼。如果您最初將靜態分析工具設置為跳過舊文件（例如，跳過開始靜態分析的“截止”日期之后未添加或修改的所有文件），則可能需要考慮移回該截止日期，或者取消一共。

技巧10：自動化！自動化！自動化！

您可以使靜態分析過程自動化的程度越高，對開發人員的負擔就越小，并將他們從他們真正喜歡的更具挑戰性的任務中分散出來。另外，增加的自動化功能將幫助您在整個團隊和整個組織中獲得一致的結果。

許多組織遵循多級自動化過程。每天，當開發人員在IDE中處理代碼時，他或她都可以按需運行分析-或配置自動分析以在后臺連續運行（就像拼寫檢查一樣）。開發人員在將新的或修改的代碼添加到源代碼管理之前清除這些違規行為。

然后，基于服務器的進程會再次檢查簽入的代碼庫是否干凈。該分析可以作為每晚持續進行的持續集成的一部分，等等，以確保沒有任何漏洞通過裂縫。通過這種基于服務器的流程，重要的是避免使用舊的向開發人員發送電子郵件的范例。有效工作流程的一部分是將錯誤消息分發到開發人員編寫代碼的同一UI。電子郵件會強制執行額外的步驟，從而導致違規行為丟失，浪費時間在文件中查找正確的行以及對編碼人員的不滿，他們覺得自己在常規程序之外做了其他事情。

要通過自動化進一步優化工作流程，請考慮：

• 自動將每個報告的問題直接路由給負責的開發人員，并自定義問題優先級以適合您的策略優先級，以確保及時解決最關鍵的問題。
• 集中配置管理，以確保規則集得到一致應用，并且可以隨著優先級和流程的發展而毫不費力地進行更新。
• 盡可能利用自動的“快速修復”重構，以幫助團隊盡快糾正違反規則的情況。