Как найти неиспользуемый / мертвый код в проектах Java
https://stackoverflow.com/questions/162551
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Какие инструменты вы используете для поиска неиспользуемого / мертвого кода в больших проектах Java?Наш продукт разрабатывается уже несколько лет, и становится очень сложно вручную обнаружить код, который больше не используется.Однако мы стараемся удалять как можно больше неиспользуемого кода.
Также приветствуются предложения по общим стратегиям / методам (отличным от конкретных инструментов).
Редактировать: Обратите внимание, что мы уже используем инструменты покрытия кода (Clover, IntelliJ), но они мало помогают.Мертвый код все еще содержит модульные тесты и отображается как покрытый.Я думаю, идеальным инструментом было бы идентифицировать кластеры кода, от которых зависит очень мало другого кода, что позволяет проверять документы вручную.
Решение
Я бы поручил работающей системе вести журналы использования кода, а затем начать проверять код, который не используется месяцами или годами.
Например, если вас интересуют неиспользуемые классы, все классы могут быть снабжены инструментарием для регистрации при создании экземпляров. Затем небольшой скрипт может сравнить эти журналы с полным списком классов, чтобы найти неиспользуемые классы.
Конечно, если вы переходите на уровень метода, вы должны помнить о производительности. Например, методы могут регистрировать только свое первое использование. Я не знаю, как это лучше всего сделать в Java. Мы сделали это в Smalltalk, который является динамическим языком и, таким образом, позволяет модифицировать код во время выполнения. Мы применяем все методы к вызову регистрации и удаляем код регистрации после того, как метод был зарегистрирован в первый раз, таким образом, через некоторое время больше не происходит ухудшения производительности. Возможно, подобное можно сделать в Java с помощью статических логических флагов ...
Другие советы
Плагин Eclipse, который работает достаточно хорошо, это Детектор неиспользуемого кода .
Он обрабатывает весь проект или конкретный файл и показывает различные неиспользуемые / неработающие методы кода, а также предлагает изменения видимости (то есть публичный метод, который может быть защищен или закрыт).
CodePro недавно был выпущен Google вместе с проектом Eclipse. Это бесплатно и очень эффективно. Плагин имеет функцию Поиск мертвого кода с одной или несколькими точками входа. (ы). Работает довольно хорошо.
Я удивлен Предусмотрительный здесь об этом не упоминалось.Это один из самых зрелых продуктов в мире.
Предусмотрительный является бесплатным средством сжатия файлов Java-класса, оптимизатором, обфускатором и предварительной проверкой.Он обнаруживает и удаляет неиспользуемые классы, поля, методы и атрибуты.Он оптимизирует байт-код и удаляет неиспользуемые инструкции.Он переименовывает остальные классы, поля и методы используя короткие бессмысленные имена.Наконец, выполняется предварительная проверка обработанного кода для Java 6 или для Java Micro Edition.
Некоторые области применения ProGuard заключаются в следующем:
- Создание более компактного кода для создания небольших архивов кода, более быстрой передачи по сетям, более быстрой загрузки и уменьшения объема памяти следы.
- Усложнение реинжиниринга программ и библиотек.
- Перечисление мертвого кода, чтобы его можно было удалить из исходного кода.
- Перенацеливание и предварительная проверка существующих файлов классов для Java 6 или более поздней версии, чтобы в полной мере воспользоваться преимуществами более быстрой загрузки классов.
Вот пример для списка мертвого кода: https://www.guardsquare.com/en/products/proguard/manual/examples#deadcode
Одна вещь, которую я, как известно, делал в Eclipse для одного класса, - это поменять все его методы на приватные, а затем посмотреть, какие жалобы я получаю. Для используемых методов это вызовет ошибки, и я верну их к самому низкому уровню доступа. Для методов, которые не используются, это вызовет предупреждения о неиспользуемых методах, которые затем могут быть удалены. И в качестве бонуса вы часто находите некоторые публичные методы, которые можно и нужно сделать приватными.
Но это очень вручную.
Мы начали использовать Поиск ошибок , чтобы помочь идентифицировать некоторые фанки в нашей целевой базе кода среда для рефакторинга. Я также хотел бы рассмотреть Structure 101 , чтобы определить слишком сложные в вашей архитектуре кода области, так что вы знаете, где настоящие болота.
Теоретически, вы не можете детерминированно найти неиспользуемый код.Есть математическое доказательство этого (ну, это частный случай более общей теоремы).Если вам интересно, посмотрите на проблему остановки.
Это может проявляться в коде Java многими способами:
- Загрузка классов на основе пользовательского ввода, конфигурационных файлов, записей базы данных и т. Д;
- Загрузка внешнего кода;
- Передача деревьев объектов сторонним библиотекам;
- и т.д.
При этом я использую IDEA IntelliJ в качестве своей среды разработки, и она имеет обширные инструменты анализа для определения зависимостей между модулями, неиспользуемыми методами, неиспользуемыми членами, неиспользуемыми классами и т.д.Это тоже довольно разумно, например, частный метод, который не вызывается, помечен как неиспользуемый, но открытый метод требует более тщательного анализа.
В Eclipse Goto Windows > Настройки > Java > Компилятор > Ошибки / предупреждения
и измените их все на ошибки. Исправьте все ошибки. Это самый простой способ. Прелесть в том, что это позволит вам очистить код во время написания.
Код Eclipse для скриншотов:
IntelliJ имеет инструменты анализа кода для обнаружения кода, который не используется. Вы должны попытаться сделать как можно больше закрытых полей / методов / классов, и это покажет больше неиспользуемых методов / полей / классов
Я бы также попытался найти дублирующийся код для уменьшения объема кода.
Мое последнее предложение - попытаться найти открытый исходный код, который в случае его использования сделает ваш код проще.
Structurea01 перспектива среза предоставит список (и граф зависимостей) любых «сирот»; или " бесхозные группы " классов или пакетов, которые не имеют зависимостей от или от "main" кластер.
DCD не является плагином для какой-либо IDE, но может быть запущен из ant или автономно.Это выглядит как статичный инструмент и он может делать то, чего не могут PMD и FindBugs.Я обязательно попробую это сделать.
P.S.Как упоминалось в комментарии ниже, проект сейчас живет в ГитХаб.
Существуют инструменты, которые профилируют код и предоставляют данные покрытия кода. Это позволяет увидеть (по мере выполнения кода), сколько из этого вызывается. Вы можете получить любой из этих инструментов, чтобы узнать, сколько у вас есть потерянного кода.
- FindBugs отлично подходит для подобных вещей.
- PMD (Project Mess Detector) - это еще один инструмент, который можно использовать.
Однако ни один из них не может найти общедоступные статические методы которые не используются в рабочей области.Если кто-нибудь знает о таком инструменте, пожалуйста, дайте мне знать.
Инструменты покрытия пользователей, такие как EMMA. Но это не статический инструмент (т. Е. Он требует, чтобы фактически запустить приложение через регрессионное тестирование и через все возможные случаи ошибок, что, ну, в общем, невозможно :))
Тем не менее, EMMA очень полезна.
Инструменты покрытия кода, такие как Emma, Cobertura и Clover, обработают ваш код и запишут, какие его части вызываются, запустив набор тестов.Это очень полезно и должно быть неотъемлемой частью вашего процесса разработки.Это поможет вам определить, насколько хорошо ваш набор тестов охватывает ваш код.
Однако это не то же самое, что идентифицировать реальный мертвый код.Он идентифицирует только код, который покрывается (или не покрывается) тестами.Это может привести к ложноположительным результатам (если ваши тесты охватывают не все сценарии), а также к ложноотрицательным результатам (если ваши тесты обращаются к коду, который на самом деле никогда не используется в реальном сценарии).
Я полагаю, что лучший способ действительно идентифицировать мертвый код - это использовать инструмент покрытия вашего кода в среде реального выполнения и анализировать покрытие кода в течение длительного периода времени.
Если вы работаете в избыточной среде с балансировкой нагрузки (а если нет, то почему бы и нет?), То я полагаю, что имело бы смысл настроить только один экземпляр вашего приложения и настроить ваш балансировщик нагрузки таким образом, чтобы случайная, но небольшая часть ваших пользователей запускалась в вашем инструментированном экземпляре.Если вы делаете это в течение длительного периода времени (чтобы убедиться, что вы охватили все сценарии использования в реальном мире - например, сезонные колебания), вы должны быть в состоянии точно видеть, к каким областям вашего кода осуществляется доступ при использовании в реальном мире, а к каким частям действительно никогда не обращаются и, следовательно, мертвый код.
Я лично никогда не видел, как это делается, и не знаю, как вышеупомянутые инструменты можно использовать для измерения и анализа кода, который не вызывается через набор тестов, но я уверен, что это возможно.
Существует проект Java - детектор мертвого кода (DCD). Для исходного кода это, кажется, не работает хорошо, но для файла .jar - это действительно хорошо. Кроме того, вы можете фильтровать по классу и по методу.
Netbeans - это плагин для Netbeans детектор мертвого кода .
Было бы лучше, если бы он мог ссылаться и выделять неиспользуемый код. Вы можете голосовать и комментировать здесь: Ошибка 181458 - Найти неиспользуемые общедоступные классы, методы, поля
Eclipse может показывать / выделять код, который недоступен. JUnit может показать вам покрытие кода, но вам потребуются некоторые тесты и вы должны решить, отсутствует ли соответствующий тест или код действительно не используется.
Я нашел инструмент покрытия Clover, который инструментирует код и выделяет код, который используется и который не используется. В отличие от Google CodePro Analytics, он также работает для веб-приложений (по моему опыту, и я могу ошибаться в Google CodePro).
Единственный недостаток, который я заметил, это то, что он не учитывает интерфейсы Java.
Я использую Doxygen для разработки карты вызовов методов, чтобы найти методы, которые никогда не вызывались. На графике вы найдете острова кластеров методов без абонентов. Это не работает для библиотек, так как вам всегда нужно начинать с некоторой главной точки входа.
