Пробуем NDepend на небольшой библиотеке

Я постоянно ищу инструменты, которые помогут мне улучшить качество кода. Недавно я столкнулся с программой NDepend, которая распространяется как:

  • Расширение Visual Studio
  • Автономное приложение
  • Инструмент для создания отчета о процессе непрерывного совершенствования
  • Расширение Azure DevOps

В этой статье я попробую это сделать с версией сообщества Visual Studio 2019. Вот мои мысли по этому поводу.

Тестовый пример: библиотека .NET Core 3.0

Я произвел свое первое впечатление с помощью NDepend с простой библиотекой .NET Core 3.0 для постановки и удаления электронных писем, это весь код C # с некоторыми сценариями TSQL и консольным приложением (называемым Playground) для опробования библиотечных конструкций. Вы можете найти библиотеку в этом репозитории.

Примечание. NDepend также работает с другими версиями .NET Framework

В первый раз, когда вы откроете свое решение с установленным NDepend, вы заметите маленький белый кружок в правом нижнем углу IDE. Если вы щелкнете по нему, появится диалоговое окно, в котором вы сможете выбрать каждую сборку для анализа:

Сразу после нажатия кнопки «Анализировать» браузер открывает интерактивную локальную веб-страницу с отчетом обо всем анализе, который разделен на разделы.

Диаграммы

В этом разделе вы можете изучить визуальные представления анализа.

  • График зависимостей: здесь мы можем увидеть отношения между сборками нашего приложения. В моем примере мы видим, что Playground зависит от BasicEmailQueueManager (конечно, Playground использует свои классы) и от System.Threading.Tasks.
  • Матрица зависимостей: еще одно представление отношений сборок.
  • Представление показателей древовидной карты: это матрица, которая представляет цикломатическую сложность вашего программного обеспечения. На практике вы видите изображение, состоящее из квадратов, где каждый квадрат представляет метод. Его размер и цвет зависят от его сложности.
  • Абстрактность против нестабильности: это очень интересное представление. Это помогает определить, какие сборки потенциально болезненно поддерживать (например, конкретные и стабильные), а какие сборки потенциально бесполезны (например, абстрактные и нестабильные). Абстрактность: если сборка содержит много абстрактных типов (например, интерфейсы и абстрактные классы) и несколько конкретных типов, она считается абстрактной. Нестабильность: сборка считается стабильной, если ее типы используются множеством типов из других сборок. В этом контексте стабильный означает болезненное изменение.

Метрики приложения

В этом разделе вы можете увидеть числовые результаты.

Обратите внимание, что вы также можете видеть эти метрики непосредственно в Visual Studio и взаимодействовать со значениями:

  • Количество строк кода: подсчитывает строки кода.
  • Типы: подсчитывает количество языковых конструкций, таких как количество сборок, количество пространств имен, количество методов, полей и сторонних элементов.
  • Комментарий: процент прокомментированных строк по сравнению со всем проанализированным кодом.
  • Долг: оценка сложности рефакторинга некоторых частей кода для решения проблем. (См. Также: Технический долг)
  • Покрытие: процент кода, покрытого каким-либо тестом, например модульным тестом. В данном случае у меня нет модульных тестов, поэтому его значение равно 0%.
  • Сложность метода
  • Контрольные точки качества. Контрольные точки качества - это набор правил, которые классифицируются как "не пройдено", "предупредить" или "пройдено". Это прямое изображение качества вашего кода. Если вы видите, что что-то не работает, как в этом случае, вам следует начать с этого момента, чтобы просмотреть свое приложение.
  • Правила: Опять же, набор анализаторов, которые могут пройти или не пройти.
  • Проблемы: Еще одна классификация проблем вашего кода, классифицированная по степени важности. На данный момент в моей маленькой библиотеке есть два больших выпуска, шесть средних и два низких.

Сводка по воротам качества

Это первый раздел, который я прочитал бы, потому что он ясно показывает, что может быть не так с вашим кодом:

Как видите, было нарушено важное правило - давайте посмотрим, что это такое.

Резюме правила

Анализатор говорит, что основные проблемы моего кода следующие:

  • Есть метод со слишком большим количеством аргументов.
  • Есть тип, который имеет только статические члены, но сам класс не помечен как статический.
  • У класса есть три метода, которые не зависят от своего состояния, поэтому они должны быть помечены как статические.
  • Есть два пространства имен, которые содержат слишком мало типов. Он говорит: не создавайте пространство имен, если у вас есть только два типа для его добавления!
  • Один потенциально мертвый метод - также известный как бесполезный код.
  • Есть две сборки без обозначенной версии.

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

Если вы нажмете на любую из проблем, вы перейдете на страницу, где строка кода полностью описана, чтобы вы могли исправить ее:

Речь идет об этом конструкторе, который имеет семь параметров. Последовательная запись всех этих строк при создании экземпляра класса может считаться подверженной ошибкам, потому что, если вы сделаете ошибку порядка, вы можете поместить body в переменную subject и наоборот:

Исправление этого запаха кода могло бы сгруппировать две даты в класс EmailCronology, subject, from и body в EmailMainInformations.

Конечно, вы используете встроенное расширение Visual Studio, вы можете более комфортно перемещаться по коду:

Конфигурация правил

Что делать, если я не считаю ошибку важной и хочу ее отключить? NDepend поставляется с проводником правил:

Слева вы видите группы правил, связанные с текущим проектом. Если вы выберете одну группу, справа вы увидите список ее правил. Например, если я выберу групповое правило «Объектно-ориентированный дизайн», я найду несколько интересных правил, таких как:

  • Избегайте слишком больших интерфейсов
  • Базовый класс не должен использовать производные
  • Избегайте шаблона Singleton

Как видите, вы легко можете отключить каждую из них.

В заключение, любой статический анализатор кода - полезный инструмент. Я думаю, что каждый разработчик, работающий над базой кода, должен интегрировать ее в свою программу кодирования или в конвейер разработки. Возможность измерять, анализировать, визуализировать качество кода и определять некоторые пороги качества напрямую коррелирует с качеством кода и меньшим количеством ошибок в производственной среде.

Если вы работаете с Visual Studio и .NET Framework или .NET Core, NDepend отлично с этим справится!