Monday 10 August 2009

Maintenance - Repay the debt

It's time to repay some of that technical debt you have accumulated. The project has been running for a few years and often the code gets smelly. The code smells of complexity and bugs.

What do you do to approach such a problem? You clean it up of course!

Now I will tell you how you can choose what areas in the code you want to clean. For this you need a couple of tools. First one to calculate complexity and then you need something that tells you about changes in your codebase.

I have used Complexian and StatSVN in this example, but you may find other tools that does the same job just as well.

I started with Complexian and found that a few classes had a complexity above 21, which I consider as high risk. Then I combined those data with what we can get from StatSVN and came up with more that suggested that we should focus on the classes that has high complexity and many revisions. This because I reckon that a class with high complexity that is changed a lot must mean trouble. There is a lot of different approaches you can use, but this one proved to be sufficiant in my case.

From Complexian
Register.java: Complexity is 38

From StatSVN
Register.java : Lines of code: 2273
Register.java : Revisions: 32 (4th place)


Here you can of course add all the static code analysis you want, but for me this is sufficient to tell that there is something wrong with this class. In this way it is also easy to persuade the project manager that this is a risk that needs to be taken care of.

Then I dive in to the class to find if's and else's that needs a refactoring.. At the same time I notice that the class is in the wrong package as well. My goal is to reduce the risk in this class. Never refactor without a goal. Refactoring makes no sense if you do not do it to achieve something better. If the class never gets changed and you have no bugs that you know of in there, leave it alone. It would probably not show up as a candidate either since there would not be many revisions of that file.

Write some tests for those methods that have high complexity is hard, but rewarding. In this way you deal with risk in a professional manner instead of just "feeling" where to do you cleaning.

Hope this gives someone inspiration and a way to start repaying that technical debt they have accumulated during the years.

1 comment:

Thomas Ferris Nicolaisen said...

Very inspiring indeed! I've been postponing measuring complexity in our code for too long now. Will give Complexian a run :)