I received a free copy of NDepend a few months back, which was timed almost perfectly to the start of a project I was going on to. However before I get to that, what is NDepend?
NDepend is a static analysis tool, in other words it looks at your compiled .NET code and runs analysis on it. If you know the Visual Studio code analysis or FxCop then you are thinking of the right thing - except this is not design or security rules but more focused at the architecture of the code.
Right back to the field, the new project has gone through a few phases:
- Fire fighting - There were immediate burning issues that needed to be resolved.
- Analysis - Now that the fires are out, what caused them and how do we prevent it going forward.
- Hand over - Getting the team who will live with the project up to speed.
Right, so how did NDepend help me? Well let’s look at each phase since it has helped differently in each phase.
Note: The screen shots here are not from the project, since that is NDA - these are from the application I am using in my upcoming Dev4Dev’s talk.
Fire Fighting
The code base has over 30000 lines of code and the key bugs were very subtle and almost impossible to duplicate. How am I supposed to understand it quick enough? Well first I ran the entire solution and I start looking at it in the Visual Explorer:
The first thing that it helps is dependency graph in the middle which visually shows me what depends on what, not just one level but multiple levels and so on a large project it could look like:
Now that may be scary to see, but you can interact with it and zoom, click and manipulate it to find out what is going on.
For fighting code I could sit with the customer people, and easily see where the possible impact could be coming from. So that gets it down to libraries, but what about getting it down further? Well I can use the metrics view (those black squares at the top of the image above) which I change what they mean - so maybe the bigger the square the bigger the method, class, library etc… so using the logic that at some magical point (about 200 lines - according to Code Complete by Steve McConnell), the bigger the method the more likely that there is bugs in it. I could use that to find out where to spend time looking for the problems first, which meant that the problems were found quicker and resolved.
Analysis
Right now that the fires were over moved on to analysis to make sure that it never happened again - well when a project is analysed by NDepend it produces an HTML report with the information above but also a lot of other information like this cool chart which shows how much your assemblies are used (horizontal axis) vs. how a change may effect other parts of the code (vertical axis):
And that is great to see what you should focus on in refactoring (or maybe what to avoid), but there is another part which is more powerful and that is the CQL language which is like SQL but for code so you can have queries like show me the top 10 methods which have more than 200 lines of code:
WARN IF Count > 0 IN SELECT TOP 10 METHODS WHERE NbLinesOfCode > 200 ORDER BY NbLinesOfCode DESC
Some of these are in the report, but there is loads more in the visual tool and you can even write your own. I found that I ended up writing a few to understand where some deep inheritance was getting used when it came to exception handling specifically. In the visual tool this is all interactive too, so when you run that query it lights up the dependency tree and the black squares so you can easily see what is the problem spots and identify hot spots in the code.
Hand Over
Moving the final stages, I have to get the long term guys up to speed - how do I do that in a way they can understand without going through the code line by line? Easy, just pop this on a projector and use it as your presentation tool, with a custom set of CQL’s as slides or key points to show. What makes this shine is that it is live and interactive so when taking questions or doing a discussion you can easily move to other parts and highlight those.
All Perfect Then?
No, there are some minor UI issues that are more annoyance than anything else (labels not showing correctly in the ribbon mode or the fact that you must specify a project extension), but those are easily overlooked. The big problem is that this is not something you can pick up and run with - in fact I had tried NDepend a few years back and decided it wasn’t for me very quickly. If it wasn’t for a lot more experience and having an immediate need which forced me over that steep initial learning curve then I would never have gotten how powerful it is. That also brings up another point, the curve is steep - and if you aren’t used to metrics and thinking on an architectural level then this tool will really cause your head to melt and so this is not a tool for every team member, it is a tool for the architects and senior devs in your team to use.