Как найти неиспользуемый/мертвый код в проектах Java

Ответ 1

Я хотел бы использовать текущую систему для ведения журналов использования кода, а затем начать проверку кода, который не используется в течение нескольких месяцев или лет.

Например, если вас интересуют неиспользуемые классы, все классы могут быть использованы для регистрации при создании экземпляров. А затем небольшой script мог сравнить эти журналы с полным списком классов, чтобы найти неиспользуемые классы.

Конечно, если вы идете на уровне метода, вы должны помнить о производительности. Например, методы могут только регистрировать их первое использование. Я не знаю, как это лучше всего делать на Java. Мы сделали это в Smalltalk, который является динамическим языком и, таким образом, позволяет изменять код во время выполнения. Мы обрабатываем все методы с помощью журнала и удаляем код регистрации после того, как метод был зарегистрирован в первый раз, поэтому через какое-то время больше не возникает штрафов за производительность. Возможно, аналогичная вещь может быть выполнена на Java со статическими булевыми флагами...

Ответ 2

Плагин Eclipse, который работает достаточно хорошо, Unused Code Detector.

Он обрабатывает весь проект или определенный файл и показывает различные методы неиспользуемого/мертвого кода, а также предлагает изменения видимости (т.е. общедоступный метод, который может быть защищен или закрыт).

Ответ 3

CodePro был недавно выпущен Google с проектом Eclipse. Это бесплатно и очень эффективно. У плагина есть функция Find Dead Code с одной или несколькими точками входа. Хорошо работает.

Ответ 4

Я удивлен, что ProGuard здесь не упоминается. Это один из самых зрелых продуктов вокруг.

ProGuard - это бесплатный инструмент для сжатия файлов класса Java, оптимизатор, обфускатор и предварительный анализатор. Он обнаруживает и удаляет неиспользуемые классы, поля, методы и атрибуты. Он оптимизирует байт-код и удаляет неиспользуемые инструкции. Переименовывает остальные классы, поля и методы, используя короткие бессмысленные имена. Наконец, он предварительно проверяет обработанный код для Java 6 или для Java Micro Edition.

Некоторые виды использования ProGuard:

• Создание более компактного кода для небольших архивов кода, более быстрая передача по сети, более быстрая загрузка и меньшие объемы памяти.
• Создание программ и библиотек сложнее для обратного проектирования.
• Перечисление мертвого кода, поэтому его можно удалить из исходного кода.
• Перенацеливание и предварительная проверка существующих файлов классов для Java 6 или более поздней версии, чтобы в полной мере воспользоваться их более быстрой загрузкой классов.

Вот пример для списка мертвых кодов: https://www.guardsquare.com/en/products/proguard/manual/examples#deadcode

Ответ 5

Одна вещь, которую я знаю в Eclipse, в одном классе, сводит все свои методы к частным, а затем вижу, какие жалобы я получаю. Для методов, которые используются, это вызовет ошибки, и я верну их на самый низкий уровень доступа, который я могу. Для неиспользуемых методов это вызовет предупреждения о неиспользуемых методах, и их можно будет удалить. И в качестве бонуса вы часто находите некоторые общедоступные методы, которые могут и должны быть частными.

Но он очень ручной.

Ответ 6

Используйте инструмент для тестирования, чтобы настроить свою кодовую базу, а затем запустить приложение, а не тесты.

Emma и Eclemma даст вы хорошо сообщаете, какой процент от того, какие классы запускаются для любого запуска кода.

Ответ 7

Мы начали использовать Найти ошибки, чтобы помочь определить некоторые из фанков в нашей целевой среде с базой кода для рефакторинга. Я бы также рассмотрел Structure 101, чтобы идентифицировать пятна в вашей архитектуре кода, которые слишком сложны, поэтому вы знаете, где находятся настоящие болота.

Ответ 8

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

Это может проявляться в Java-коде по-разному:

• Загрузка классов на основе ввода пользователем, файлов конфигурации, записей в базе данных и т.д.
• Загрузка внешнего кода;
• Передача деревьев объектов в сторонние библиотеки;
• и др.

Как я уже сказал, я использую IDEA IntelliJ как свою IDE-выбор, и у нее есть обширные инструменты анализа для зависимостей findign между модулями, неиспользуемыми методами, неиспользуемыми членами, неиспользуемыми классами и т.д. Его довольно интеллектуальный тоже как частный метод, t называется помеченным, но общедоступный метод требует более подробного анализа.

Ответ 9

В Eclipse Перейти к Windows > Предпочтения > Java > Компилятоp > Ошибки/Предупреждения
и изменить их все на ошибки. Исправьте все ошибки. Это самый простой способ. Красота заключается в том, что это позволит вам очистить код при записи.

Снимок экрана Код Eclipse:

Ответ 10

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

Я также попытался бы найти дубликат кода как способ уменьшения объема кода.

Мое последнее предложение - попытаться найти код с открытым исходным кодом, который, если его использовать, сделает ваш код более простым.

Ответ 11

Структура101 перспектива среза даст список (и график зависимостей) любых "сирот" или "сирот groups" классов или пакетов, которые не имеют зависимости от кластера или из основного кластера.

Ответ 12

DCD не является плагином для какой-то IDE, но может быть запущен из ant или standalone. Он выглядит как статический инструмент и может делать то, что PMD и FindBugs не могут. Я попробую.

PS Как уже упоминалось в комментарии ниже, проект сейчас живет в GitHub.

Ответ 13

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

Ответ 14

• FindBugs отлично подходит для такого рода вещей.
• PMD (детектор проекта Messenger) - еще один инструмент, который можно использовать.

Однако ни один из них не может найти общедоступные статические методы, которые не используются в рабочей области. Если кто-нибудь знает о таком инструменте, пожалуйста, дайте мне знать.

Ответ 15

Инструменты покрытия пользователя, такие как EMMA. Но это не статический инструмент (т.е. Он требует фактически запускать приложение через регрессионное тестирование и через все возможные случаи ошибок, что, возможно, невозможно:))

Тем не менее EMMA очень полезна.

Ответ 16

Инструменты покрытия кода, такие как Emma, ​​Cobertura и Clover, будут обрабатывать ваш код и записывать, какие части его вызывают, запуская набор тестов. Это очень полезно и должно быть неотъемлемой частью вашего процесса разработки. Это поможет вам определить, насколько хорошо ваш набор тестов охватывает ваш код.

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

Я предполагаю, что лучший способ действительно идентифицировать мертвый код - это инструмент для вашего кода с инструментом покрытия в живой среде и для анализа покрытия кода в течение длительного периода времени.

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

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

Ответ 17

Существует проект Java - Детектор мертвых кодов (DCD). Для исходного кода это не работает хорошо, но для файла .jar - это действительно хорошо. Кроме того, вы можете фильтровать по классам и по методу.

Ответ 18

Netbeans - это плагин для Netbeans детектор мертвого кода.

Было бы лучше, если бы он мог ссылаться и выделять неиспользуемый код. Вы можете проголосовать и прокомментировать здесь: Ошибка 181458 - Поиск неиспользуемых общедоступных классов, методов, полей

Ответ 19

Eclipse может показать/выделить код, который не может быть достигнут. JUnit может показать вам покрытие кода, но вам потребуются некоторые тесты, и вам нужно решить, нет ли соответствующего теста или код действительно не используется.

Ответ 20

Я нашел инструмент для покрытия Clover, который кодирует код и выделяет код, который используется и который не используется. В отличие от Google CodePro Analytics, он также работает для WebApplications (согласно моему опыту, и я могу ошибаться в Google CodePro).

Единственный недостаток, который я заметил, заключается в том, что он не учитывает интерфейсы Java.

Ответ 21

Я использую Doxygen для разработки карты вызова метода для поиска методов, которые никогда не вызываются. На графике вы найдете острова кластеров методов без абонентов. Это не работает для библиотек, так как вам всегда нужно начинать с какой-то основной точки входа.