One thing in common with developers and infrastructure professionals is that they often turn to monitoring and analysis tools in times of strife rather than incorporate them into their daily routine. If the monitoring and analysis tools are bought out only when there's a problem, then you're often confronted by the fact that no one really knows them well enough to interpret what they're telling you.
That's why I'm spending some time getting to know NDepend now, before I really need it.
NDepend is a tool designed to perform static analysis on a codebase and provide you with a large set of interesting code metrics. It's a tool which offers an incredible amount of value and insight, but it's also one which is going to put a lot of people off by the sheer amount of data it has to offer. One of the keys with metrics and statistics is knowing how to interpret them – NDepend does an incredible job of presenting you with all the data you could possibly need to know about your projects, however the job of understanding how that data actually relates to your day to day development and maintenance is mostly up to you.
The best way to get started with NDepend is to download a copy, open up a project that you know well, and start looking about the UI. There are some great screencasts available to help you get started, and watching some of them is probably a good idea. Another great resource is this podcast from Scott Hanselman – although it's a couple of years old, it's a great way to get an overview of how you could use this product in real world situations, as well as explaining some of the important UI features and common terminology.
Once the analysis has been run against your code, you are presented with a number of different UI elements allowing you to explore the results, as well as an XML report which opens in a browser offering you a static summary. The visual elements offer you different ways to explore your code however you also have the option of running custom queries written in CQL, which is NDepend's own query language. Visual elements include a class browser (used to.. well, browse classes!), a Dependency Graph (which is a very useful visual overview of your project and it's dependencies), a dependency matrix, and a Metrics treeview (which has a similar UI to hard drive size reporting tools such as SequoiaView). Each of these visual elements has a wealth of options allowing you to change how the metrics are presented to you depending on your requirements.
The CQL queries list comes with some pretty useful precreated queries covering areas such as code quality, design, performance, usage of .NET framework, naming conventions to name but a few, and of course you can write your own. When you click on a query or a group of queries, the resulting/offending areas of your code are highlighted on the Metrics treemap (if it's visible), as well as being displayed in the CQL Query results list. Clicking on a specific item from the results list will also highlight where that single item lives in the Metrics treemap.
Queries can range from simple things such as "Show me methods taking more than 10 parameters" or "Show me the 10 methods with the most lines of code" through to much more complex ones. It's worth taking some time to browse through the ones which ship with the product, as they're great examples of the power of the CQL language, as well as being queries that you're likely to want to run against your projects.
There's simply too much in the UI for me to even pretend to attempt to run through it all. You really need to download it and use it to get an idea of just how much this tool offers you.
I think different teams and developers will find different ways to use NDepend. You could choose to use it only for a milestone reviews or releases, for troubleshooting, prior to any significant refactoring, daily as part of a build process (as the Professional version of NDepend allows you to run CQL queries as part of your CI process), or all of the above. For me, I'm looking to use it as a semi-regular sanity check for what I'm doing, but also to analyze potential codebases which I may "inherit" so I know what I'm dealing with right off the bat. I found that just taking 5 minutes to look at the dependency graph was a great way to get an overview of a project, where the areas of complexity are, as well as what third party assemblies and elements of the .NET framework are being used. It's the sort of graph which is going to make code smell stand out pretty quickly.
There are a couple of things I noticed, but haven't had time to use in depth yet. The most intriguing one of those is the option to compare 2 versions of a code base. It strikes me as being something which would be incredibly handy - I've done it before for a small section of a codebase using Winmerge (an open source merge tool), which did the job, but I can imagine that if you were dealing with a larger codebase that you'd want to be using NDepend instead.
NDepend is a tool which is a valuable addition to any developer's toolkit. You're going to want to spend a bit of time getting to know it, but it'll be time well spent.
Link: NDepend
Link: Hanselminutes episode #66 - Static code analysis with NDepend
Link: Patrick Smacchia's (NDepend's author) blog
Link: JD of Mindscape's blog on NDepend