專案越來越大，也越來越難一眼看出專案潛在的品質問題，這時必須利用一些第三方工具幫我們進一步分析 .NET 專案 (或整個方案)，而這套 NDepend 正是一個極其優異的產品，對於一些多人開發的專案或是有點龐大或複雜的專案，都能利用 NDepend 幫我們做品質分析，甚至於可以跟 TFS 或其他 CI 整合進開發流程，透過自訂規則確保專案在開發的過程中都能有效維持一定的程式碼品質。
該產品下載之後是一個 zip 壓縮檔，免安裝，直接解壓縮就能立刻執行
開啟之後可以先看 Getting Started 中的影片學習如何操作使用，我個人習慣將 NDepend 整合進 Visual Studio 2010 開發工具中使用，所以我會點選 Install Visual Studio AddIn 這個按鈕將 NDepend 整合到 Visual Studio 2010 開發工具之中。
接著我們開啟現有的專案或方案檔，只要專案能成功編譯，就可以馬上利用 NDepend 幫我們分析程式，如下圖可以在 Visual Studio 2010 的 NDepend 選單選取 Attach new NDepend Project to current VS Solution 建立新的 NDepend 分析專案：
他預設會幫你選進整個方案預設輸出的組件，如果不夠的話可以點選 Add .NET Assemblies of some Visual Studio Solution 按鈕再加入額外專案的組件進來。按下 OK 按鈕後就會立即開始分析所有組件。
由於加入 NDepend 專案會修改 *.sln 方案設定檔，因此加入會被要求重新載入方案：
接著分析完畢後會開啟一份含有整個專案完整分析的網頁報告，這份報告的內容十分的詳盡且豐富。
備註：若想直接看現成的報表樣式，可以到官網的 Sample Reports 網頁即可立即查看報表的互動界面。
這份分析報告包括了有：
- 四種不同的組件分析圖表，用圖表的方式告訴你整體專案的相依性、複雜度、抽象性、穩定性等。
- Dependency Graph
- Dependency Matrix
- Treemap Metric View
- Abstractness vs. Instability
- 與該應用程式相關的各式統計數據，給你一個概略的應用程式資訊。
- Application Metrics
- Application Statistics
- Assemblies Metrics
- Namespaces Metrics
- Types Metrics : Code Quality
- 程式碼品質的分析報告 (CQL Rules)，這裡提供了 82 條精選的程式碼規則用來分析原始碼品質，並且依據不同的分類告訴你哪裡的程式可能有問題。
- 程式碼差異比對 (Code Diff)，此功能可以讓你比對不同時期所編譯的組件版本到底有什麼差異？有沒有公開的方法或屬性名稱被改變？（註: 如果你的專案是開發 API 給其他人用，變更公開的成員名稱可能會導致使用該 API 的程式掛掉）以下是透過 CQL 分析的類型。
- API Breaking Changes: Types
- Methods added
- Methods where code was changed
- Public Types added
- Types added
- Types where code was changed
- Namespaces added
- Namespaces where code was changed
- Third party Types that were not used and that are now used
- Third party Methods that were not used and that are now used
- 程式碼覆蓋率 (Code Coverage)，匯入 Visual Studio 2010 的 Code Coverage 統計資料進來。
- 未使用的型別 ( Dead Code )，告知你有哪些程式碼完全沒有被參考或使用。
- Potentially unused types
- Potentially unused methods
- Potentially unused fields
- 組件建置的順序 ( Assemblies Build Order )
- 提供 NDepend 分析過程中的完整記錄 ( Analysis Log )，這些記錄有時候還蠻有價值的，我之前從這個分析記錄中找到過幾個專案的問題來源。
除了這份報告外，所有的資訊也都可以在 Visual Studio 2010 中取得，不僅僅是透過 NDepend 視窗可以取得資訊，在原始碼視窗中按下右鍵也隨時可以取得與該型別相關的分析資訊。
最常用的不外乎是 CQL Query Explorer 了，這個視窗可以幫你快速的找到整個專案中有問題的程式碼，以下圖為例，我開啟 .NET Framework Usage \ System 分類發現有幾個警告的訊息，以下圖 Do not raise too general exception types 為例，他告訴我整個方案中有 72 個地方使用了太過於一般的例外型別，也就是程式丟出例外時直接使用 Exception 類別。
我點選 Do not raise too general exception types 之後會開啟另一個 CQL Query Edit 視窗，直接幫我篩選出整個方案中包含這項警告的程式碼位置，直接雙擊方法名稱就能到達目的地，也可以立即修正有問題的程式碼。
這裡的 CQL (Code Query Language) 是 NDepend 獨創的一個類似 T-SQL 的程式碼查詢語言，開發人員只要有 T-SQL 撰寫經驗，要能閱讀 CQL 語法應該不是太困難，以上圖為例我們來講解一下這段 CQL 到底幫我們查出了什麼資料：
WARN IF Count > 0 IN SELECT METHODS WHERE
( ( DepthOfCreateA "OPTIONAL:System.Exception" == 1 OR
DepthOfCreateA "OPTIONAL:System.ApplicationException" == 1 OR
DepthOfCreateA "OPTIONAL:System.SystemException" == 1 )
AND !IsConstructor )
整段語法你看不到 "FROM" 子句，因為預設就是查詢的資料來源就是你的整個方案檔中的所有組件，這段 CQL 語法你可以從第一行的 "SELECT" 開始讀起，我們選的是 METHODS 代表我們要撈出所有類別中的方法，然後 "WHERE" 子句就包含了一些似懂非懂的語法了，你仔細閱讀一些字面的意思就能理解其用途 ( 如果無法理解也可以到 Code Query Language 1.8 Specification 查詢相關說明 )，這句的意思是如果在方法中建立 System.Exception、System.ApplicationException 或 System.SystemException 等例外類別，以及該方法不是建構子 ( !IsConstructor ) 該方法就會被選出來。而 WARN IF COUNT > 0 IN 是為了告知 CQL Query Explorer 在特定條件下 ( COUNT > 0 ) 會出現警告 (Warn) 提示。
其實 CQL 撰寫可以非常的千變萬化，因此你的團隊若在定義一些命名風格時，也可以在 CQL Query Explorer 定義自己專屬的 CQL 語法，漸漸的把自己的開發經驗累積成一條一條的 CQL 語法，這就是你的專屬程式碼品質知識庫，如此一來日後在 Code Review 的過程就會越來越輕鬆自在！
NDepend 這工具博大精深，我至今尚未完全瞭解所有功能，不過這工具卻幫我分析過許多專案，建議到官網取得更進一步的文件資料。
後記
開發工具與開發時期的資訊已經越來越多，建議各位開發人員所使用的電腦螢幕是多多益善、越大越好，否則做起事來還真的會礙手礙腳的。 :-)
相關連結