Визуализация погашения технического долга посредством рефакторинга с помощью NDepend

В этой статье я расскажу, как можно использовать NDepend для погашения технического долга посредством рефакторинга.

Введение

Я получил лицензию от Патрика Смаччиа, создателя NDepend. Однако моя недавняя работа была больше сосредоточена на инфраструктуре, чем на разработке приложений, поэтому у меня не было возможности использовать ее в своей работе. Поэтому я решил провести рефакторинг исходного кода, написанного ранее.

Вот исходный код, который я пытался реорганизовать; это простой инструмент для захвата рабочего стола:

Код был написан 15 лет назад, поэтому он довольно примитивен, но я подумал, что он идеально подойдет для практики рефакторинга.

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

Что такое NDepend?

NDepend — это инструмент статического анализа для анализа кода .NET. Его основные функции включают качество кода и визуализацию архитектуры, а также отслеживание изменений кода.

Вот статья, в которой Патрик рассказывает о NDepend:

Анализ исходного кода

Запустите VisualNDepend.exe и проанализируйте проект VS. Связь с проектом VS может быть сохранена как проект NDepend.

Результаты анализа визуализируются на панели инструментов.

Установка базовой линии

Во-первых, установите базовый уровень перед рефакторингом.

Создайте копию исходного кода `v1.0` и создайте `v2.0`. Затем создайте проекты NDepend для версий 1.0 и 2.0 и установите версию 1.0 в качестве базовой версии для версии 2.0.

Отныне я не буду модифицировать v1.0 и рефакторить v2.0.

Изучение горячих точек

NDepend обладает мощными функциями, помогающими определить области, требующие рефакторинга.

Сосредоточьтесь на «Долг» (технический долг) на панели инструментов.

При выборе «Типы для исправления приоритета» перечислены классы с «проблемами» с низкой точкой останова.

Чем ниже точка останова, тем выше ценность инвестиций в улучшение качества кода, и она служит индикатором для определения приоритета.

Пожалуйста, обратитесь к официальной документации для концепции точек останова:

На этот раз я сосредоточусь на исправлении MainForm+Config с самой низкой точкой останова и рейтингом E.

Обратите внимание, что рейтинг основан на методе SQALE.

Горячие точки рефакторинга

Нажмите «Проблемы» в «Главной форме + Конфигурация», и отобразится список проблем.

Многие проблемы возникают из-за полей, поэтому я заменю их на свойства.

v1.0

/// <summary>
/// Configuration
/// </summary>
private class Config {
    /// <summary>
    /// Image format
    /// </summary>
    public string ImageType;
    /// <summary>
    /// Image magnification
    /// </summary>
    public decimal Magnification;
}

v2.0

/// <summary>
/// Configuration
/// </summary>
private class Config {
    /// <summary>
    /// Image format
    /// </summary>
    public string ImageType { get; set; }
    /// <summary>
    /// Image magnification
    /// </summary>
    public decimal Magnification { get; set; }
}

После восстановления и повторного анализа вы можете увидеть, сколько долга было погашено по сравнению с базовым уровнем. Другие показатели, такие как «Сложность метода», также визуализируются.

Новый долг, созданный непреднамеренно

Важно убедиться, что рефакторинг не приведет к возникновению новых долгов.

Я перепечатаю приборную панель из ранее.

Это показывает, что по сравнению с базовым планом возникли четыре новые проблемы. Это долги, созданные в процессе рефакторинга.

При нажатии на «+4» будут перечислены классы с проблемами.

Нажав на `typeIssues` соответствующего класса, вы увидите проблему.

Все эти проблемы указывают на то, что видимость свойств общедоступна, хотя класс MainForm+Config не является общедоступным. Поэтому буду модифицировать их на внутренние.

v2.0

private class Config {
    /// <summary>
    /// Image format
    /// </summary>
    internal string ImageType { get; set; }
    /// <summary>
    /// Image magnification
    /// </summary>
    internal decimal Magnification { get; set; }
}

После перестроения и повторного анализа убедитесь, что новые проблемы устранены.

Визуализация сравнения с базовой линией

Как упоминалось ранее, вы можете сравнить, сколько долга было погашено по сравнению с базовым уровнем.

Кроме того, вы можете сравнить различные аспекты.

Например, если выбрать в меню [Diff] › [Code Diff Summary] › [Types where code], будут перечислены классы, измененные во время рефакторинга.

При выборе [Diff Source] в контекстном меню отобразится разница между соответствующим классом и базовым уровнем.

Заключение

В этой статье я объяснил, как использовать NDepend для улучшения качества кода, сосредоточившись на сравнении с базовым уровнем.

Попробовав его, я понял, что NDepend может обеспечить следующие преимущества:

• Количественная оценка потерь из-за долга и погашения с помощью рефакторинга, который может быть использован для обращения к бизнес-стороне. Другими словами, его можно использовать в качестве основы для предложения рефакторинга.
• Повышение мотивации разработчиков за счет визуализации показателей достижения улучшения качества кода и текущего качества кода по сравнению с целевыми значениями.

Кроме того, NDepend имеет множество других функций и вариантов использования. Я хотел бы попробовать другие функции в будущем.