在評估代碼庫的風險時，這不是單個的魔術數字，也不是簡單的“通過/不通過”交通信號燈。風險是多維和多變的，對于不同的組織，風險的衡量方法也有所不同。

您可能已經知道代碼中高風險或“不良”部分的位置–它們是您經常更改的代碼部分，在此處和此處進行了一些小調整，以修復一些看起來無害的小問題，但通常代表分層設計不良的特點。這就是為什么更改現有代碼是在應用程序中引入缺陷的主要原因。

但是我們也知道變化是不變的。您永遠不會完全實現所有功能或第一次都無法正確執行，但是與此同時，當您在現有代碼上分層時，對每個用例和場景的了解就會丟失，復雜性會增加，并且代碼的風險也會越來越大。這些變化為將環境應用于風險提供了關鍵。

與了解風險本身同樣重要的是，了解如何應對風險–如何確定補救措施的優先級，以實現“可接受的風險水平”，同時最大程度地降低對團隊速度的影響。這篇文章僅著眼于：如何評估代碼更改的風險以及如何有效地確定優先級和減輕風險。

確定多元風險

風險不是一個單一的數字，也不是項目級別的“交通燈”（盡管我們確實在UI中使用了易于關聯的交通燈顏色），而是代碼庫的分類以及關于實際和潛在存在問題的指導。見下文：

來自Parasoft的Process Intelligence Engine的餅圖示例，顯示了高，中和低風險代碼的比例。

風險的分類既是多維的又是多元的–您必須將靜態分析，度量，代碼覆蓋率和測試等技術中的質量度量匯總在一起，才能真正理解它。這些技術中沒有一個能為您提供特定維的值，而是為公式提供了值。例如，代碼覆蓋率不是一個好用的數字，因為您可以擁有100％的覆蓋率，但是只有少量的測試可以做有意義的事情–您需要考慮使用代碼覆蓋率告訴您的內容（即，“我的代碼的測試水平如何？”），并通過添加更多數據來進行更有意義的分析。

風險代碼更改氣泡圖的示例說明了最高風險所在。 （可以擴展氣泡以查看驅動分類的指標。）

上面的氣泡圖說明了基于兩個維度的風險分類（也如下圖所示）：

• 維護負擔，結合使用Halstead體積，嚴格的循環復雜性，代碼行數和代碼與注釋的比率來量化代碼的可維護性和可理解性，以及
• 測試缺陷，使用測試次數，方法數量和代碼覆蓋率來量化測試代碼的質量。

測試不良的代碼（即測試缺陷較高）被歸類為高風險（紅色），而經過良好測試和結構良好的代碼（即較低的維護負擔）被歸類為低風險（綠色）。

易變的代碼庫，其中的每項更改都有風險

在開發過程中，您的代碼庫處于不斷變化的狀態，每行更改的代碼都會帶來未知的風險。它會破壞基本功能嗎？它會引入安全漏洞嗎？信息越少，風險越大。在之前的文章中，我們討論了變更對測試的影響，以及如何智能地使用代碼覆蓋率來預測測試資源需要集中在哪里。但是，即使覆蓋范圍和測試范圍不斷擴大，隨著時間的流逝，仍然存在更多的風險。

代碼庫中的更改為我們提供了第三個也是最重要的風險維度：時間。時間不是傳統意義上的時間，而是與構建及其之間的變化相關的時間。專注于代碼庫在內部版本之間已更改的部分，這使我們能夠集中精力處理風險最高且最相關的代碼，因為該團隊目前正在代碼庫的這一部分中工作。

質量債務的負擔會拖慢您的速度嗎？

重用和遺留代碼已經有其自己的負擔，特別是對于安全性。如果沒有足夠的檢查來維持或改善質量基準，則每條提交或修改的代碼行都會加重債務。要擺脫這種債務，就像任何債務一樣，需要關注并致力于減少債務。另外，就像任何債務一樣，除非您知道花在哪里，否則怎么會知道如何儲蓄？

一旦確定了具有最高風險和最高優先級的代碼，就還需要考慮減輕風險所需的工作量。這是第四個也是最后一個方面：質量債務。在上面的氣泡圖中，質量債務用氣泡的大小表示–氣泡越大，需要解決的已知問題越多。在我們的示例中，質量債務是高嚴重性靜態分析違例（包括違反代碼度量標準的設置閾值）和測試失敗的組合，并通過邏輯代碼行數進行了標準化（請參見圖3）。

這些出色的質量任務的匯總為降低代碼風險所需的相對工作量提供了指導。

但這不是我衡量風險的方法！

并非每個組織都將遵循相同的質量實踐或在計算尺寸時要考慮哪些因素。您需要能夠配置和創建自己的風險定義。

該博客中的示例可供Parasoft市場上的用戶使用，使您可以立即使用它，并進行擴展和修改以滿足您的特定需求。從示例開始，您可以自定義靜態分析，指標閾值和風險分類以適合您的組織。

結論

通過適當的安全措施平衡預算，進度和質量目標，同時滿足客戶需求，這是一個艱巨的任務，每一個環節都有風險。但是，質量實踐和流程智能的自動化可幫助您將資源最佳地用于哪里。了解風險的根源以及每個代碼的更改方式如何影響基線質量和安全性，可以減少開發方程式中的許多未知數。正確地關注質量和安全債務是可以克服的。