Takeover of Alfresco's Technical Debt
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.
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.
if(type == "limit")
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.
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.
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.
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.
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.
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
- Refactored project: Alfresco's remote-api refactored
- Original (with svn): http://svn.alfresco.com/repos/alfresco-open-mirror/alfresco/HEAD/root/projects/remote-api
About Scertify™ Professional
» 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
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)