Visual NDepend Blows My Socks Off!

NathanZaugg — Fri, 27 Feb 2009 00:10:23 GMT

I’m not easily impressed by even the best of software. There is usually some little thing that ruins my user experience. I tell you this so you know that what I say next is something special. Visual NDepend is AWESOME! Everything meet or far exceeded my expectations! If you are not yet running this software, you should be! This is not one of those ‘nice to have’ pieces of software like you might thing. This is a must have! If Microsoft was smart they would do everything they could to package this in with Visual Studio 2010.

What does it do? It’s hard to answer that question in a paragraph or two. The basic answer is that it gives you a set of different representations of your software in such a way that you can understand the architecture and complexity. This can be a huge help before undertaking large refactor efforts. It also gives you an idea or the quality of the code based off of some metrics. This quality score can be a really good indicator of wither your code is going to be maintainable and if it’s not it can help you get it there. Before I go through the quick walkthrough of the software it’s self I’ll just say this – If you’re not paying attention to code metrics and the maintainability of the code from the earliest stages of development your likely not going to develop code that is easy to maintain. And as you probably know, software maintenance is usually more than 3/4ths the cost of the software lifecycle. Therefore, if you can get a build process established early and use a tool like NDepend to keep a close watch on some important metrics I can guarantee you will be creating much higher quality software than you would have otherwise.

Installation Experience

This is the best kind of install – you simply unzip the files. I bet you didn’t think I would do a whole section on install when there is nothing to the install. I suppose if it were any other product there would be a lot under this section.

Analyze a Project

The user interface is very intuitive. I installed integration with Visual Studio 2008 and .NET Reflector with minimal effort and started to analyze my assembly.

It took a while to analyze but this particular assembly is quite large! It also pulls in any referenced assemblies so the graph can be complete. It allows you to specify multiple assemblies just in case you have sets of assemblies in the same project that have no direct relationship. In this case I had a WCF service that would need to be added separately as it’s technically not a direct dependency. Once the analysis is complete it’s INFORMATION OVERLOAD!

Results

There are six or seven main results to view. The most obvious is the bubble chart at the top. This gives you a visual representation of different aspects of the code. For example it’s currently set to Method level and the metric shown is number of lines of code. the larger the bubble, the larger the method is in relation to the others. I can select from Method, Field, Type, Namespace or Assembly. In addition there are 11 different metrics that you can plot in the bubble chart.

The next thing you notice is the dependency graph. Unfortunately this project doesn’t have a dependency graph like in my other blog post. Visual Studio makes it really tough to make circular dependencies but it is possible to create them if not all of your projects are loaded into the same solution. And as I said in the other post, circular dependencies are very bad! It’s also good to know what references what. You might be surprised to see what kind of references get worked in over time. On a recent project the data layer code kept working it’s way up to the UI even though it didn’t belong there.

The next section is the code metric-centric part. This is my most favorite portion of the results generated and can be a real good indicator of how maintainable a codebase is. Of course it’s impossible to avoid all complexities in software so you probably can’t have a perfect score with every project but you can use this information to figure out what kinds of habits you have that contribute to un-maintainable code. As you can see from the image below when you select a metric it is highlighted in the bubble chart. In fact, all of these reports are “active” so anything that is relevant to another will be indicated. By the way, this application has amazing performance. I’m pretty sure it’s using WPF under the hood.

Another really cool feature is the Dependency Matrix. This takes some practice to use but it helps identify which pieces of which assemblies access pieces of other assemblies. Again, great for refactoring efforts and a good indication of how an application is put together. You may have to stair at the image below for a while to figure out what it’s trying to tell you but after a while it makes perfect sense.

Last, but certainly not least is the comprehensive report compiled into HTML. This is the kind of thing that I’d love to see emailed to me each day, so I hope it’s easy to put this into a build process. The report is awesome! My favorite part of the software and I really like this software. Below is the screen shot of the table of contents that is generated at the top.

The only feature I didn’t get a chance to try is code coverage results. I would have loved to see that in action! Too bad I don’t have a project with very good code coverage results and I’d be embarrassed to find out anything in detail about my code coverage. Of course code coverage isn’t everything but it is a useful tool when taken into context and can be made more useful with nDepend.

Overall, I would give this software very high marks! I can’t wait to make this part of my build process! It is worth the time and money!

Avoiding Circular Dependencies

NathanZaugg — Mon, 09 Jun 2008 21:45:06 GMT

The term "circular dependency" may be foreign to some programmers (especially if you do Java as it is a pretty common practice). However, anyone who has done some scripting for a referential database knows that you have to run scripts in a certain order. Running scripts out of order causes errors when you run. The interesting trick is that if you run that same incorrectly-ordered DDL script again and again you will eventually get it to run without errors. If you were unaware of the order being incorrect and thought to yourself in that moment "Stupid database!" then this blog post is for you!

What is a circular dependency?

It is simply two libraries that use each other (either directly or indirectly) as shown below:

Figure 1: Circular Dependency

Figure 2: Complex Circular Dependency

The complexity of a circular dependency may vary. If you are using Visual Studio and have all of your projects loaded into a single solution AND you add Project References (Right click on project -> Add Reference -> Projects Tab -> {Project Name}) then the IDE will not allow you to create Circular Dependencies. In fact, this is a good practice as Visual Studio will ensure the correct build order.

Why are circular dependencies bad?

Just like our Database example above, a circular dependency makes it so you can not guarantee that your application has the latest code. That is a big deal! Here is why:

I make changes to Application 1 (in Figure 2)
I build my project, The changes I made in Application 1 may or may not have gotten into Application 2 (depending on build order). It may have taken a copy of the compiled code that was left over from the last time I built.
Application 2 depends on this new functionality to provide services to Application 3; This functionality will not work correctly with this build.
Application 3 may or may not depend on these same services to provide back to Application 1

As you can see in this scenario, there is no such thing as a "correct" build order when there are these circular dependencies. The only way you can arrive at the correct version of the code is to build it as many times as there are nodes in our circle. That would mean for Figure 1 that we would need to build twice and three times for Figure 3. Some of these dependencies can get really ugly! Here is some actual code running in an actual company that I did analysis on some time ago using a tool called Structure 101.

How do I fix circular dependencies?

There are some steps to take to solve even the most complex tangles! They all involve refactoring your code though.

Refactor common code into a "base" dependency; I usually call this "Common" (figure 3). BEST SOLUTION
Remove code that is unused. In the tangles shown above many of them are using deprecated/unused code.
Duplicate the sections of code used. This should be seen as a last resort but given the choice between code duplication and circular dependencies, I take code duplication ever time!

Figure 3: Refactor a Common

Summary

There are two kinds of design concepts for nTier (and other types of architectures as well) called Logical Layout Design and Physical Layout Design. The Logical Layout is simply that your software occupies the same project/package but leverage different classes. In contrast Physical Layout Design forces each tier to be separated into different Projects/Packages. So long as we are careful to manage the dependencies between these packages from the start this is the preferable way to code. While the logical layout does not suffer from the dependency problem eventually you may wish to break these classes apart and find that there are a lot of inner-dependency that should not exist simply because they occupied the same project. Remember to keep it clean!

Search results matching tags 'Tools' and 'Testing'