Wie gut funktioniert statische Code-Analyse mit Spring und anderen Abstraktionen?

Question

Ich bin in einer Situation, in der ich mich mindestens etwas anstrengen muss, um nie verwendeten Code aus meinem Quellcode zu entfernen. Die allgemeine Präferenz besteht darin, ein Tool zur statischen Codeanalyse zu verwenden. Wir hatten viel Glück damit in anderen Projekten, aber die Leute, von denen ich höre, sind hauptsächlich C/C++ - Entwickler, die an Code auf Geräteebene arbeiten.

Ich bin ein Webentwickler, der an einem Java EE System arbeitet. Das bevorzugte Werkzeug für die Analyse ist Coverity Prevent, obwohl ich mich wahrscheinlich für etwas anderes einsetzen könnte, wenn ich einen starken Beweis dafür erbringen könnte, dass es für die Technologie, mit der wir entwickeln, besser geeignet ist.

Ich finde mich zweifelhaft - Was ist die Effektivität der statischen Code-Analyse für toten Code, wenn Sie gegen ein System mit vielen Abstraktionen laufen? Zum Beispiel verwenden wir Spring 's Abhängigkeitsinjektion, sowie JSF. In beiden Fällen gibt es keine einfache Möglichkeit, die Funktionsaufrufe vom Front-End zum Back-End zu verfolgen und ein vollständiges Bild davon zu zeichnen, was aufgerufen wird und was nicht.

Ich bin sehr besorgt, dass die False Positives auf eine tote Code-Überprüfung den Wert überwiegen wird, das Tool an erster Stelle auszuführen.

Was ist die Erfahrung mit diesem Szenario? Haben Sie es geschafft, einen Nutzen aus einem statischen Codeanalyse-Tool zu ziehen, wenn Ihre Architektur viele Abstraktionen verwendet hat? Gab es etwas, was Sie tun mussten, um es mit einem Minimum an Fehlalarmen zum Laufen zu bringen?

Answer 1

Ich arbeitete zuvor bei Coverity, auf dem statischen Analyseprodukt von Java.

Diese spezielle Aufgabe, toten Code zu finden, kann für einen statischen Analysator ein Treffer oder Fehltreffer sein. Insbesondere bei toten Methoden, also einer Methode, die zur Laufzeit nicht aufgerufen werden kann, ist die False-Positive-Rate sehr hoch, ohne dass viel von Ihnen abgestimmt wird, um den statischen Analysator über alle dynamischen Eingangspunkte zu informieren.

Bei einem Deadcode innerhalb einer Methode sollten die Ergebnisse ziemlich gut sein, wenn Ihr Analysator über diese Fähigkeit verfügt, da die Analyse keine Annahmen über die Eingabedaten trifft. Selbst wenn alle möglichen Eingaben angenommen werden, ist es möglich, einen toten Code zu finden, bei dem korrelierte Logik verhindert, dass bestimmte Zweige genommen werden.

Answer 2

Statische Codeanalyse sollte in jedem Fall nur durchgeführt werden, wenn Sie den Analyseprozess und den Code vollständig verstanden haben. Das Problem ist einfach, dass es nur grob ist und Annahmen bietet. Weder eine Lösung, noch eine vollständig genaue Überprüfung auf Schwachstellen. Sie müssen die Fehlalarme mit anderen Testmethoden ermitteln können.

Der Wert eines statischen Codeanalysators ist kein Code-Review. Um toten Code zu eliminieren, würde ich Code-Coverage verwenden, um das zu profilieren. - In Ihrem Fall - Sie erwähnten viele Abstraktionen ... Ich glaube ziemlich, statische Code-Analyse wird nicht genug sein.

Answer 3

Sie können Testabdeckungswerkzeuge (dynamische Analyse) verwenden, um zu ermitteln, welcher Code Ihres Systems ist; Das Komplement ist ein Code, der tot sein könnte (er wurde nicht ausgeführt!) und muss überprüft werden (z. B. kann es einige falsche Positive geben). Je mehr Übung Sie Ihrem System geben, desto geringer ist die False-Positive-Rate.

Ein Java-Test-Coverage-Tool, das diese Daten für Sie sammeln kann, finden Sie unter here.

Wenn Sie die Fehlalarme minimieren möchten, sollten Sie das statische Analysetool und die Testabdeckung ausführen und die Schnittmenge verwenden.

Im Allgemeinen muss zur Erkennung des toten Codes X nachgewiesen werden, dass es keine Bedingung gibt, unter der X aufgerufen wird. Das ist schwer (theoretisch unmöglich), wenn sie mit einer Turing-Maschine und IF-Anweisungen der Form

if (Turing(..)) then call X(); 

konfrontiert, weshalb statische Analyse-Tools haben eine hohen falsch positive Raten für diese.

In vielen Fällen jedoch ist "toter Code" wirklich nur Code, der einfach keine Möglichkeit hat, ihn aufzurufen ("deactive code" im FAA-Sprachgebrauch). Das heißt, während X definiert ist, gibt es einfach keine Aufrufe von X (oder Zugriffe, wenn X ein Datenelement ist) an irgendeiner Stelle im System, direkt oder indirekt. Diese sind für statische Analysewerkzeuge einfacher zu erkennen, wenn die dynamische Klassenbelastung und -reflexion in Java unübersichtlich wird (was das Problem der deaktivierten Codeanalyse angesichts unbekannter, aber ladbarer Klassen unmöglich macht).

Ignoriert man diese Komplikationen, kann man statische Analysetools finden, die deactive Code in großen Java-Systemen erkennen und melden. Ein solches Tool muss das gesamte Java-System auf einmal verarbeiten, da sonst möglicherweise ein Verweis in dem einen Modul existiert, das nicht in der Analyse enthalten ist. Wir haben eine "deactive" code detector and remover gebaut können Ihnen sogar Ihren Quellcode zurück mit allen deactive-Code automatisch entfernt, sowie berichten, was nicht referenziert ist. Sie untersuchen den Bericht und entscheiden, ob Sie den bereinigten Code verwenden oder einen Zugriff auf eine scheinbar nicht verwendete Entität hinzufügen möchten.

Answer 4

Bei der statischen Analyse ist mir kein statisches Analysewerkzeug bekannt, das tatsächlich mit Abstraktionen arbeitet. Sie werden höchstwahrscheinlich ein Modul schreiben müssen, das sich in den Analyseprozess einklinkt, und Gründe dafür, wie Sie Abstraktionen verwenden.

Und ich bezweifle, dass die Anwesenheit von totem Code mehr kostet.