NDepend to the rescue

Some time ago I inherited a rather complex and intimidating codebase that I wanted to get my head around to. I already made some minor tweaks in the past, but without fully understanding it. The time has come to refactor some crucial parts in this application. In comes NDepend

NDepend was known to me for many years as I used the free version in the past on and off on smaller projects. It basically analyses the hell out of your code and provides some really compelling statistics and graphs. The feature list is impressive and the latest (beta) version integrates fully with Visual Studio.

Patrick Smacchia was kind enough to provide me with a free license to his amazing product. But sadly enough I did not find the time to play with it that much. Until now that is.

On my particular project, I contemplated for a long time on coming up with a mass amount of unit tests to support the code. But doing so after the fact is not only boring, but also not very effective if you don’t fully grasp the inner workings of it. The change I had to make needed me to better understand the code.

After I ran NDepend, I was greeted with a marvelous report that provided me with insights I had never seen before. Especially the “Assemblies Abstractness vs. Instability” diagram put me with my feet on the floor again.

NDepend

Now I know why coming up with decent unit tests for this code would not be easy :-) If you’re not into metrics like I do, you do need the excellent documentation though.

The out of the box report provides you with suggestions on which methods could need refactoring, which ones are too big, too complex, lack comments, have too many parameters, too many local variables, too many responsibilities and much much more. Furthermore, you can customize the report by adding your own queries – in Code Query Language (CQL) format.

Unfortunately I cannot disclose my complete report, but believe me – it turned out to be invaluable!

If you haven’t looked at NDepend before, be sure you do!

[Update] I found this article by Scott Hanselman a particular good read on the basic terminologies involved in NDepend.

Source Control Rocks!

Having the pleasure to have inherited an interesting codebase from a former colleague, I recently discovered first hand that source control can be a PITA too! That is, not using it as it should be used. As I already stated before, when used right, source control can safe your life. But not this time..

When I first looked at the codebase I’m being asked to change, I was relieved to see that it was under source control. Okay, let’s see what version is the one in production right now. Huh? Okay, no tags to be seen anywhere. In case you don’t know what tags are, this is a very good introduction to source control.

Right, let’s see if I can determine the production version by looking at the history of changes. Nope, almost no checkins contain comments to determine what was changed and why. Great. What’s next?

What I’m doing now is trying to compare the dll versions on the production system with the times of checkin in source control to narrow the scope. To make things even worse, it seems that the client side of the application has been modified after the server side has been into production. Because all parts of the application reside in the same solution and source control tree, I’ll have to do some serious hacking afterwards to assemble the current state of the system as it is in production.

So using source control is good, using it as it should is even better!

Definitely the best guide to using source control is made by Eric Sink.

[Update] Currently using the magnificent WinMerge to see what has changed exactly

Remote Debugging Web Applications

While trying to debug a problem with one of my webapps, I discovered this post by Wictor Wilén about how to get remote debugging working properly.

So far, it works great! I managed to find the problem almost immediately – as usual it was kind of trivial. Mmhh, makes me think about getting more logging into my app 😉