So finden Sie unbenutzte/Toter code in java-Projekten
https://stackoverflow.com/questions/162551
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Welche tools verwenden Sie, um zu finden unbenutzt/Toter code, bei großen java-Projekten?Unser Produkt wurde in der Entwicklung für einige Jahre, und es ist immer sehr schwer manuell zu erkennen-code, der nicht mehr in Verwendung.Wir wollen jedoch versuchen, Sie zu löschen, wie viel ungenutzte code wie möglich.
Anregungen für die Allgemeinen Strategien/Techniken (andere als spezifische Werkzeuge) sind auch willkommen.
Edit: Beachten Sie, dass wir bereits verwenden, die code-coverage-tools (Klee, IntelliJ), diese sind aber wenig hilfreich.Dead code noch unit-tests, und zeigt sich als abgedeckt.Ich denke, ein ideales Werkzeug identifizieren würde Cluster von code, der sehr wenig anderen code, der davon abhängig zu sein, so dass für docues manuelle Inspektion.
Lösung
Ich kann das laufende System Instrument zu halten Protokolle von Code-Nutzung, und starten Sie dann Code Inspektion, die nicht für Monate oder Jahre verwendet wird.
Wenn Sie zum Beispiel in nicht genutzten Klassen interessiert sind, können alle Klassen instrumentiert werden zu protokollieren, wenn Instanzen erstellt werden. Und dann ein kleines Skript dieser Protokolle gegen die komplette Liste der Klassen nicht verwendete Klassen finden vergleichen kann.
Natürlich, wenn Sie auf der Methode Ebene gehen, sollten Sie die Leistung im Auge behalten. Zum Beispiel könnten die Verfahren nur einloggen, um ihren ersten Gebrauch. Ich weiß nicht, wie dies am besten in Java getan. Wir haben dies in Smalltalk gemacht, die eine dynamische Sprache ist und somit ermöglichen Code-Änderung zur Laufzeit. Wir Instrument alle Methoden mit einem Logging-Aufruf und deinstallieren Sie den Logging-Code nach einer Methode zum ersten Mal angemeldet wurde, so dass nach einiger Zeit nicht mehr Leistungseinbußen auftreten. Vielleicht kann eine ähnliche Sache in Java mit statischem boolean Flags erfolgen ...
Andere Tipps
Ein Eclipse-Plugin, das einigermaßen gut ist nicht verwendeter Code Detector funktioniert.
Es verarbeitet ein ganzes Projekt oder eine bestimmte Datei und zeigt verschiedene ungebraucht / tote Code Methoden, sowie darauf hindeutet Sichtbarkeit Änderungen (das heißt eine öffentliche Methode, die geschützt werden könnte oder privat).
Ich bin überraschter ProGuard hier nicht erwähnt wurde. Es ist eines der reifsten Produkte um.
ProGuard ist eine freie Java-Klasse-Datei Shrinker, Optimierer, obfuscator, und preverifier. Es erkennt und entfernt ungenutzte Klassen, Felder, Methoden und Attribute. Es optimiert Bytecode und entfernt ungenutzte Anleitung. Es benennt die übrigen Klassen, Felder und Methoden mit kurzen sinnlosen Namen. Schließlich preverifies es die verarbeiteten Code für Java 6 oder für Java Micro Edition.
Einige Anwendungen von ProGuard sind:
- Erstellen kompakten Code, für kleinere Code-Archive, schnellere Übertragung über Netzwerke, schnelleren Laden und kleinere Speicher Fußspuren.
- machen Programme und Bibliotheken schwieriger Reverse-Engineering.
- Listing toten Code, so kann es aus dem Quellcode entfernt werden.
- Retargeting und preverifying bestehende Klassendateien für Java 6 oder höher, um vollen Nutzen aus ihrem schnelleren Laden von Klassen zu nehmen.
Hier Beispiel für Liste von totem Code: https: // www. guardsquare.com/en/products/proguard/manual/examples#deadcode
Eine Sache, ich bin dafür bekannt in Eclipse, auf einer einzigen Klasse zu tun, ist es, alle ihre Methoden zu privaten ändern und dann sehen, was Beschwerden, die ich bekommen. Für Methoden, die verwendet werden, werden diese Fehler provozieren, und ich sie zurück auf den niedrigsten Zugriffsebene ich kann. Für Methoden, die nicht verwendet werden, werden diese Warnungen über nicht verwendete Methoden provozieren, und die können dann gelöscht werden. Und als Bonus, oft einige öffentliche Methoden finden, kann und soll privat gemacht werden.
Aber es ist sehr Handbuch.
Wir haben damit begonnen Bugs verwenden Finden einige der Funk in unserer Code-Basis des identifizieren Zielreichen Umwelt für Refactoring. Ich würde auch Struktur 101 zu identifizieren Punkte in Ihrer Code-Basis der Architektur betrachten, die zu kompliziert sind, so dass Sie wissen wo die wirklichen Sümpfe sind.
In der Theorie kann man nicht deterministisch nicht verwendeten Code finden. Theres einen mathematischen Beweis dafür (na ja, das ist ein Spezialfall eines allgemeineren Satzes). Wenn Sie neugierig sind, das Halteproblem suchen.
Dies kann sich in vielerlei Hinsicht in Java-Code manifestieren:
- Laden Klassen basierend auf Benutzereingaben, Konfigurationsdateien, Datenbankeinträge, etc;
- Laden von externem Code;
- Passing Objektbäume zu Bibliotheken von Drittanbietern;
- etc.
Dass gesagt wird, verwende ich IDEA IntelliJ als meine IDE der Wahl und es verfügt über umfangreiche Analysetools für findign Abhängigkeiten zwischen den Modulen, nicht verwendeten Methoden, ungebraucht Mitglieder, nicht verwendeten Klassen, etc. Seine ziemlich intelligent zu wie eine private Methode, die ‚isn t genannt wird markiert ungenutzt, sondern eine öffentliche Methode erfordert weitergehende Analyse.
In Eclipse-Springen Fenster> Einstellungen> Java> Compiler> Fehler / Warnungen
und ändern Sie alle von ihnen zu Fehlern. Fix alle Fehler. Dies ist die einfachste Art und Weise. Das Schöne ist, dass diese Sie den Code bereinigen können, wie Sie schreiben.
Bildschirm Eclipse-Code:
IntelliJ hat Code-Analyse-Tools zur Code-Erkennung, die nicht verwendet wird. Sie sollten versuchen, so viele Felder / Methoden / Klassen als nicht-öffentlich wie möglich zu machen, und das wird mehr nicht verwendete Methoden / Felder / Klassen zeigt
Ich würde auch versuchen, doppelten Code als einen Weg zu finden, Codevolumen zu reduzieren.
Mein letzter Vorschlag ist, versuchen Open-Source-Code zu finden, wenn verwendet, würde der Code einfacher machen.
Die Structure101 slice Perspektive eine Liste geben (und Abhängigkeitsgraph) einer „Waisen“ oder „orphan Gruppen “ von Klassen oder Pakete, die keine Abhängigkeiten zu oder von der „main“ Cluster haben.
DCD ist kein Plugin für einige IDE kann aber von Ameise oder Standalone betrieben werden. Es sieht aus wie ein statisches Werkzeug und kann es tun, was PMD und FindBugs nicht . Ich werde es versuchen.
P. S. Wie weiter unten in einem Kommentar erwähnt, lebt das Projekt jetzt in GitHub .
Es gibt Werkzeuge, die Profil-Code und Code-Coverage-Daten zur Verfügung stellen. Auf diese Weise können Sie sehen (als Code ausgeführt wird), wie viel davon genannt wird. Sie können jedes dieser Werkzeuge bekommen, um herauszufinden, wie viel Waise Code, den Sie haben.
- ist FindBugs für diese Art der Sache hervorragend.
- PMD (Projekt Mess Detector) ist ein weiteres Werkzeug, das verwendet werden kann.
Doch weder finden public static Methoden , die in einem Arbeitsbereich nicht verwendet werden. Wenn jemand von einem solchen Werkzeug weiß, dann lass es mich wissen.
Benutzer Coverage Tools, wie EMMA. Aber es ist nicht statisch Werkzeug (das heißt es erfordert, um tatsächlich die Anwendung durch Regressionstests laufen und durch alle möglichen Fehlerfälle, die, nun ja, unmöglich :))
Dennoch EMMA ist sehr nützlich.
Code-coverage-tools, wie Emma, Cobertura, und Clover, wird instrument Ihren code ein und notieren Sie, welche Teile Sie wird aufgerufen durch ausführen einer Reihe von tests.Dies ist sehr nützlich, und sollte ein wichtiger Teil Ihrer Entwicklung.Es wird Ihnen helfen, herauszufinden, wie gut Ihre test-suite deckt Ihren code.
Dies ist jedoch nicht das gleiche wie zu identifizieren echte tote code.Es identifiziert nur code, der verdeckt ist (oder nicht) von tests.So können Sie sich false positives (wenn die tests nicht decken alle Szenarien), als auch false negatives (also, wenn Sie Ihre tests auf code, der eigentlich nie in einem realen Welt-Szenario).
Ich Stelle mir den besten Weg, um wirklich zu identifizieren, Toten code zu instrumentieren Sie Ihren code mit einer coverage-tool in einer live-Umgebung und um zu analysieren, code-coverage über einen längeren Zeitraum von Zeit.
Wenn Sie runnning in a load-balanced redundante Umgebung (und wenn nicht, warum nicht?) dann habe ich angenommen, es wäre sinnvoll, die einzige instrument, das eine Instanz der Anwendung und konfigurieren Sie den load balancer so, dass eine zufällige, aber kleinen Teil der Benutzer auf die instrumentierte Instanz.Wenn Sie dieses über einen längeren Zeitraum (bis machen sicher, dass Sie abgedeckt habe alles realen Welt Anwendungsszenarien - wie saisonale Schwankungen), Sie sollten in der Lage sein, genau zu sehen, welche Bereiche von Ihrem code aufgerufen werden, die unter realen Welt Verwendung und die Teile sind wirklich nie aufgerufen und somit dead code.
Ich habe noch nie persönlich gesehen, die dies getan haben, und wissen nicht, wie die oben genannten tools können verwendet werden, um instrument und analysieren von code, der nicht aufgerufen wird, durch eine test-suite - aber ich bin sicher, Sie können.
Es ist ein Java-Projekt - Dead Code Detector (DCD). Für Quellcode scheint es nicht gut zu funktionieren, aber für .jar-Datei - es ist wirklich gut. Darüber hinaus können Sie nach Klasse filtern und durch Verfahren.
Netbeans hier ist ein Plugin für Netbeans dead-Code-Detektor .
Es wäre besser, wenn sie in Verbindung bringen könnte und die nicht verwendeten Code zu markieren. Sie können hier abstimmen und kommentieren: Bug 181458 - Finden Sie nicht genutzte öffentliche Klassen, Methoden, Felder
Eclipse kann zeigen / Highlight-Code, der nicht erreicht werden kann. JUnit können Sie Codeabdeckung zeigen, aber Sie würden einige Tests müssen und entscheiden, ob der betreffende Test fehlt oder der Code ist wirklich ungenutzt.
fand ich Clover Coverage Tool die Instrumente Code und zeigt den Code, der verwendet wird, und das ist ungenutzt. Im Gegensatz zu Google CodePro Analytics, es funktioniert auch für WebApplications (nach meiner Erfahrung und ich kann über Google CodePro falsch sein).
Der einzige Nachteil, dass ich bemerkt, dass es nicht Java-Schnittstellen in Betracht zieht nimmt.
Ich verwende Doxygen einen Methodenaufruf Karte zu entwickeln, Methoden zu finden, die nie aufgerufen werden. Auf der Grafik sehen Sie Inseln Methode Cluster ohne Anrufer finden. Dies gilt nicht für Bibliotheken arbeiten, da man immer von einem Haupteinstiegspunkt beginnen muß.
