Вы используете NDepend?
Я испытывал NDepend, чтение нескольких сообщений в блоге об этом и даже услышал подкаст. Я думаю, что NDepend мог бы быть действительно полезным инструментом, но я все еще не вижу, где я использовал бы его.
Как Вы используете его? Вы используете его, почему? Почему нет?
Я хотел бы услышать о некоторых практичных примерах реального мира.
5 ответов
Я широко использовал NDEPEND в течение последних нескольких лет. В основном это инструмент анализа зависимостей, и поэтому это может помочь вам с множеством проблем, связанных с зависимостями.
Одно из главных вещей, которые я использую его, - это изучить зависимости между моими узлами, типами и методами. Это помогает мне сдерживать ли связь между типовыми типами вне руки, а также помогает мне возможности рефакторинга.
При отправке массивного рефактора, например Извлечение типов в другие сборы, это позволяет вам увидеть, что зависит от того, что, так, вам не нужно делать старые «Переместить мои типы на другую сборку, то попробовать и скомпилировать и посмотреть, какие перерывы»
NDEPend также имеет Отличная визуальная матрица для просмотра такой информации.
Кроме того, он имеет фантастический язык запросов, CQL, который позволяет писать пользовательские запросы. Это могут быть простыми вещами, такими как «Показать мне все методы, которые вызывают этот метод», чтобы запросы выделить Dead Code, запросы на циллологическую сложность, муфту и т. Д., И гораздо больше.
В свою очередь, он может быть интегрирован в процесс сборки, поэтому вы сможете создать предупреждения / неудачи на основе запросов CQL, такие как «сбой сборки, если метод имеет более 100 строк кода, но нет комментариев» (это является примером - я не предлагаю эту конкретную метрику - это хорошо).
Он также может импортировать данные охвата кода и дать вам визуальное представление областей с небольшим количеством покрытия кода, а также позволяя вам запустить запросы CQL от информации о покрытии кода (например, показать мне методы с использованием менее 70%)
Вы также можете загрузить текущую сборку своего проекта, а предыдущие сборки и запускающие запросы между ними, такие как «Показать мне все новые типы , которые имеют <70% Code Coverage» - это поможет вам представить Уверенные правила на существующих кодовых базах.
Это фантастический инструмент, и не слишком сложно учиться. В начале страшно, только из-за чистого объема ИНФОРМАТОНА Это дает вам, но настоятельно рекомендуется.
Я обнаружил, что это полезно для визуализации изменений между версиями сборки. Даже для моментального снижения изменений в данном выпуске ...
Я думаю, что он сияет в непрерывной интеграционной среде, где вы можете настроить запросы CQL для измерения метрик кода, которые вас интересуют (цикломаты, длинные методы и т. Д. ), а затем вы можете измерить ваше улучшение в этих областях со временем.
На самом деле этот инструмент полезен, если у вас есть E.G. Интерфейс, который использует другой частью приложения, разработанный другим человеком / поставщиком. Каждый раз, когда вы хотите изменить интерфейс, вы должны выяснить, кто использует ваш интерфейс, чтобы не разбить свой код (сборка не будет строить) Это применимо для более крупных проектов.
Я также считаю его бесценным для понимания структуры сложных вызовов методов. Я могу вызывать все методы транзитивно, используя, например, конкретный метод или поле, и могу видеть, есть ли возможные проблемы с циклическими вызовами, или нежелательными зависимостями, или путями, которые более запутаны, чем необходимо, и т. Д.
Граф зависимостей также теперь интерактивен, поэтому я могу удалить методы, которые мне сейчас не интересны, и перемещать другие, чтобы получить хорошую визуализацию того, что происходит.
Этот инструмент полезен, когда ваше приложение содержит огромное количество сборок. Он помогает мне выяснить зависимости кода, а также изменения между выпусками