А как следить за качеством кода в большой команде или нескольких команд? А если вы ими руководите и не можете уследить за всем кодом, т.е. участвовать в его написании, или кода настолько много что его ревью отнимает много времени? Тут нужно что-то придумать. Нужна лакмусовая бумажка которая укажет нам какие участки большой code base пересматривать а какие можно упустить. Такой лакмусовой бумажкой могут стать утилиты статического анализа и метрики кода. Тогда, по метрикам кода можно определить участки требующие внимания.
А одна из таких утилит, достаточно навороченная, с возможностью просматривать большое число метрик – NDepend. Помимо всего прочего основной акцент NDepend – это анализ зависимостей, поэтому прежде всего он поможет для анализа и разрешения проблем с зависимостями в коде.
Основное применение для себя в NDepend, я нашел в том чтобы проверять зависимости между сборками, типами, методами и т.п.
И тут вступает в игру одна из самых красочных фич NDepend – Граф зависимостей (dependency graph).
Линии между блоками имеют определенное значение и если навести на них можно получить описание. Например зависимость между классами Step и Workflow которые показаны на Графе зависимостей на картинке выше.
Read more: Regfors devblog