.NET效能調優之二：使用Visual Studio進行程式碼度量

.NET效能調優系列文章

系列文章索引

• .NET效能調優之一：ANTS Performance Profiler的使用
• .NET效能調優之二：使用Visual Studio進行程式碼度量
• .NET效能調優之三：YSlow相關規則的調優工具和方法

使用Visual Studio進行程式碼度量

在這篇文章裡，暫且拋開代碼、資料庫和網路的最佳化，從軟體程式碼度量的角度來看看其對.NET效能調優的作用。

當軟體項目異常龐大的時候，通過簡單的CodeReview進行軟體複雜度估量和可靠性評測已經變得不太現實，還好有軟體來完成這些事情。降低軟體的複雜度也會對效能調優帶來很大的協助。

在Visual Studio 2008前，進行程式碼度量還要藉助第三方的一些工具，如devMetrics、C# Source Code Metrics等，而從Visual Studio 2008開始微軟就在裡面整合了程式碼度量的工具。

點擊Visual Studio的“分析”菜單，可以看到度量工具能夠針對當前項目或者整個解決方案進行程式碼度量。

下拉式功能表的上面還有和第一篇文章裡介紹的ANTS Performance Profiler類似的代碼效能分析工具，簡單使用了下，發現當要查看.NET架構內部實現的耗能時是看不到的，其他的功能基本能滿足需求，感謝園友風雲的提醒。

短暫運行後，就可以看到分析的結果。

這裡列出了所有能計算出來的列，下面是MSDN對計算結果值意義的說明。

1. 階層：按照項目-命名空間-類-屬性/方法進行逐級細分，所以可以只針對某一個方法查看相關的程式碼度量值。
2. 可維護性指數：計算一個介於 0 和 100 之間的指數值，表示維護代碼的相對容易度。 值越大表示可維護性越好。 彩色表徵圖的等級可用來快速識別代碼中的故障點。 綠色等級介於 20 和 100 之間，表示代碼的可維護性良好。 黃色等級介於 10 和 19 之間，表示代碼的可維護性中等。 紅色等級是介於 0 和 9 之間的等級，表示可維護性低。
3. 循環複雜度：衡量代碼在結構上的複雜程度。 通過計算程式流中的不同代碼路徑數而建立的。 具有複雜控制流程的程式需要更多測試才能實現良好的程式碼涵蓋範圍，並且不容易維護。在某些情況下，Visual Studio 2010 中的方法的循環複雜度計算與早期版本有所不同，具體參見Visual Studio 2010 在代碼複雜度計算方面所做的更改。
4. 繼承深度：指明擴充到類階層根的類定義的數目。 階層越深，則越難瞭解特定方法和欄位是在何處定義或/和重新定義的。
5. 類別結合程度：通過參數、局部變數、傳回型別、方法調用、泛型或模板執行個體化、基類、介面實現、在外部類型上定義的欄位以及特性修飾來衡量與唯一類的耦合程度。 良好的軟體設計要求類型和方法應具有較高的內聚力和較低的耦合。 耦合較高表示設計難以重用和維護，這是因為它與其他類型之間存在許多依存關係。
6. 代碼的行數：指明代碼中的大概行數。 該計數基於 IL 代碼，因此並不是原始碼檔案中的確切行數。 計數過高可能表示某個類型或方法正在嘗試執行過多的工作，應予以拆分。 還可能表示該類型或方法難以維護。

最需要關注的可能就是循環複雜度和類別結合程度兩個度量值了，以使得程式保持高類聚低耦合；如果循環複雜度過高，應該將函數拆解，這樣在進行效能調優時可以逐個擊破，維護起來也比較容易。

結語

希望在探討程式效能調優時別忘記先將軟體的複雜度和可維護性降低一些，這樣在遇到複雜的效能最佳化問題時，思路才能足夠清晰，可以將精力集中在細分後的程式碼片段上，而不是有太多的代碼噪音來幹擾邏輯的梳理與思考。

所以這個系列文章先將這部分內容拿到了第二篇裡來和大家一起探討了。

文章有所疏漏和要補充的，請留言一起討論，也請關注後續的相關文章。

如果文章對你有點協助，推薦一下吧，謝謝