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

Какие инструменты вы используете, чтобы найти неиспользуемый / мертвый код в больших проектах Java? Наш продукт разрабатывался в течение нескольких лет, и очень трудно вручную обнаружить код, который больше не используется. Однако мы стараемся удалить как можно больше неиспользуемого кода.

Предложения для общих стратегий / методов (кроме конкретных инструментов) также приветствуются.

Изменить: Обратите внимание, что мы уже используем инструменты покрытия кода (Clover, IntelliJ), но они мало помогают. У мертвого кода все еще есть юнит-тесты, и он отображается как покрытый. Я предполагаю, что идеальный инструмент идентифицирует кластеры кода, у которых очень мало другого кода в зависимости от него, что позволяет проводить проверку документов вручную.

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

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

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

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

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

CodePro был недавно выпущен Google вместе с проектом Eclipse. Это бесплатно и очень эффективно. Плагин имеет функцию « Найти мертвый код » с одной / несколькими точками входа. Работает довольно хорошо.

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

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

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

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

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

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

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

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

Эмма и Эклемма дадут вам хорошие отчеты о том, какой процент классов выполняется для любого данного прогона кода.

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

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

Это может проявиться в коде Java разными способами:

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

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

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

Скриншот Eclipse Code:

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

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

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

Перспектива среза Structure101 предоставит список (и граф зависимостей) любых «сирот» или « групп сирот » классов или пакетов, которые не имеют зависимостей от «основного» кластера или от него.

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

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

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

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

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

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

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

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

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

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

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

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

Есть Java-проект - Dead Code Detector (DCD). Для исходного кода это, кажется, не работает хорошо, но для файла .jar - это действительно хорошо. Плюс вы можете фильтровать по классу и по методу.

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

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

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

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

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

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