Как поддерживать качества код на должном уровне? Есть много способов – культура написания кода, регулярное code review, всевозможные договорённости внутри команды (convensions), парное программирование и прочие практики XP, TDD, BDD, DDD… Список можно продолжать, и в него будут попадать все более страшные слова :) Но на самом деле каждый выбирается для себя свой способ.
А как следить за качеством кода в большой команде или нескольких команд? А если вы ими руководите и не можете уследить за всем кодом, т.е. участвовать в его написании, или кода настолько много что его ревью отнимает много времени? Тут нужно что-то придумать. Нужна лакмусовая бумажка которая укажет нам какие участки большой code base пересматривать а какие можно упустить. Такой лакмусовой бумажкой могут стать утилиты статического анализа и метрики кода. Тогда, по метрикам кода можно определить участки требующие внимания.
А одна из таких утилит, достаточно навороченная, с возможностью просматривать большое число метрик – NDepend. Помимо всего прочего основной акцент NDepend – это анализ зависимостей, поэтому прежде всего он поможет для анализа и разрешения проблем с зависимостями в коде.
Основное применение для себя в NDepend, я нашел в том чтобы проверять зависимости между сборками, типами, методами и т.п.
И тут вступает в игру одна из самых красочных фич NDepend – Граф зависимостей (dependency graph).
Причем смотреть зависимости можно между сборками, типами, методами и т.п.
Линии между блоками имеют определенное значение и если навести на них можно получить описание. Например зависимость между классами Step и Workflow которые показаны на Графе зависимостей на картинке выше.
Причем тут следует сказать что NDepend работает как с solution файлами так и со сборками, поэтому можно анализировать сборки даже без исходного кода.
Еще одним графиком который умеет отображать NDepend – матрица зависимостей (dependency matrix)
Матрица зависимостей это другой вариант представления зависимостей между элементами кода. Она находиться в синхронизируемом состоянии с графом зависимостей.
Например на матрице зависимостей мы видимо такую метрику как dependency cycles в виде красных квадратов. Что за метрика можно посмотреть также в контекстной помощи.
Еще один визуализатор – это Метрики (Metrics)
Он просто визуализирует метрики кода в виде такой вот матрицы:
Между метриками можно переключатся и соотвественно определять наиболее большой элемент. Например если нас интересует количество строк код то нам небходимо выбрать метрику lines of code (LOC) и проанализирвоать самые большые по площади элменты матрицы метрик.
CQL (Code Query Language)
В NDepend включена такая фича как CQL. CQL – это похожий на SQL синтаксис для того чтобы делать запросы на анализируемый код и получать на выходе результат в виде соответствия или не соответствия метрик.
Например, запрос на картинке ниже выводит не используемые типы:
CQL полезен для написания собственных запросов на анализируемый код. Но NDepend содержит большой набор уже построенных запросов. На основании которых он выводит определенные рекомендации к коду.
На картинке ниже показаны запросы которые отработали на анализируемом кода, например есть неиспользуемые методы и типы.
Интересно также что NDepend может проверять покрытие, это если мы анализируем solution из Visual Studio:
Или запросы связанные с производительностью, в данном случае boxing/unboxing и размер объектов:
В NDepend можно просто и быстро строить новые запросы на CQL, например простенький запрос на картинке ниже:
Метрик, которые анализирует NDepend, очень много и сразу наверное все не понять. Но к примеру может помочь этот постер про метрики кода (взят отсюда, картинка кликабельная и можно загрузить):
Из наиболее полезных метрик можно выделить, кроме привычных нам по типу Lines of Code:
- Afferent coupling (Ca)
Метрика описывает число типов или методов из внешних сборок, которые используют заданный тип или метод. Чем выше это значение – тем важнее заданный тип или метод для внешней сборки. - Efferent coupling (Ce)
Прямая противоположность Ca: описывает число внешних методов и типов сборки, которые использует определенный тип или метод. Чем выше значение, тем более зависимый указанный тип или метод от внешней сборки. - Relational cohesion (H)
Метрика описывает насколько сильно соотносятся типы внутри одной сборки. Обычно, типа внутри сборки могут быть сильно связаны, но не ооочень сильно (всему есть придел). - Instability (I)
Описывает насколько чувствительна определенная сборки относительно изменения в зависимых сборках. Измеряется как частное от efferent coupling (Ce) и total coupling (Ca+Ce). - Abstractness (A)
Описывает соотношение абстрактных типов в сборке. - Distance from main sequence (D)
Нестабильность (І) и абстрактность (А) должны быть сбалансированы. Другими словами сборка с высокой степеью абстрактности должна быть стабильной, так как она скорее всего используется другими сборками. Если сборка нестабильна (I), то скорее всего рано или поздно в нее будут внесены изменения и это повлечет собой необходимость вносить изменения в зависимые от нее сборки. С другой стороны, от от более “конкретной” сборка чаще всего не зависят другие сборки, в так случае допускается нестабильность (I) сборки в той или иной степени. - Lack of cohesion (LCOM)
В связанных классах большинство методов имеют дело с членами таких классов. Если окажется что большинство методов класса работают только с какой то частью методов связанных классов – это может стать индикатором того что ответственность (responsibility) класса слишком широкая и нужно произвести его декомпозицию (например разбить на классы). - Cyclomatic complexity (CC)
По этой метрике есть статья в википедии написанная сложным языком :) Можно понимать ее как анализ вложенностей метода. Описывает сколько возможных ветвлений и вложенностей, циклов, имеет метод. Метод с высоким CC сложно поддерживать.
Еще можно посмотреть определения всех метрик на сайте NDepend.
NDepend интегрируется с билд процессом – TFS, Cruise Control.NET, FinalBuilder, TeamCity. Для этого есть документация на сайте. Также есть консольный вариант. Так что автоматизируется задачи NDepend – “на ура”. Также в конце билда или анализа кода NDepend предоставляет сводный HTML отчет.
У NDepend есть возможность интегрироваться с Visual Studio 2008, 2010 (и наверное 2005, не проверял). Но к сожалению на загрузку дается только zip архив со всем необходимым. Мне кажется что им стоит все таки сделать простенький msi инсталлер и давать пользователю на выбор что загружать архив или его.
Также для NDepend есть определенный порог входа, и он достаточно не низкий. Метрик, графиков достаточно много и нужно уметь в них разбираться, анализировать и принимать решения. Для обучения на сайте есть неплохая документация, но к сожалению с “инсталляцией” самого продукта она не идет. Я думаю также можно найти подкасты или вебкасты в интернете. Например есть неплохое видео демо и туториал – Getting started
NDepend продукт не бесплатный, его стоимость порядка 400$ на 2 разработчика, и порядка 600$ на 2 билд компьютера. Это не дешево, поэтому каждому разработчику такой продукт не поставишь. К тому же в Trail/Open source/Academic лицензиях нет возможности зумирования на Графике зависимостей что весьма достает и делает анализ сложных и больших проект очень сложным. Мне бы хотелось чтобы зумирование разрешили в этих лицензиях.
NDepend продукт с достаточно захватывающими возможностями. Причем его сила не только в визуальной стороне. Визуальные графики – скорее для быстрого охвата и просмотра, а вот интеграция с билд процессом, и результаты CQL, и метрики покажут на что смотреть. Но малым командам, или индивидуальным разработчикам , или тем у кого небольшая code base такой продукт наверное не нужен – слишком дорог для этого. А вот большим командам, возможно с одним или несколькими архитекторами и большой code base – он пригодится. В таком сценарии визуальная часть устанавливается на компьютеры архитекторов плюс обязательная интеграция в билд процесс для остальных участников команды.
Комментариев нет:
Отправить комментарий