Проблема связанности в архитектуре приложений в последнее время получила очень много огласки, и породила большое количество фреймворков DI-характера и приложений для статического разбора и «умного рефакторинга». Об одном таком приложении под названием NDepend я и хочу рассказать.
Что такое NDepend? Это приложение для статического анализа кода. Казалось бы, у нас уже есть FxCop со своим набором правил, есть ReSharper который умеет «чистить» наш код и неплохо его рефакторит, есть также метрики в Team Edition, так зачем же еще один анализатор?
NDepend – это программа с весьма большим уклоном в сторону архитектуры, в частности в сторону выявления разных погрешностей в плане сильной связанности между компонентами, слишком открытой видимости классов (неоптимальной инкапсуляции), плохого наименования структур. Также, NDepend выдает очень много сложных метрик (например, показатель абстрактности) которые можно анализировать и визуализировать.
Прежде чем начать работать с NDepend (триальную версию можно скачать тут), я хочу заметить что в отличии от, скажем, ReSharper, который можно купить даже для джуниора (особенно для джуниора) и получить повышение эффективности, NDepend требует от пользователя немалых знаний в плане архитектуры, да и терминология у него весьма специфическая, и ее надо изучать.
Для начала посмотрим на самые «красочные» фичи NDepend, а именно на возможности визуализации. NDepend, как и другие статические анализаторы, подгружает ваш скомпилированный код (он анализирует именно IL) включая все зависимости. После анализа, он формирует несколько артефактов.
График зависимостей (dependency graph)
График зависимостей иллюстрирует зависимость между элементами анализируемого кода. В отличии от программ которые показывают зависимость между проектами, NDepend может показывать любые формы зависимости, начиная от сборок, и заканчивая конкретными методами.
График зависимостей синхронизируется с матрицей зависимостей (показана ниже). Также, его элементы кликабельны, и позволяют через right-click манипулировать визуализацией элементов, производить запросы, и так далее. Об этом чуть позже.
Матрица зависимостей (dependency matrix)
Матрица зависимостей – это двумерная сетка, на которой показано общее количество зависимостей между компонентами. При клике на квадратике, график зависимостей обновляется, показывая именно те взаимодействия, на которые вы только что нажали. Внимание: некоторые компоненты с большой степенью связанности могут рисоваться не сразу (т.к. их много). Вот например фрагмент иллюстрированного взаимодействия
Матрица зависимостей позволяет осуществлять drill-down, то есть углубляться в структуру программы чтобы понять, где конкретно связанность. Для этого можно использовать плюсики в начале колонок и рядов. Например, на скриншоте ниже, я раскрыл пространство имен NHibernate, и могу видеть взаимодействие вплоть до отдельных методов.
Метрики
Визуализатор метрик позволяет оценить вашу кодовую базу визуально. В частности, вы можете сравнить элементы вашего кода по объему IL инструкций, количеству методов, и еще по многим критериям. Сама диаграмма, естественно, кликабельна.
Это окошко хоть и названо «метрики», но собственно те метрики, которые фигурируют в выпадающем меню – это те же метрики о которых предоставляется отчет. Я не буду писать об отчете отдельно, скажу только что там фигуриет большое количество необычной терминологии. Для чтого чтобы быстро разобраться что же такое, например, afferent coupling, я рекоммендую вот этот постер, где все достаточно неплохо описано.
Другие окна
Информационное окошко показывает дополнительную информацию по выбранному элементу. Например, если вы выбрали зависомость между компонентами, в этом окошке будет написано, сколько найдено зависимостей, и какого типа.
Браузер классов работает точно так же как в Студии. Выбрав элемент из дерева, в информационном окне будут расписаны показатели метрик по выбранному элементу. Также, элемент можно манипулировать контекстным меню, о котором мы поговорим отдельно.
Да, и еще одна фича (и соответственно еще одно окно) – это поиск по кодовой базе.
Для статического анализа кода, NDepend использует SQL-образный язык для проведения запросов по кодовой базе. Язык этот называется CQL (Code Query Language). Этот язык фактически содержит те конструкции, которые полезны для анализа именно кода. На основе CQL NDepend содержит немалое количество «рекоммендаций». Вот например как выглядит предложение делать все структуры immutable:
Я специально оставил комментарий чтобы показать, что все рекоммендации с которыми поставляется NDepend прокомментированы, и про них можно почитать.
Панель статического анализа показывает дерево тех правил, которые были проверены.
Панель CQL соответственно показывает результаты запроса, т.е. те элементы кода, которые имеет смысл рефакторить.
Гонять NDepend локально на своей машине – это хорошо, но недешево. Поэтому есть и другая возможность – а именно встроить NDepend в процесс непрервыной интеграции, ведь NDepend поставляется с тасками для MSBuild. Пример того, как интегрировать NDepend и TeamCity описан тут, но если погуглить, уверен что можно найти и другие туториалы, например для CC.Net или для использования NAnt.
Если вас заинтересовала эта программа, рекоммендую скачать триальную версию и погонять эту тулзу по вашему коду. Кто знает – возможно она станет неотъемлимой составляющей вашей практики программирования. Удачи!
Что такое NDepend? Это приложение для статического анализа кода. Казалось бы, у нас уже есть FxCop со своим набором правил, есть ReSharper который умеет «чистить» наш код и неплохо его рефакторит, есть также метрики в Team Edition, так зачем же еще один анализатор?
NDepend – это программа с весьма большим уклоном в сторону архитектуры, в частности в сторону выявления разных погрешностей в плане сильной связанности между компонентами, слишком открытой видимости классов (неоптимальной инкапсуляции), плохого наименования структур. Также, NDepend выдает очень много сложных метрик (например, показатель абстрактности) которые можно анализировать и визуализировать.
Прежде чем начать работать с NDepend (триальную версию можно скачать тут), я хочу заметить что в отличии от, скажем, ReSharper, который можно купить даже для джуниора (особенно для джуниора) и получить повышение эффективности, NDepend требует от пользователя немалых знаний в плане архитектуры, да и терминология у него весьма специфическая, и ее надо изучать.
Для начала посмотрим на самые «красочные» фичи NDepend, а именно на возможности визуализации. NDepend, как и другие статические анализаторы, подгружает ваш скомпилированный код (он анализирует именно IL) включая все зависимости. После анализа, он формирует несколько артефактов.
График зависимостей (dependency graph)
График зависимостей иллюстрирует зависимость между элементами анализируемого кода. В отличии от программ которые показывают зависимость между проектами, NDepend может показывать любые формы зависимости, начиная от сборок, и заканчивая конкретными методами.
График зависимостей синхронизируется с матрицей зависимостей (показана ниже). Также, его элементы кликабельны, и позволяют через right-click манипулировать визуализацией элементов, производить запросы, и так далее. Об этом чуть позже.
Матрица зависимостей (dependency matrix)
Матрица зависимостей – это двумерная сетка, на которой показано общее количество зависимостей между компонентами. При клике на квадратике, график зависимостей обновляется, показывая именно те взаимодействия, на которые вы только что нажали. Внимание: некоторые компоненты с большой степенью связанности могут рисоваться не сразу (т.к. их много). Вот например фрагмент иллюстрированного взаимодействия
NHibernate и Iesi.Collections:Матрица зависимостей позволяет осуществлять drill-down, то есть углубляться в структуру программы чтобы понять, где конкретно связанность. Для этого можно использовать плюсики в начале колонок и рядов. Например, на скриншоте ниже, я раскрыл пространство имен NHibernate, и могу видеть взаимодействие вплоть до отдельных методов.
Метрики
Визуализатор метрик позволяет оценить вашу кодовую базу визуально. В частности, вы можете сравнить элементы вашего кода по объему IL инструкций, количеству методов, и еще по многим критериям. Сама диаграмма, естественно, кликабельна.
Это окошко хоть и названо «метрики», но собственно те метрики, которые фигурируют в выпадающем меню – это те же метрики о которых предоставляется отчет. Я не буду писать об отчете отдельно, скажу только что там фигуриет большое количество необычной терминологии. Для чтого чтобы быстро разобраться что же такое, например, afferent coupling, я рекоммендую вот этот постер, где все достаточно неплохо описано.
Другие окна
Информационное окошко показывает дополнительную информацию по выбранному элементу. Например, если вы выбрали зависомость между компонентами, в этом окошке будет написано, сколько найдено зависимостей, и какого типа.
Браузер классов работает точно так же как в Студии. Выбрав элемент из дерева, в информационном окне будут расписаны показатели метрик по выбранному элементу. Также, элемент можно манипулировать контекстным меню, о котором мы поговорим отдельно.
Да, и еще одна фича (и соответственно еще одно окно) – это поиск по кодовой базе.
Для статического анализа кода, NDepend использует SQL-образный язык для проведения запросов по кодовой базе. Язык этот называется CQL (Code Query Language). Этот язык фактически содержит те конструкции, которые полезны для анализа именно кода. На основе CQL NDepend содержит немалое количество «рекоммендаций». Вот например как выглядит предложение делать все структуры immutable:
// <Name>Structures should be immutable</Name>
WARN IF Count > 0 IN SELECT TYPES WHERE IsStructure AND !IsImmutable AND !IsInFrameworkAssembly<br/>
// It is deemed as a good practice to make your structure immutable.
// An object is immutable if its state doesn’t change once the object has been created.
// Consequently, a structure is immutable if its instances are immutable.
// Immutable types naturally simplify code by limiting side-effects.
// See some explanations on immutability and how NDepend supports it here:
// http://codebetter.com/blogs/patricksmacchia/archive/2008/01/13/immutable-types-understand-them-and-use-them.aspx
Я специально оставил комментарий чтобы показать, что все рекоммендации с которыми поставляется NDepend прокомментированы, и про них можно почитать.
Панель статического анализа показывает дерево тех правил, которые были проверены.
Панель CQL соответственно показывает результаты запроса, т.е. те элементы кода, которые имеет смысл рефакторить.
Гонять NDepend локально на своей машине – это хорошо, но недешево. Поэтому есть и другая возможность – а именно встроить NDepend в процесс непрервыной интеграции, ведь NDepend поставляется с тасками для MSBuild. Пример того, как интегрировать NDepend и TeamCity описан тут, но если погуглить, уверен что можно найти и другие туториалы, например для CC.Net или для использования NAnt.
Если вас заинтересовала эта программа, рекоммендую скачать триальную версию и погонять эту тулзу по вашему коду. Кто знает – возможно она станет неотъемлимой составляющей вашей практики программирования. Удачи!
