Як знайти невикористаний / мертвий код у 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 - це змінити всі його методи на приватні, а потім побачити, які скарги я отримую. Для методів, які використовуються, це спровокує помилки, і я поверну їх до найнижчого рівня доступу. Для невикористаних методів це спровокує попередження про невикористані методи, і їх можна буде видалити. І як бонус, ви часто знаходите деякі публічні методи, які можна і потрібно зробити приватними.

Але це дуже керівництво.

Використовуйте інструмент тестового покриття для інструменту вашої кодової бази, а потім запустіть саме додаток, а не тести.

Емма та Еклемма дадуть вам приємні звіти про те, який відсоток класів виконується для будь-якого запуску коду.

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

Теоретично ви не можете детерміновано знайти невикористаний код. Це математичне підтвердження цього (ну, це особливий випадок більш загальної теореми). Якщо вам цікаво, знайдіть проблему зупинки.

Це може проявлятися в коді Java багатьма способами:

• Завантаження класів на основі введення користувача, конфігураційних файлів, записів бази даних тощо;
• Завантаження зовнішнього коду;
• Передача дерев об'єктів третім сторонам бібліотекам;
• тощо.

Зважаючи на це, я використовую IDEA IntelliJ як мій вибір IDE, і він має широкі інструменти аналізу для знаходження залежності між модулями, невикористаними методами, невикористаними членами, невикористаними класами і т.д. з тегом невикористаний, але публічний метод вимагає більш широкого аналізу.

У Eclipse Goto Windows> Налаштування> Java> Компілятор> Помилки / попередження
та змініть всі на помилки. Виправте всі помилки. Це найпростіший спосіб. Краса в тому, що це дозволить вам очистити код під час написання.

Код затемнення коду екрана:

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

Я б також спробував знайти дублікат коду як спосіб зменшення обсягу коду.

Моя остання пропозиція - спробувати знайти відкритий код, який, якщо він буде використаний, полегшить ваш код.

У перспективі фрагмента Structure101 буде подано список (і графік залежності) будь-яких "сиріт" або "осиротілих груп " класів або пакетів, які не залежать від або "основного" кластера.

DCD не є плагіном для деяких IDE, але він може бути запущений з мурашки або окремо. Це схоже на статичний інструмент, і він може робити те, що не може PMD та FindBugs . Я спробую.

PS Як зазначено в коментарі нижче, Проект зараз живе в GitHub .

Є інструменти, які кодують профіль і надають дані про покриття коду. Це дозволяє вам побачити (як виконується код), яка частина його викликається. Ви можете отримати будь-який з цих інструментів, щоб дізнатися, скільки у вас є сиротний код.

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

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

Інструменти охоплення користувачів, такі як EMMA. Але це не статичний інструмент (тобто він вимагає насправді запустити додаток через регресійне тестування та через усі можливі випадки помилок, що, ну, неможливо :))

Все-таки EMMA дуже корисна.

Інструменти покриття коду, такі як Емма, Кобертура та Конюшина, будуть інструментувати ваш код і записувати, які його частини викликаються, виконавши набір тестів. Це дуже корисно і має бути невід'ємною частиною вашого процесу розвитку. Це допоможе вам визначити, наскільки добре ваш тестовий набір покриває ваш код.

Однак це не те саме, що ідентифікувати реальний мертвий код. Він ідентифікує лише код, який охоплюється (або не охоплюється) тестами. Це може призвести до помилкових позитивних результатів (якщо ваші тести не охоплюють усіх сценаріїв), а також помилкових негативів (якщо ваш тест код доступу, який насправді ніколи не використовується в реальному сценарії).

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

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

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

Є проект Java - детектор мертвого коду (DCD). Для вихідного коду він, здається, не працює добре, але для .jar-файла - це справді добре. Крім того, ви можете фільтрувати за класом та за методом.

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

Було б краще, якби він міг посилатись і виділяти невикористаний код. Ви можете голосувати та коментувати тут: Bug 181458 - Знайдіть невикористані загальнодоступні класи, методи, поля

Затьмарення може показати / виділити код, якого неможливо досягти. JUnit може показати вам покриття коду, але вам знадобляться деякі тести, і вам доведеться вирішити, чи немає відповідного тесту чи код справді не використовується.

Я знайшов інструмент покриття Clover, котрий інструменти кодує і виділяє код, який використовується, а який не використовується. На відміну від Google CodePro Analytics, він також працює для WebApplications (на мій досвід, і я можу помилятися щодо Google CodePro).

Єдиний недолік, який я помітив, - це те, що він не враховує інтерфейси Java.

Я використовую Doxygen для розробки карти викликів методів, щоб знайти методи, які ніколи не викликаються. На графіку ви знайдете острови кластерних методів без викликаючих. Це не працює для бібліотек, оскільки завжди потрібно починати з якоїсь основної точки входу.