Umgang mit Einwänden: Die statische Analyse nimmt einen Teil der Arbeitszeit in Anspruch

Wenn wir auf Konferenzen und in Kommentaren zu Artikeln mit Personen sprechen, stoßen wir auf folgenden Einwand: Die statische Analyse verkürzt die Zeit zum Erkennen von Fehlern, nimmt jedoch die Zeit der Programmierer in Anspruch, was die Vorteile der Verwendung zunichte macht und sogar den Entwicklungsprozess verlangsamt. Lassen Sie uns diesen Einwand klären und versuchen zu zeigen, dass er unbegründet ist.

Die aus dem Kontext genommene Aussage "statische Analyse nimmt einen Teil der Arbeitszeit weg" ist richtig. Es dauert definitiv einige Zeit, die Warnungen des Analysators, die für neuen oder geänderten Code ausgegeben werden, regelmäßig zu überprüfen. Wir sollten jedoch die Idee fortsetzen: Die dafür aufgewendete Zeit ist jedoch viel geringer als die Zeit, die erforderlich ist, um Fehler mit anderen Methoden zu finden. Es ist noch schlimmer, sich über Fehler von Benutzern zu informieren.

Unit-Tests können hier eine sehr gute Analogie sein. Unit-Tests brauchen auch Zeit von Entwicklern, aber es ist nicht der Grund, sie nicht zu verwenden. Die Vorteile eines sichereren Codes mit besserer Qualität bei der Verwendung von Komponententests überwiegen die Kosten für deren Erstellung.

Eine weitere Analogie: Compiler-Warnungen. Dies ist im Allgemeinen ein sehr enges Thema, da Warnungen vor statischen Analysewerkzeugen in gewissem Maße als Erweiterung von Compiler-Warnungen betrachtet werden können. Wenn ein Programmierer eine Compiler-Warnung sieht, verbringt er natürlich einige Zeit damit. Er muss entweder den Code ändern oder einige Zeit damit verbringen, Warnungen zu unterdrücken, beispielsweise mit #pragma. Diese zeitliche Verpflichtung war jedoch nie der Grund, Compiler-Warnungen zu deaktivieren. Und wenn jemand das tut, wird es von anderen eindeutig als berufliche Unfähigkeit interpretiert.

Woher kommt jedoch die Angst, Zeit für Warnungen vor statischen Code-Analysatoren zu verschwenden?

Die Antwort ist sehr einfach. Programmierer, die mit dieser Methode noch nicht vertraut sind, verwechseln Teststarts und die regelmäßige Verwendung. Beim ersten Durchlauf geben alle Analysegeräte eine riesige Liste von Warnungen aus, die sogar beängstigend anzusehen ist. Der Grund ist, dass der Analysator noch nicht konfiguriert ist. Während ein konfigurierter Analysator eine kleine Anzahl von Fehlalarmen ausgibt, die regelmäßig verwendet werden. Mit anderen Worten, die meisten Warnungen weisen auf echte Fehler oder Codegerüche hin. Es ist nur wichtig, diese Konfiguration vorzunehmen. Dies ist der Trick, der einen statischen Analysator von einem zeitraubenden Übel in einen Freund und einen Assistenten verwandelt.

Jeder statische Analysator gibt zuerst viele falsch positive Ergebnisse aus. Dafür gibt es viele Gründe, und dieses Thema verdient einen separaten Artikel. Natürlich kämpfen sowohl Entwickler anderer Analysegeräte als auch unser Team gegen Fehlalarme. Trotzdem gibt es viele Warnungen, wenn Sie den Analysator nur zum ersten Mal für ein Projekt verwenden. Die gleiche Situation besteht übrigens bei Compiler-Warnungen. Angenommen, Sie haben ein großes Projekt, das Sie immer erstellt haben, beispielsweise mit dem Visual C ++ - Compiler. Nehmen wir an, das Projekt erwies sich auf wundersame Weise als portabel und mit GCC kompiliert. Trotzdem erhalten Sie eine Reihe von Warnungen von GCC. Leute, die in einem großen Projekt einen Compilerwechsel erlebt haben, verstehen, wovon ich spreche.

Niemand zwingt Sie jedoch dazu, nach dem Wechseln des Compilers oder nach dem Ausführen des Analysators ständig in den Warnhaufen zu stöbern. Der naheliegende nächste Schritt besteht darin, einen Compiler oder Analysator einzurichten. Diejenigen, die sagen, "Warnanalyse ist zeitaufwändig", bewerten die Komplexität der Einführung des Tools und denken nur an all diese Warnungen, die am Anfang überwunden werden müssen, aber nicht an die unkomplizierte regelmäßige Verwendung.

Das Einrichten von Analysatoren und Compilern ist nicht so schwierig und arbeitsintensiv, wie es Programmierer gerne tun. Wenn Sie ein Manager sind, hören Sie ihnen nicht zu. Sie sind nur faul. Der Programmierer kann stolz sagen, wie er 3 Tage lang nach einem vom Tester / Client gefundenen Fehler gesucht hat. Und das ist gut für ihn. Aus seiner Sicht ist es jedoch nicht akzeptabel, einen Tag damit zu verbringen, das Tool einzurichten. Danach wird ein solcher Fehler erkannt, bevor er in das Versionskontrollsystem gelangt.

Ja, nach dem Setup sind Fehlalarme vorhanden. Aber ihre Zahl ist übertrieben. Es ist durchaus möglich, einen Analysator so einzurichten, dass der Prozentsatz falsch positiver Ergebnisse 10% bis 15% beträgt. Das heißt, für 9 gefundene Fehler muss nur 1 Warnung als falsch unterdrückt werden. Wo ist hier also die "Zeitverschwendung"? Gleichzeitig sind 15% ein sehr realer Wert; Sie können mehr darüber in diesem Artikel lesen.

Es gibt noch eine Sache übrig. Ein Programmierer kann Einwände erheben:

Nehmen wir an, regelmäßige statische Analyseläufe sind wirklich effektiv. Aber was soll ich mit dem Lärm machen, den ich beim ersten Mal bekomme? Bei unserem großen Projekt können wir das Tool nicht für einen versprochenen Tag einrichten. Die Neukompilierung zur Überprüfung der nächsten Einstellungen dauert mehrere Stunden. Wir sind nicht bereit, ein paar Wochen damit zu verbringen.

Und das ist kein Problem, sondern ein Versuch, einen Grund zu finden, etwas Neues nicht einzuführen. Natürlich ist bei einem großen Projekt immer alles schwierig. Aber zuerst bieten wir Unterstützung und helfen, PVS-Studio in den Entwicklungsprozess zu integrieren. Und zweitens ist es nicht erforderlich, alle Warnungen sofort zu sortieren.

Wenn Ihre App funktioniert, sind die dort vorhandenen Fehler nicht so kritisch und leben wahrscheinlich in selten verwendetem Code. Es wurden bereits schwerwiegende offensichtliche Fehler gefunden und mit langsameren und teureren Methoden behoben. Ich werde unten in der Notiz darüber schreiben. Das ist jetzt nicht von großer Bedeutung. Es macht keinen Sinn, massive Änderungen am Code vorzunehmen und viele unbedeutende Fehler zu korrigieren. Bei einem so großen Refactoring ist es leicht, etwas zu zerbrechen, und der Schaden wird mehr als gut sein.

Es ist besser, bestehende Warnungen technische Schulden zu berücksichtigen. Sie können später zur Schuld zurückkehren und schrittweise mit den alten Warnungen arbeiten. Mit dem Mechanismus zur Unterdrückung von Massenwarnungen können Sie PVS-Studio in einem großen Projekt schnell verwenden. Hier ist eine kurze Beschreibung dessen, was passiert:

1. Sie schließen offensichtlich redundante Verzeichnisse (Bibliotheken von Drittanbietern) von der Analyse aus. Sie sollten dies am Anfang tun, um die Analysezeit zu verkürzen.
2. Sie probieren PVS-Studio aus und untersuchen die interessantesten Warnungen . Sie mögen die Ergebnisse und zeigen das Tool Kollegen und Vorgesetzten. Das Team beschließt, es regelmäßig zu verwenden.
3. Das Projekt wird geprüft. Alle unterdrückten Warnungen werden mithilfe des Massenunterdrückungsmechanismus deaktiviert. Mit anderen Worten, alle Warnungen, die Sie zu diesem Zeitpunkt haben, werden jetzt als technische Schulden betrachtet, die später überarbeitet werden können.
4. Die resultierende Datei mit unterdrückten Warnungen gelangt in das Versionskontrollsystem. Diese Datei ist groß, aber das ist in Ordnung. Sie führen diese Aktionen nur einmal aus (oder zumindest sehr selten). Und jetzt haben alle Entwickler diese Datei.
5. Jetzt sehen alle Entwickler Warnungen, die sich nur auf neuen oder geänderten Code beziehen. Von diesem Moment an profitiert das Team von statischen Analysen. Als Nächstes richten Sie den Analysator schrittweise ein und kümmern sich um die technischen Schulden.

Das Speichersystem für uninteressante Warnungen ist übrigens ziemlich schlau. Hashes werden für die Zeile mit einem potenziellen Fehler sowie für die vorherige und die nächste Zeile gespeichert. Wenn Sie also am Anfang einer der Dateien eine Zeile hinzufügen, wird nichts in die Irre geführt, und der Analysator schweigt für den Code, der als technische Schuld angesehen wird.

Ich hoffe, ich habe es geschafft, eines der Vorurteile bezüglich der statischen Analyse zu zerstreuen. Laden Sie unseren statischen Code-Analysator PVS-Studio herunter und testen Sie ihn. Es erkennt viele Fehler in einem frühen Stadium und macht Ihren Code im Allgemeinen zuverlässiger und besser.

Hinweis

Während der Entwicklung eines Projekts treten ständig neue Fehler auf und werden behoben. Nicht gefundene Fehler "setzen" sich lange Zeit im Code fest, und dann können viele von ihnen erkannt werden, wenn eine statische Code-Analyse angewendet wird. Dies erweckt manchmal den falschen Eindruck, dass statische Analysatoren in selten verwendeten Codeteilen nur einige uninteressante Fehler finden. Nun, es ist wahr - falls Sie den Analysator falsch verwenden und ihn nur von Zeit zu Zeit ausführen, zum Beispiel kurz vor der Veröffentlichung. Mehr zu diesem Thema finden Sie hier . Ja, wir selbst überprüfen Open Source-Projekte einmalig, wenn wir Artikel schreiben. Aber wir haben einen anderen Zweck. Wir konzentrieren uns auf die Demonstration der Fähigkeit des Code-Analysators, Fehler zu erkennen. Im Allgemeinen hat diese Aufgabe wenig mit der Verbesserung der Qualität des Projektcodes und der Reduzierung der Kosten für die Behebung von Fehlern zu tun.

Zusätzliche Links

1. PVS-Studio ROI .
2. Warum statische Analyse eine komplexe C ++ - Codebasis verbessern kann .
3. Ivan Ponomarev. Führen Sie die statische Analyse in den Prozess ein und suchen Sie damit nicht nur nach Fehlern .