Поглощение технического долга Alfresco

Для этой демонстрации мы использовали проект «remote-api» от Alfresco, который доступен через svn здесь . Он состоит примерно из 100 тысяч строк кода Java. После того, как у нас появился наш проект, мы должны были провести его аудит и рефакторинг. Но первым делом нужно было определить, что мы собираемся проверять: какие правила качества мы собираемся проверить.

1. Настройка хранилища правил

Scertify — это инструмент статического анализа на основе правил. Он интегрирует существующие инструменты, такие как PMD, Findbugs, Checkstyle, JSLint …, а также предоставляет собственный механизм анализа. Это развитый движок, который позволяет писать расширенные правила анализа и рефакторинга. Итак, первое, что нужно сделать, это выбрать, какие правила контролировать на проекте. В этой статье мы фокусируемся на рефакторинге, поэтому мы выбрали только те правила, которые могут быть автоматически реорганизованы. Ниже приводится выдержка из репозитория правил, который мы использовали.

<?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>

UseEqualsToCompareString

Это правило обнаруживает сравнения строк, которые используют «==» вместо метода «равно». Рефакторинг заменяет сравнение вызовом метода equals.
Оригинальный код:

if(type == "limit")

Рефакторированный код:

if("limit".equals(type))

PositionLiteralsFirstInComparisonsRefactor

Это правило проверяет, что литералы находятся на первом месте в сравнениях (как в коде рефакторинга выше). Рефакторинг инвертирует литерал и переменную. Это гарантирует, что код не сможет завершиться сбоем из-за того, что переменная является нулевым указателем.

InefficientConstructorCall

Вызов конструктора типа оболочки, такого как Integer, для преобразования примитивного типа — плохая практика. Это менее эффективно, чем вызов статического метода valueOf.

Оригинальный код:

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

Рефакторированный код:

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

 2. Провести аудит проекта

После того, как у нас появился репозиторий, мы были готовы провести аудит проекта. Мы использовали Scertify Refactoring Assessment, чтобы получить обзор технической задолженности проекта и возможностей рефакторинга. Как видно на рисунке ниже, при использовании репозитория техническая задолженность за 11 дней может быть исправлена ​​автоматически. Конечно, мы могли бы включить другие правила, чтобы получить более полную картину технической задолженности проекта. Тем не менее, это было из-за беспокойства за эту статью.

3. Провести рефакторинг проекта

Последний шаг — выполнить рефакторинг проекта. Для этого мы использовали Scertify Professional Edition через подключаемый модуль Scertify для Eclipse. Мы импортировали наш XML-репозиторий, как описано в этой статье . Scertify проанализировал проект и сообщил о нарушениях, как показано на рисунке ниже.

Все, что нам нужно было сделать, это использовать функцию рефакторинга Scertify непосредственно в Eclipse, и движок позаботился об исправлении нарушений. В результате всего за несколько кликов мы устранили техническую задолженность за 11 дней. Для иллюстрации приведу пример кода до рефакторинга и после рефакторинга. Как мы видим, было применено правило «Использовать равно для сравнения строк».

В заключение, благодаря функциям рефакторинга Scertify мы смогли эффективно исправить 11-дневный технический долг за несколько минут. Мы рады сделать переработанный код доступным для сообщества, вы можете скачать его ниже. Мы будем продолжать проводить такой рефакторинг в приложениях с открытым исходным кодом, поэтому, если у вас есть идея для проекта с открытым исходным кодом, который может использовать такой рефакторинг, просто дайте нам знать!

Скачать исходные файлы

• Реорганизованный проект:  удаленный API Alfresco с рефакторингом
• Оригинал (вместе со svn):   http://svn.alfresco.com/repos/alfresco-open-mirror/alfresco/HEAD/root/projects/remote-api

О Scertify ™ Professional

Scertify ™ Professional Edition — это подключаемый модуль Eclipse, предназначенный для анализа, контроля и исправления дефектов качества кода с помощью компьютерного рефакторинга кода. Он включает +1 600 правил кодирования и автоматического рефакторинга для проектов Java и Javascript.