Getting Started with NDepend
Recently Patrick Smacchia reached out to me to suggest I take a look at a code analysis tool NDepend. He gave me a license and I started to use it.
I am a big fan of Resharper. I love it. I will follow Resharper's suggestions blindly. My goal in life is to make the upper right hand corner icon become a green check mark. Resharper's biggest strength is that it gives you almost immediate feedback as you write code.
I am currently learning piano. Running a code analysis tool on a project is similar to recording myself as I play, then listening to it. These tools when ran against some code provide a quick opinion about its state.
Code analysis tools are typically ran against a code base using defined rules. A sample rule could be a C sharp file exceeding 1000 lines. The tool will show you these rule violations ("Class too big") and offer suggestion as to how to fix it.
Resharper does have a code analysis tool. It basically shows you all of the R# warnings and information in a list.
It doesn't provide much information, but it does allow you to click to the line of code. Most of the time when you are at the line of code you can use autofix (ALT + ENTER) to resolve the issue.
What is the difference between Resharper's code analysis tool and NDepend? I only used the NDepend Stand Alone module. I did not install the visual studio extensions. This is what NDepend's dashboard for the same solution looks like:
Features of the NDepend Analysis Tool:
- Provides letters scores and person hour estimates for the project's lifetime and to resolve technical debt.
- Provides an issue difference count since a baseline analysis. Tracking the analysis over time allows you to start from a certain point to address the technical debt and track your progress.
- The results of the analysis over time can be plotted to see trends.
- It can import Test Coverage files and will use the information from those files during the analysis.
- It provides heat maps around namespaces and assemblies.
- In the windows application everything related to the analysis can be drilled down into. This allows you to quickly find information. This may seem overwhelming. Yet once I started clicking around it began to make sense.
- Can export the analysis to an html report. Several examples are included in this blog post.
- Can be ran against non Visual Studio files like dll assemblies.
Tracking Technical Debt over Time
The biggest advantage of this tool is the tracking the analysis over time feature. I am not sure why, but if you start tracking anything you will start improving. If you don't believe me get a bluetooth scale and weigh yourself every morning, in a month you will weigh less.
- The Analysis Ratings over Time
- Problem Patterns emerging on solutions and/or teams. You can then address the problem by providing training and/or resources.
- Where the biggest problems are allowing you to develop a plan as to approach them.
The tool can be integrated into a build/deployment pipeline. You could set this up and export the analysis report to HTML and all of the developers could have access to it.
How can these tools reduce technical debt?
Let's take a look at how to reduce the technical debt using these code analysis tools. We are going to work with this solution which is SqlWrangler. It's a SQL editor windows application. The analysis tools we will use are Visual Studio Code Analysis, Resharper, and NDepend.
First I ran NDepend on the solution.
I then ran Visual Studio Code Analysis on the solution.
I then ran Resharper Code Issues on the solution. The results are here.
I then resolved the issues that Resharper found. That commit is here. You can see from the screenshot that most of the issues were related to using newer features of the framework. There were some naming issues found but most of the issues were involving null checks and string interpolation.
Full Commit History for Branch
I then resolved the issues that Visual Studio Code Analysis found. That commit is here. Most of the issues Visual Studio found were related to naming rule violations on the windows forms.
After addressing these issues I ran NDepend again.
When I addressed the Resharper and Visual Studio issues I changed some of the public methods and classes. NDepend is warning me about it with these issues:
Next I began to address the issues that NDepend had found those commits were:
- Avoid non read only static fields (Commit)
- Avoid methods too big / too complex (Commit)
- Types too big (Commit)
Once I had addressed those I then ran NDepend again. It saw an issue with "Avoid namespaces mutually dependent". I fixed that and some Resharper and Visual Studio issues with this commit. This project doesn't have any tests and I broke something. The snippet menu was under the wrong item. I fixed it with this commit.
And I ran NDepend again and got these results:
The NDepend technical debt has gone down!
I was impressed that NDepend raised issues on the public API changing. Someone out there in the wild might be using an assembly that I don't know about and it is nice knowing about the potential breaking changes.
NDepend's issues are described in the user interface well:
* Rule Name: From now, all methods added should respect basic quality principles * Rule Id: ND1102 * Rule Explicit Id: FromNowAllMethodsAddedShouldRespectBasicQualityPrinciples * Rule Description: This rule is executed only if a baseline for comparison is defined (diff mode). This rule operates only on methods added or refactored since the baseline. This rule can be easily modified to also match methods refactored since baseline, that don't satisfy all quality criterions. Methods matched by this rule not only have been recently added or refactored, but also somehow violate one or several basic quality principles, whether it is too large (too many lines of code), too complex (too many if, switch case, loopsÖ) has too many variables, too many parameters or has too many overloads. * How to Fix Issues of this Rule: To refactor such method and increase code quality and maintainability, certainly you'll have to split the method into several smaller methods or even create one or several classes to implement the logic. During this process it is important to question the scope of each variable local to the method. This can be an indication if such local variable will become an instance field of the newly created class(es). Large switch case structures might be refactored through the help of a set of types that implement a common interface, the interface polymorphism playing the role of the switch cases tests. Unit Tests can help: write tests for each method before extracting it to ensure you don't break functionality. Issues of this rule have a constant 5 minutes Debt, because the Debt, which means the effort to fix such issue, is already estimated for issues of rules in the category Code Smells. However issues of this rule have a High severity, with even more interests for issues on new methods since baseline, because the proper time to increase the quality of these methods is now, before they get committed in the next production release.
As seen in the user interface:
NDepend provides a straight forward path to resolve issues and decrease your technical debt. The issues NDepend raised did get me started in reducing the technical debt and gave me ideas as to how to restructure my application so it's easier going forward.
Summary
The issues NDepend raised for me seemed to be more related to architecture issues versus the other tools. It definitely gave me insight into what to refactor and how to reduce technical debt. The issues it did raise were valid concerns that should be addressed.
NDepend provides tracking of problems over time and gives you detailed analysis of the issues it found. The best case for this tool is to bring it into your build/deploy pipeline and publish the results. It would still be useful in an organization for people to run locally against code bases and email the results. I found value in it as a single developer.
NDepend definitely helped me get started in reducing my technical debt and improving my application. These changes should make adding things to the SqlWrangler solution easier and faster.
NDepend has a fourteen day free trial. You could download it and run it against your solutions to see what it points out. NDepend has decent training videos that provide a great insight into what the tool can do. These take around twenty minutes to go through.
Learn more about:
