Almost for the last 2 years, I’ve been working on a substantially large and complex project. And like in any long haul project, some areas of the project’s code has been developing their own distinct smell. Much of the project is in good condition however, thanks mostly to my OCD. But, there’s this one library of code that’s been haunting me in my dreams, begging me to refactor it out of it’s misery. Then again, this is working code…
Refactoring a 2 year old code base is never going to be easy or pleasant. Without the right tools to help you, the task could be pretty daunting. NDepend is one such awesome tool. One glance at the many testimonials the tool has received is enough to realize that this no ordinary app. Check out what the Scott Hanselman’s got to say:
“NDepend is giving me insight into my applications that I haven’t had before (…) Once I realized the depth and breadth of the information I was looking at it, I was like a kid in a candy shop.”
Personally however, I was a little intimidated by the complexity of NDepend at first. It’s definitely not the kind of app with which you can jump first and figure out on the way down. You might want to invest a couple of hours going through the documentation first. This post from Andre Loker is probably a good place to start.
Step 1: Figuring out where to start
When you have a large code base to refactor, the hardest thing to do is to figure out where to start. Generally, you’d want to start with the simplest steps. The built in CQL queries in NDepend are probably the best guides for this.
With just one click (“Run Analysis”), NDepends have come back with a report of how crappy the project’s code is. Not only that, it has made a quick list of 10 methods that I should look in to refactoring. So, there it is… my starting point.
