How OpenKM's Technical Debt Decreased by 49% Through Code Refactoring

Technical Debt is worth nothing if no pragmatic action is taken into code, in order to control and tackle it. To ilustrate the Scertify's capability to automatically correct code defects that increase this unintended debt, we performed code refactoring on OpenKM, an Free/Libre document management system. The initial Technical Debt of the project has been reduced by 49.2% from 84 days to 42 days. Here, at Tocea, we call it the Debt Write-Off.

For this first Debt Write-Off, we have decided to perform the refactoring of OpenKM (6.2.1-DEV).

According to Wikipedia, OpenKM is a Free/Libre document management system that provides a web interface for managing arbitrary files. OpenKM is a great tool but an audit of the code revealed some technical debt problems. That was a good opportunity to use Scertify and to be useful to an open-source community. The application consists mainly in 200K lines of code of Java. There is also Javascript, JSP, CSS... but we focus here on the Java code.

Technical debt before refactoring

Scertify Refactoring Assessment allows us to estimate the technical debt of the application. As you can see on screenshot #1, it is estimated to 84 days. This is the time needed to correct manually each error. This number only includes the time needed to make the change on the code, it does not include things like finding the file, understanding the problem, etc.

Of this 84 days, 60 represent errors that can be automatically refactored, thus taking nearly zero effort to correct.

We can take a closer look on the possibilities of automation (screenshot #2). Not all rules are currently implemented in Scertify, but we are working on it. For this project, we chose 7 rules that seemed particularly interesting.

Rules used for the refactoring

Here's a presentation of the rules used to perform the refactoring of OpenKM.

We are now ready to perform the refactoring with Scertify.

    The refactoring process

    The refactoring process consists of two steps :

  1. Configure a xml rule repository: The first step is crucial. As we have seen in previous section, some rules need to be configured to be useful. However, it shouldn't take more than half an hour.
  2. Run Scertify to perform the refactoring: The second step is just a command line invocation, where you specify the project to refactor and the rule repository to use.

For this project of 200K lines of code, the refactoring took 2 minute. You can check the process on a smaller project in this video tutorial.

Technical debt after refactoring
Screenshot #3 is the analysis of the refactored project by Scertify Refactoring Assessment. As you can see, 24 days of technical debt have been erased.

Screenshot #4 and #5 show the difference of violations in Sonar between the original and the refactored project.

Here's the number of violations that have been corrected for each rule (*) :

To sum up, with Scertify we've been able to correct quickly a huge number of errors. Some of them are not critical (like MethodArgumentCouldBeFinal) but we've also been able to refactor more evolved errors like AvoidPrintStackTrace, AddEmptyStringToConvert,...

Download the source files

(*) if you do the math, you'll see that more errors have been corrected. It's due to side effects of the refactoring (correcting a rule can remove violations of other rules) and also because we manually corrected few things in the code.

Submit your project for a Debt Write-Off

If you're interested in submitting your project to the next Debt Write-off, or just give some valuable feedback... Please contact us on Twitter: @Scertify

© 2008 SYS-CON Media