Bei der Kommunikation mit Personen auf Konferenzen und in Kommentaren zu Artikeln stoßen wir auf folgenden Einwand: Die statische Analyse reduziert den Zeitaufwand für das Auffinden von Fehlern, nimmt jedoch Zeit für Programmierer in Anspruch, wodurch der Nutzen der Verwendung entfällt und sogar der Entwicklungsprozess verlangsamt wird. Lassen Sie uns diesen Einwand analysieren und zeigen, dass er unbegründet ist.
Die Aussage "statische Analyse nimmt einen Teil der Arbeitszeit ein" ist isoliert vom Kontext wahr. Das regelmäßige Überprüfen der Warnungen des statischen Analysators für neuen oder geänderten Code nimmt wirklich Zeit in Anspruch. Der Gedanke sollte jedoch fortgesetzt werden: Die dafür aufgewendete Zeit ist jedoch viel geringer als die, die für die Identifizierung von Fehlern mit anderen Methoden aufgewendet wird. Noch schlimmer ist es, von Kunden über Fehler zu lernen.
Unit-Tests können hier eine sehr gute Analogie sein. Unit-Tests brauchen auch Zeit für Entwickler, aber dies ist kein Grund, sie nicht zu verwenden. Der Vorteil des Schreibens von besserem und zuverlässigerem Code bei der Verwendung von Komponententests übersteigt die Kosten für das Schreiben.
Eine weitere Analogie: Compiler-Warnungen. Dies ist im Allgemeinen ein sehr enges Thema, da die Warnungen statischer Analysewerkzeuge als erste Annäherung als Erweiterung der Compilerwarnungen angesehen werden können. Wenn ein Programmierer eine Compiler-Warnung sieht, verbringt er natürlich Zeit damit. Es sollte entweder den Code ändern oder explizit Zeit damit verbringen, die Warnung zu unterdrücken, beispielsweise mit #pragma. Diese Zeit ist jedoch kein Grund, Compiler-Warnungen zu deaktivieren. Und wenn jemand dies tut, wird dies von anderen eindeutig als berufliche Ungeeignetheit interpretiert.
Woher kommt jedoch die Angst, Zeit damit zu verbringen, statische Code-Analysatoren zu warnen?
Alles ist sehr einfach. Programmierer, die mit dieser Methode noch nicht vertraut sind, verwechseln Testläufe und die regelmäßige Verwendung. Bei den ersten Starts 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. Ein abgestimmter Analysator erzeugt bei regelmäßigen Starts eine kleine Anzahl von Fehlalarmen. Mit anderen Worten, die meisten Warnungen enthüllen echte Mängel oder einen Geruchscode. Es ist nur wichtig, diese Einstellung vorzunehmen. Dies ist der ganze Trick, der einen statischen Analysator vom Bösen, das Zeit braucht, zu einem Freund und Helfer macht.
Jeder statische Analysator erzeugt zuerst viele falsch positive Ergebnisse. Dafür gibt es viele Gründe, und dieses Thema verdient einen separaten Artikel. Natürlich haben sowohl wir als auch die Entwickler anderer Analysegeräte mit Fehlalarmen zu
kämpfen . Aber es wird immer noch viele positive Ergebnisse geben, wenn Sie ohne Vorbereitung plötzlich den Analysator für ein Projekt nehmen und ausführen. Das gleiche Bild übrigens mit Compiler-Warnungen. Angenommen, Sie haben ein großes Projekt, das Sie immer erstellt haben, beispielsweise mit dem Visual C ++ - Compiler. Angenommen, das Projekt war auf wundersame Weise portabel und wurde mit GCC kompiliert. Trotzdem erhalten Sie vom GCC einen Berg von Warnungen. Jeder, der in einem großen Projekt einen Compilerwechsel erlebt hat, versteht, worum es geht.
Nach dem Wechseln des Compilers oder nach dem Starten des Analysators zwingt sich jedoch niemand, ständig in den Müllbergen vor Warnungen zu graben. Der nächste natürliche Schritt ist die Konfiguration des Compilers oder Analysators. Diejenigen, die sagen, dass die Analyse von Warnungen zeitaufwändig ist, bewerten die Komplexität der Implementierung des Tools und denken nur an all diese Warnungen, die zu Beginn überwunden werden müssen, denken aber nicht an eine ruhige regelmäßige Verwendung.
Das Einrichten von Analysatoren und Compilern ist nicht so kompliziert und arbeitsaufwendig, wie Programmierer es gerne erschrecken. 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 dem vom Tester / Client gefundenen Fehler gesucht hat. Und das ist normal für ihn. Aus seiner Sicht ist es jedoch nicht akzeptabel, einen Tag damit zu verbringen, das Tool zu optimieren. Danach wird ein ähnlicher Fehler erkannt, bevor er in das Versionskontrollsystem gelangt.
Ja, nach dem Einstellen werden Fehlalarme angezeigt. Aber ihre Zahl ist übertrieben. Es ist durchaus möglich, den Analysator so zu konfigurieren, dass der Prozentsatz falsch positiver Ergebnisse 10% -15% beträgt. Das heißt, Bei 9 gefundenen Fehlern muss nur 1 Warnung als falsch unterdrückt werden. Wo ist hier also die "Zeitverschwendung"? Gleichzeitig ist 15% ein sehr realer Wert, der in diesem
Artikel ausführlicher
beschrieben wird .
Eine Sache bleibt noch. Der Programmierer kann Einwände erheben:
Angenommen, regelmäßige statische Analysen sind wirklich effektiv. Aber was tun mit dem anfänglichen Geräusch? Bei unserem großen Projekt können wir das Tool nicht für einen versprochenen Tag konfigurieren. Nur eine 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 in einem großen Projekt nicht alles einfach. Zunächst bieten wir jedoch Unterstützung und helfen bei der Integration von PVS-Studio in den Entwicklungsprozess. Und zweitens ist es überhaupt nicht notwendig, alle Warnungen zu sortieren.
Da Ihre Anwendung funktioniert, bedeutet dies, dass die Fehler dort nicht so kritisch sind und höchstwahrscheinlich in selten verwendetem Code auftreten. Es wurden bereits schwerwiegende offensichtliche Fehler gefunden und mit langsameren und teureren Methoden korrigiert. Aber darüber weiter unten in einer
Notiz . Jetzt ist uns etwas anderes wichtig. Es macht keinen Sinn, umfangreiche Änderungen am Code vorzunehmen und viele kleinere Fehler zu korrigieren. Bei so viel Refactoring ist etwas leicht zu brechen und es wird mehr schaden als nützen.
Es ist besser, bestehende Warnungen als technische Schulden zu betrachten. Es wird möglich sein, später wieder Schulden zu machen und schrittweise mit alten Warnungen zu arbeiten. Mit
dem Mechanismus zur Unterdrückung von Massenalarmen können Sie PVS-Studio in einem großen Projekt schnell verwenden. Ganz kurz passiert es so:
- Sie schließen explizit redundante Verzeichnisse (Bibliotheken von Drittanbietern) von der Analyse aus. In jedem Fall wird diese Einstellung am besten ganz am Anfang vorgenommen, um die Analysezeit zu verkürzen.
- Sie probieren PVS-Studio aus und studieren die interessantesten Warnungen . Sie mögen die Ergebnisse und zeigen das Tool Kollegen und Vorgesetzten. Das Team beschließt, den regulären Einsatz aufzunehmen.
- Das Projekt wird überprüft. Alle gefundenen Warnungen werden mithilfe des Massenunterdrückungsmechanismus deaktiviert. Mit anderen Worten, alle derzeit verfügbaren Warnungen gelten jetzt als technische Schulden, die später zurückgegeben werden können.
- Die resultierende Datei mit unterdrückten Warnungen wird im Versionskontrollsystem abgelegt. Diese Datei ist groß, aber nicht beängstigend. Sie führen diesen Vorgang einmal aus (oder zumindest äußerst selten). Und jetzt wird diese Datei in allen Entwicklern angezeigt.
- Jetzt sehen alle Entwickler Warnungen, die nur für neuen oder geänderten Code gelten. Ab diesem Moment profitiert das Team von statischen Analysen. Richten Sie den Analysator schrittweise ein und machen Sie technische Schulden.
Das System zum Speichern uninteressanter Warnungen ist übrigens intelligent genug. Hashes werden für eine Zeichenfolge mit einem potenziellen Fehler sowie für die vorherige und die nächste gespeichert. Wenn daher eine Zeile am Anfang einer der Dateien hinzugefügt wird, wird nichts „korrodieren“ und der Analysator schweigt immer noch zu dem Code, der als technische Pflicht angesehen wird.
Ich hoffe, wir konnten eines der Vorurteile in Bezug auf die statische Analyse abbauen.
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 insgesamt zuverlässiger und qualitativ hochwertiger.
HinweisBei der Entwicklung eines Projekts treten ständig neue Fehler auf und werden korrigiert. Nicht erkannte Fehler „setzen“ sich lange Zeit im Code fest, und dann können viele von ihnen beim Starten einer statischen Code-Analyse erkannt werden. Aus diesem Grund besteht manchmal das falsche Gefühl, dass statische Analysatoren in selten verwendeten Codeabschnitten nur einige uninteressante Fehler finden. Dies ist natürlich der Fall, wenn Sie den Analysator falsch verwenden und ihn nur von Zeit zu Zeit ausführen, z. B. kurz vor der Veröffentlichung der Version. Mehr zu diesem Thema
hier . Ja, beim Schreiben von Artikeln führen wir selbst einmalige Überprüfungen offener Projekte durch. Aber wir haben ein anderes Ziel. Wir möchten die Fähigkeiten eines Code-Analysators zur Erkennung von Fehlern demonstrieren. Diese Aufgabe hat wenig mit der Verbesserung der Qualität des gesamten Projektcodes und der Reduzierung der mit der Fehlerkorrektur verbundenen Kosten zu tun.
Zusätzliche Links:- PVS-Studio ROI .
- Die statische Analyse verbessert die Codebasis komplexer C ++ - Projekte .
- Heisenbug 2019. Bericht von Ivan Ponomarev " Continuous Static Code Analysis ".
- Ivan Ponomarev. Betten Sie statische Analysen in den Prozess ein und suchen Sie nicht nach Fehlern .
Wenn Sie diesen Artikel einem englischsprachigen Publikum zugänglich machen möchten, verwenden Sie bitte den Link zur Übersetzung: Andrey Karpov.
Umgang mit Einwänden: Die statische Analyse nimmt einen Teil der Arbeitszeit in Anspruch .