Managing technical debt with NDepend 2017

By | March 2, 2017

I’m building my Get Noticed project from the scratch. And since 3 months is actually a very short span of time, I need compromise between doing some things fast (boring ones) and doing other things in a way that will allow me to write about it and not be ashamed to show some code afterwards. That means I’ll need to incur a technical debt in few areas of project. And I must watch it closely to not allow it to grow without control or interests will probably kill me. And I have great tool for that.

This tool is NDepend. I wrote about it a while ago (sorry, haven’t translated it to english yet) and I was impressed back then. I’m still using this extension in my own little projects and in my job.

Since every line of code in my job-project goes through, is reviewed and merged by me, and it’s a lot of code, I need something that keep track of everything that I’ve missed, overlooked or haven’t connected together. We’ve had major release of our produc lately and I must admit that NDepend helped me to wrap things up before that. If you want to know what I’m doing in my job-time take a look here.

Now let’s get back to my free-time stuff – Get Noticed.

Technical debt

Let’s start about terminology. What exactly is technical debt. It’s all those things that we sometimes skip to make something NOW instead of doing this right way.

“It’s Friday 5PM, and my code works! Screw clean code I’ll refactor first thing on monday”

It works. We remember to do something about that later, at least utill next NOW thing appears out of nowhere. “It’s Friday 5PM, and my code works! Screw clean code I’ll refactor first thing on monday”.

Truth is we tend to forget about times when we do things fast and easy way, especially if we need to fix them later. We may brag about some great few lines of code but we don’t like to remember those dozens of ugly spaghetti driven development that we’ve done. Well… it works after all.

And then you need to add a feature, do some minor refactoring or change “this little thing there” And you end up changing code in entire project, everything is entwined with other things and it just won’t work. And by the way – you just need this little feature NOW. Previous two paragraphs was about debt, this one is about interests, and those are one that can really hurt you.

Managing debt

There are times that we just need to get indebted – I’m going to do that with front-end of Me2.0 and technologies that I won’t focus on during these 3 months. There are times we don’t even know we’re having more and more technical debt. That’s why I’m going to track my project with mentioned tool from the very beggining. I’ll need to get back and fix some things and I need to continuously check that I’m not doing something that will make me stuck in spaghetti in a few weeks.

Fortunatelly NDepend released it’s new version few weeks ago. And it featured tool that I need. It’s called Smart Technical Debt Estimation. Before that you’ve had some rules and queries that warned you about bad quality of your code or some critical issues. Now those queries will add predefined and configurable “minutes” to your technical debt pool.

You can analyze that and convert your technical debt to man-time and see for yourself if you’re good or screwed. You can even convert those man-hours to money and calculate cost of debt.

I’m doing this since the project started but you can include this in middle of development of your project. You can draw a virtual line and say “since now we’ll do things right”, and just start checking what mistakes you’ve made and what rules you’ve broke on regular basis. And fix them immediatly, before interests grow to unmanageable scale.

Let’s dev this right

“Since now we’ll do things right”

Let me  show you how it works. NDepend is standalone tool but it also have extension for Visual Studio. I’m using VS2015 now but I’ve tried it on VS2017 RC and it worked fine. After few minutes of configuring our Ndepend project that will attach to our .NET solution we’ll be able to view dashboard with some stats. After few days mine looked like that:

It isn’t bad but it isn’t great too. At the bottom in the middle we have our issues and above that we have rules. It looks like I’ve violated some rules and introduced some issues. Nothing serious for now but let’s check just to be sure.

I’ll click in red 12 in my rules to see what rules I’ve broken. I could’ve click in +3 to see what I’ve broken lately but I’ve checked and it wasn’t anything serious, just some work in progress stuff. Project is still to small to have any big issues.

At the bottom of my VS I can browse are rules that I’ve broken and if we select any we’ll have more details about rule in question and classes/methods of origination on our right. Most of mine are things that I’m working on and I’m fully aware so let’s focus on “Abstract base class should be suffixed with ‘Base'” rule. To be honest I’ve completly overlooked this and I don’t really know why but my class have prefix instead of suffix, coding really late have some downsides after all.

Since I don’t want to rename a lot of things when project will grow let’s do this now and move to other minor rule – “Methods that could have a lower visibility”:

On screenshot above you can see something that I really love about this tool. On the right of the screen I’ve marked two columns in data grid with red rectangle. In it we can see exatly what current method visibility I have right now and what it could’ve (and probably should’ve) be. Since I’m pretty sure it’ll stay that way I’ll change it in a sec.

I don’t want to do any big refactoring right now. I just want to show you how you can check what happened and what impact it can have between some major code changes. For the sake of this post let’s agree I’ve just done some big changes and made some great fixes because of what Ndepend shown me. It actually does work that way in real life scenarios with bigger projects.

So let’s just rebuild, run the analysis and see for ourselves.

I’ve changed my baseline setting in dashboard (marked with red rectangle) just to see what has changed during last hour. I can’t see any new issues and some of old ones are gone so I think it went pretty nice. If those were some bigger issues that I’ve introduced with code that I’ve just written I could’ve fix them before pushing my code to repository.

When to analyze and refactor?

Just as I’m checking every blog post before publishing, just as every important email I’m sending – I’m reading my code before commiting.

It does not matter if you use NDepend, other tools or just your own eyes and common sense. The question is “where should you refactor and make code better” I’m doing this before commiting any changes to repository. I’m opening my Visual Studio Git GUI and look at changes that I’ve made or do some analysis and minor fixes. I just can’t commit something that I didn’t checked. Even if I didn’t make any big mistakes in code there is always misplaced space, bad formatting or some commented out, old code that I’ve forgot to delete.

Just as I’m checking every blog post before publishing, just as every important email I’m sending – I’m reading my code before commiting.

Well… unless there’s a fire. In that case:

Podbij ↑