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


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

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

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


Answers



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

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

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




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

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




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




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

Но это очень ручная работа.




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

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

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

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



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

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




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




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

Это может проявляться в коде Java во многих отношениях:

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

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




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




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

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

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




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

Скриншот Код Eclipse:




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







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

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




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

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

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

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

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




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

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







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




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

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




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




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