DevOps Zone is brought to you in partnership with:

I have a Master’s degree in computer science and I'm a huge Java addict. I originally worked for Tocea’s R&D team where I took part in the development of Tocea’s audit and refactoring softwares. I am now a member of the professional services team where my mission is to provide companies with solutions to tackle their technical debt. Armel has posted 7 posts at DZone. You can read more from them at their website. View Full User Profile

Takeover of Alfresco's Technical Debt

07.22.2013
| 3876 views |
  • submit to reddit
An efficient way to get rid of some Technical Debt quickly and efficiently is to use an automatic refactoring tool such as Scertify. Indeed, Scertify enables to automatically or semi-automatically correct some code violations to coding best practices. To demonstrate some of Scertify's features we performed such refactoring on a sub-project of Alfresco community edition, an open-source enterprise content management. Doing so, we were able to suppress 25% of technical debt (11 days).

For this demonstration, we used the project "remote-api" from Alfresco, which is available via svn here. It consists in around 100K lines of Java code. Once we had our project, we had to audit it and refactor it. But the first thing to do was to define what we were going to audit : which quality rules we were going to check.

1. Set-up a rules repository

Scertify is a rule-based static analysis tool. It integrates existing tools such as PMD, Findbugs, Checkstyle, JSLint... and also provide its own analysis engine. This is this evolved engine that enables to write advanced analysis rules and refactoring. So, the first thing to do was to choose which rules to control on the projet. In this article, we are focusing on refactoring, so we chose only rules that can be automatically refactored. Below is an extract if the rules repository we used.

Rules repository for remote-api's refactoring :
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<XmlRepository xmlns="http://www.tocea.com/codewatch/platform/api/repository/xml/">
<Rules Priority="3" Criticity="MAJOR" Name="java::syntax::UseIsEmpty"/>
    <Rules Priority="4" Criticity="CRITICAL" Name="java::syntax::SwitchDefaultLabelShouldBeLast"/>
    
    <Rules Priority="1" Criticity="INFO" Name="pmd::StringToString"/>
    <Rules Priority="2" Criticity="MINOR" Name="pmd::UnusedPrivateMethod"/>
    <Rules Priority="4" Criticity="CRITICAL" Name="java::syntax::DoWhileLoopsMustUseBraces"/>
    <Rules Priority="4" Criticity="CRITICAL" Name="java::syntax::SwitchShouldHaveDefault"/>
    <Rules Priority="2" Criticity="MINOR" Name="pmd::StringInstantiation"/>
    <Rules Priority="3" Criticity="MAJOR" Name="java::performance::InefficientNumberConstructor"/>
    <Rules Priority="4" Criticity="CRITICAL" Name="java::robustness::UseEqualsToCompareStrings"/>
    <Rules Priority="3" Criticity="MAJOR" Name="java::modifiers::ModifierOrder"/>
    <Rules Priority="3" Criticity="MAJOR" Name="java::modifiers::RedundantModifier"/>
    <Rules Priority="2" Criticity="MINOR" Name="java::syntax::WhileLoopsMustUseBraces"/>
    <Rules Priority="2" Criticity="MINOR" Name="pmd::MethodArgumentCouldBeFinal"/>
    <Rules Priority="3" Criticity="MAJOR" Name="java::syntax::SortableSwitch"/>
    <Rules Priority="2" Criticity="MINOR" Name="pmd::ForLoopsMustUseBraces"/>
    <Rules Priority="3" Criticity="MAJOR" Name="java::performance::ArrayListConstructorShouldSpecifySize"/>
    <Rules Priority="1" Criticity="INFO" Name="pmd::UnusedImports"/>
</XmlRepository>


Here's a more detailed presentation of three of those rules. If you'd like to learn more about other rules, do not hesitate to leave a comment.

UseEqualsToCompareString

This rule detects comparisons of Strings that use "==" instead of the "equals" method. The refactoring replaces the comparison by a call to the equals method.
Original code:

if(type == "limit")

Refactored code:

if("limit".equals(type))

PositionLiteralsFirstInComparisonsRefactor

This rule checks that literals are in the first position in comparisons (as in the refactored code above). The refactoring invert the literal and the variable. This ensures that the code cannot crash due to the variable being a null pointer.

InefficientConstructorCall

Calling the constructor of a wrapper type, like Integer, to convert a primitive type is a bad practice. It is less efficient than calling the static method valueOf.

Original code:

model.put("patchedNodeCount", newLong(patchedNodeRefs));

Refactored code:

model.put("patchedNodeCount", Long.valueOf(patchedNodeRefs));

 2. Perform an audit of the project

Once we had our repository, we were ready to perform an audit of the project. We used Scertify Refactoring Assessment to get an overview of the project's technical debt and the refactoring possibilities. As we can see on the picture below, with the repository used, 11 days of technical debt can be corrected automatically. Of course, we could have included other rules, to get a finer picture of the project's technical debt. However, this was out of concern for this article.

Remote-api in Scertify Refactoring Assessment

3. Perform the refactoring of the project

The last step is to perform the refactoring of the project. To do so, we used Scertify Professional Edition through the Scertify's plug-in for Eclipse. We imported our xml repository, as described in this article. Scertify analyzed the project and reported the violations as shown on the picture below.

Remote-api's violations in Scertify Eclipse before refactoring

All we had to do was to use the Scertify's refactoring feature directly in Eclipse and the engine took care of correcting the violations. As a result, in few clicks we eliminated 11 days of technical debt. To illustrate, here's an exemple of a code before the refactoring and after the refactoring. As we can see, the rule "Use Equals To Compare Strings" has been applied.

UseEqualsToCompareStrings before refactoring

UseEqualsToCompareStrings after refactoring



To conclude, thanks to Scertify’s refactoring features we were able to efficiently correct 11 days of technical debt in few minutes. We are glad to make the refactored code available to community, you can download it below. We will continue to do such refactoring on open-source applications, so if you have an idea for an open-source project that could leverage such refactoring, just let us know!


Download the source files

About Scertify™ Professional

Scertify™ Professional Edition is an Eclipse plugin dedicated to analyze, control and correction of code quality defects, through computer-assisted code refactoring. It includes +1,600 coding and automated-refactoring rules, for Java and Javascript projects.

» See features

» Download now (direct link)

Submit your project

If you're interested in a demo of Scertify, want to submit your project for the next TechDebt Taekover, or just give some valuable feedback... Please contact us to contact[at]tocea.com

Published at DZone with permission of its author, Armel Gouriou. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Witold Szczerba replied on Wed, 2013/07/24 - 2:27am

 Hi,

searching and fixing trivial bugs, like string comparison using equal sign, is not a refactoring, it is just a bug, easy to find and fix. Fixing trivial bugs is not an act of removing technical debt, because technical debt does not come from bugs.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.