Статьи

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

Эффективный способ быстро и эффективно избавиться от технической задолженности — использовать инструмент автоматического рефакторинга, такой как Scertify . Действительно, Scertify позволяет автоматически или полуавтоматически исправлять некоторые нарушения кода в соответствии с рекомендациями по кодированию. Чтобы продемонстрировать некоторые функции Scertify, мы выполнили такой рефакторинг для подпроекта Alfresco Community Edition — корпоративного управления с открытым исходным кодом. Благодаря этому мы смогли погасить 25% технического долга (11 дней).


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

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

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

Хранилище правил для рефакторинга remote-api:

<?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 дней может быть исправлена ​​автоматически. Конечно, мы могли бы включить другие правила, чтобы получить более полную картину технической задолженности проекта. Тем не менее, это было из-за беспокойства за эту статью.

Remote-API в оценке рефакторинга Scertify

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

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

Нарушения Remote-API в Scertify Eclipse перед рефакторингом

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

ИспользуйтеEqualsToCompareStrings перед рефакторингом

UseEqualsToCompareStrings после рефакторинга


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

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

О Scertify ™ Professional

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

»Смотрите особенности

»Скачать сейчас (прямая ссылка)

Отправить свой проект

Если вы заинтересованы в демонстрации Scertify, хотите представить свой проект для следующего TechDebt Taekover или просто дать ценный отзыв … Пожалуйста, свяжитесь с нами, чтобы связаться с [at] tocea.com