Блог

У нас есть продукт с ~ 15 решениями, в каждом из которых несколько проектов.

Вопрос довольно прост: какой инструмент позволит нам выполнить поиск мертвого кода по всей кодовой базе?

Поиск в рамках одного решения достаточно прост (для этого есть множество ответов на SO).

Но как насчет определения, действительно ли «public void Foo()» в проекте AlphaProj решения AlphaSol, которое не используется в самом AlphaSol, используется, например, в BetaSol?

Хотя у вас есть 15 решений, ничто не мешает вам создать другое решение, в котором будут ссылки на все проекты, скажем, All.sln. Поэтому всякий раз, когда вам нужно найти внешние ссылки, вы открываете это решение All.sln и ищете ссылки.

У нас, вероятно, есть около 100 решений и один All.sln, который ссылается на все проекты из этих решений. Легко добавить все проекты из одного решения во все.sln: вы просто выбираете Add Existing Projects и выбираете один из этих 15 файлов решений. Вам нужно настроить тип файла в Add Existing Projects диалоговом окне, чтобы иметь возможность выбрать файл решения. Кроме того, чтобы упорядочить это большое решение, вы можете использовать папки решений.

Возможно, вы также захотите проверить NDepend.

Поскольку другой ответ достаточно прост для вашей непосредственной потребности, и я не хочу звучать как плохая реклама, я предоставляю заинтересованному читателю узнать больше об этом инструменте.

Чтобы немного подробнее остановиться на ответе Кристиана, инструмент NDepend действительно может помочь найти неиспользуемый код в базе кода .NET. Отказ от ответственности: я являюсь одним из разработчиков этого инструмента.

NDepend предлагает написать правило кода над запросом LINQ (CQLinq). Предлагается около 200 правил кода по умолчанию, 3 из которых предназначены для обнаружения неиспользуемого / нерабочего кода:

• Потенциально мертвые типы (следовательно, обнаруживать неиспользуемый класс, структуру, интерфейс, делегат …)
• Потенциально мертвые методы (следовательно, обнаруживать неиспользуемый метод, ctor, средство получения / установки свойств …)
• Потенциально мертвые поля

NDepend интегрирован в Visual Studio, таким образом, эти правила можно проверять / просматривать / редактировать прямо в IDE. Инструмент также может быть интегрирован в ваш процесс CI и может создавать отчеты, в которых будут показаны нарушенные правила и элементы кода-нарушителя.

Если вы нажмете на эти 3 ссылки выше, ведущие к исходному коду этих правил, вы увидите, что те, которые касаются типов и методов, немного сложны. Это потому, что они обнаруживают не только неиспользуемые типы и методы, но также типы и методы, используемые только неиспользуемыми нерабочими типами и методами (рекурсивными).

Это статический анализ, отсюда и префикс, потенциально присутствующий в именах правил. Если элемент code используется только посредством отражения, эти правила могут рассматривать его как неиспользуемый, что не так.

В дополнение к использованию этих 3 правил, я бы посоветовал измерять охват кода тестами и стремиться к полному охвату. Часто вы увидите, что код, который не может быть охвачен тестами, на самом деле является неиспользуемым / мертвым кодом, который можно безопасно отбросить. Это особенно полезно в сложных алгоритмах, где неясно, доступна ли ветвь кода или нет.