Я пробовал NDepend, читал несколько блог-постов об этом и даже слышал подкаст. Я думаю, что NDepend может быть действительно полезным инструментом, но я до сих пор не вижу, где бы я его использовал.
Как вы его используете? Вы используете его, почему? Почему бы и нет?
Я хотел бы услышать о некоторых примерах реального мира.
Я использовал NDepend в течение последних нескольких лет. В основном это инструмент анализа зависимостей, и поэтому это может помочь вам с большим количеством проблем, связанных с зависимостью.
Одной из основных вещей, которые я использую для этого, является проверка зависимостей между моими сборками, типами и методами. Это помогает мне следить за тем, не связана ли связь между типами, а также помогает мне найти возможности рефакторинга.
При входе в массивный рефакторинг, например. extracting.moving types для других сборок, это позволяет вам понять, что зависит от того, что вам не нужно делать старым "переместить мои типы в другую сборку, затем попытаться скомпилировать и посмотреть, что происходит"
NDepend также имеет отличную визуальную матрицу для просмотра этой информации.
Кроме того, он имеет фантастический язык запросов, CQL, который позволяет писать пользовательские запросы. Это могут быть простые вещи, такие как "показать мне все методы, которые называют этот метод", запросам, чтобы выделить мертвый код, запросы о сложностях с циклеком, связь и т.д. И многое другое.
В свою очередь, он может быть интегрирован в процесс сборки, поэтому вы можете создавать предупреждения/сбои на основе запросов CQL, например "сбой сборки, если метод имеет более 100 строк кода, но без комментариев" (это является примером - я не предлагаю, чтобы эта конкретная метрика была хорошей вещью).
Он также может импортировать данные о покрытии кода и дает вам визуальное представление областей с небольшим охватом кода, а также позволяет запускать запросы CQL с информацией о покрытии кода (например, показать мне методы с охватом менее 70% кода)
Вы также можете загрузить свою текущую сборку своего проекта и предыдущую сборку и выполнить запросы между ними, такие как "показать мне все новые типы с охватом кода на 70%" - это поможет вам ввести более жесткие правила в отношении существующих базы кода.
Это фантастический инструмент, и его не так сложно изучить. Это страшно в начале, просто из-за большого объема информации, которую он дает, но настоятельно рекомендуется.
Я также считаю его неоценимым в понимании структуры сложных вызовов методов. Например, я могу вызвать все методы транзитивно с использованием определенного метода или поля и посмотреть, есть ли проблемы с круговыми вызовами или нежелательными зависимостями или более запутанными путями, чем необходимо, и т.д.
График зависимости также теперь является интерактивным, поэтому я могу удалить методы, которые меня сейчас не интересуют, и перемещать других вокруг, чтобы дать хорошую визуализацию происходящего.
Я нашел полезным визуализировать изменения между версиями сборок. Даже для моментального снимка изменений в данном выпуске...
Я думаю, что он сияет в среде непрерывной интеграции, где вы можете настроить запросы CQL для измерения интересующих вас метрик кода (Cyclomatic Complexity, Long Methods и т.д.), а затем вы можете измерить свое улучшение в этих областях время.
На самом деле этот инструмент полезен, если у вас есть, например, интерфейс, который используется другой частью приложения, разработанной другим человеком/поставщиком. Каждый раз, когда вы хотите изменить интерфейс, вы должны выяснить, кто использует ваш интерфейс, чтобы не нарушать его код (сборка не будет строить) Это применимо для больших проектов.
Этот инструмент полезен, когда ваше приложение имеет огромное количество сборок. Это помогает мне узнать зависимости кода, а также изменения между выпусками
Я также использую NDepend для сравнения двух версий некоторой сборки. У NDepend есть эта отличная функция. Это дает мне представление об изменениях и ходе работы в сборке, добавленных методах, методах и многом другом.