Statische Analyse – vom Kennenlernen bis zur Integration

Manchmal sind Sie der endlosen Codeüberprüfung oder dem Debuggen überdrüssig und denken manchmal darüber nach, wie Sie Ihr Leben vereinfachen können. Und nachdem Sie ein wenig gesucht haben oder zufällig darauf gestoßen sind, können Sie den Zauberspruch entdecken: „Statische Analyse“. Sehen wir uns an, was es ist und wie es mit Ihrem Projekt interagieren kann.

Statische Analyse – vom Kennenlernen bis zur Integration
Wenn Sie in einer modernen Sprache schreiben, haben Sie tatsächlich, ohne es zu merken, einen statischen Analysator durchlaufen. Tatsache ist, dass jeder moderne Compiler, wenn auch nur in geringem Umfang, Warnungen vor potenziellen Problemen im Code ausgibt. Wenn Sie beispielsweise C++-Code in Visual Studio kompilieren, sehen Sie möglicherweise Folgendes:

Statische Analyse – vom Kennenlernen bis zur Integration
In dieser Ausgabe sehen wir, dass die Variable jung wurde nirgendwo in der Funktion verwendet. In Wirklichkeit haben Sie also fast immer einen einfachen statischen Code-Analysator verwendet. Im Gegensatz zu professionellen Analyseprogrammen wie Coverity, Klocwork oder PVS-Studio deuten die vom Compiler bereitgestellten Warnungen jedoch möglicherweise nur auf einen kleinen Bereich von Problemen hin.

Wenn Sie nicht genau wissen, was statische Analyse ist und wie man sie implementiert, Lesen Sie diesen Artikelum mehr über diese Methodik zu erfahren.

Warum benötigen Sie eine statische Analyse?

Kurz gesagt: Beschleunigung und Vereinfachung.

Durch die statische Analyse können Sie viele verschiedene Probleme im Code finden: von der falschen Verwendung von Sprachkonstrukten bis hin zu Tippfehlern. Zum Beispiel statt

auto x = obj.x;
auto y = obj.y;
auto z = obj.z;

Sie haben den folgenden Code geschrieben:

auto x = obj.x;
auto y = obj.y;
auto z = obj.x;

Wie Sie sehen, liegt in der letzten Zeile ein Tippfehler vor. PVS-Studio gibt beispielsweise die folgende Warnung aus:

V537 Erwägen Sie, die korrekte Verwendung des Elements „y“ zu überprüfen.

Wenn Sie diesem Fehler auf den Grund gehen möchten, versuchen Sie es mit einem vorgefertigten Beispiel im Compiler Explorer: *клик*.

Und wie Sie wissen, ist es nicht immer möglich, solchen Codeabschnitten sofort Aufmerksamkeit zu schenken, und deshalb kann man eine gute Stunde lang beim Debuggen sitzen und sich fragen, warum alles so seltsam funktioniert.

Dies ist jedoch eindeutig ein Fehler. Was wäre, wenn der Entwickler suboptimalen Code schreiben würde, weil er einige Feinheiten der Sprache vergessen hat? Oder es sogar im Code erlaubt undefiniertes Verhalten? Leider kommen solche Fälle völlig an der Tagesordnung und der Löwenanteil der Zeit wird damit verbracht, speziell funktionierenden Code zu debuggen, der Tippfehler, typische Fehler oder undefiniertes Verhalten enthält.

Für diese Situationen erschien die statische Analyse. Hierbei handelt es sich um einen Assistenten für den Entwickler, der auf verschiedene Probleme im Code hinweist und in der Dokumentation erklärt, warum es nicht notwendig ist, so zu schreiben, wozu es führen kann und wie man es behebt. Hier ist ein Beispiel, wie es aussehen könnte: *клик*.

Weitere interessante Fehler, die der Analysator erkennen kann, finden Sie in den Artikeln:

Nachdem Sie dieses Material gelesen haben und von den Vorteilen der statischen Analyse überzeugt sind, möchten Sie es vielleicht ausprobieren. Aber wo soll ich anfangen? Wie integrieren Sie ein neues Tool in Ihr aktuelles Projekt? Und wie stellt man ihm das Team vor? Antworten auf diese Fragen finden Sie weiter unten.

Hinweis. Die statische Analyse ersetzt oder hebt eine so nützliche Sache wie Codeüberprüfungen nicht auf. Es ergänzt diesen Prozess und hilft, Tippfehler, Ungenauigkeiten und gefährliche Designs im Voraus zu erkennen und zu korrigieren. Es ist viel produktiver, sich auf Codeüberprüfungen auf Algorithmen und Codeklarheit zu konzentrieren, anstatt nach einer falsch platzierten Klammer oder einem Fehler zu suchen Lesen Sie langweilige Vergleichsfunktionen.

0. Kennenlernen des Tools

Alles beginnt mit einer Testversion. Tatsächlich ist es schwierig, sich zu entscheiden, etwas in den Entwicklungsprozess einzuführen, wenn man das Tool noch nie zuvor live gesehen hat. Daher sollten Sie als Erstes den Download durchführen Testversion.

Was Sie in dieser Phase lernen werden:

  • Welche Möglichkeiten gibt es, mit dem Analysator zu interagieren?
  • Ist der Analysator mit Ihrer Entwicklungsumgebung kompatibel?
  • Welche Probleme gibt es derzeit in Ihren Projekten?

Nachdem Sie alles Notwendige installiert haben, sollten Sie zunächst eine Analyse des gesamten Projekts durchführen (Windows, Linux, macOS). Im Fall von PVS-Studio in Visual Studio sehen Sie ein ähnliches Bild (anklickbar):

Statische Analyse – vom Kennenlernen bis zur Integration
Tatsache ist, dass statische Analysatoren bei Projekten mit einer großen Codebasis normalerweise eine große Anzahl von Warnungen ausgeben. Es besteht keine Notwendigkeit, sie alle zu beheben, da Ihr Projekt bereits funktioniert, was bedeutet, dass diese Probleme nicht kritisch sind. Aber du Sie können sich die interessantesten Warnungen ansehen und korrigieren Sie diese gegebenenfalls. Dazu müssen Sie die Ausgabe filtern und nur die zuverlässigsten Nachrichten hinterlassen. Im PVS-Studio-Plugin für Visual Studio erfolgt dies durch Filterung nach Fehlerstufen und Kategorien. Für eine möglichst genaue Ausgabe belassen Sie nur High и Allgemeines (auch anklickbar):

Statische Analyse – vom Kennenlernen bis zur Integration
Tatsächlich sind 178 Warnungen viel einfacher einzusehen als mehrere Tausend...

In Registerkarten Medium и Sneaker Oft gibt es gute Warnungen, aber in diese Kategorien fallen auch solche Diagnosen, die eine geringere Genauigkeit (Zuverlässigkeit) aufweisen. Weitere Informationen zu Warnstufen und Möglichkeiten für das Arbeiten unter Windows finden Sie hier: *клик*.

Es lohnt sich, die interessantesten Fehler erfolgreich überprüft (und erfolgreich korrigiert) zu haben verbleibende Warnungen unterdrücken. Dies ist notwendig, damit neue Warnungen nicht zwischen den alten untergehen. Darüber hinaus ist ein statischer Analysator ein Assistent für den Programmierer und keine Liste von Fehlern. 🙂

1. Automatisierung

Nachdem Sie sich damit vertraut gemacht haben, ist es an der Zeit, Plugins zu konfigurieren und in CI zu integrieren. Dies muss erfolgen, bevor Programmierer mit der Verwendung des statischen Analysators beginnen. Tatsache ist, dass der Programmierer möglicherweise vergisst, die Analyse zu aktivieren, oder sie überhaupt nicht durchführen möchte. Dazu müssen Sie noch einmal alles abschließend prüfen, damit nicht ungetesteter Code in den allgemeinen Entwicklungszweig gelangen kann.

Was Sie in dieser Phase lernen werden:

  • Welche Automatisierungsmöglichkeiten bietet das Tool?
  • Ist der Analysator mit Ihrem Montagesystem kompatibel?

Da es keine perfekte Dokumentation gibt, muss man manchmal reinschreiben unterstützen. Das ist normal und wir helfen Ihnen gerne weiter. 🙂

Kommen wir nun zu den Continuous Integration (CI)-Diensten. Jeder Analysator kann ohne größere Probleme in sie implementiert werden. Dazu müssen Sie eine separate Phase in der Pipeline erstellen, die sich normalerweise nach den Build- und Unit-Tests befindet. Dies erfolgt mithilfe verschiedener Konsolendienstprogramme. PVS-Studio bietet beispielsweise die folgenden Dienstprogramme:

Um Analysen in CI zu integrieren, müssen Sie drei Dinge tun:

  • Installieren Sie den Analysator.
  • Analyse ausführen;
  • Ergebnisse liefern.

Um beispielsweise PVS-Studio unter Linux (Debian-Basis) zu installieren, müssen Sie die folgenden Befehle ausführen:

wget -q -O - https://files.viva64.com/etc/pubkey.txt 
    | sudo apt-key add -
sudo wget -O /etc/apt/sources.list.d/viva64.list 
  https://files.viva64.com/etc/viva64.list
  
sudo apt-get update -qq
sudo apt-get install -qq pvs-studio

Auf Systemen unter Windows gibt es keine Möglichkeit, den Analysator über den Paketmanager zu installieren, aber es ist möglich, den Analysator über die Befehlszeile bereitzustellen:

PVS-Studio_setup.exe /verysilent /suppressmsgboxes 
/norestart /nocloseapplications

Sie können mehr über die Bereitstellung von PVS-Studio auf Systemen mit Windows lesen *hier*.

Nach der Installation müssen Sie die Analyse direkt ausführen. Es wird jedoch empfohlen, dies erst zu tun, nachdem die Kompilierung und die Tests bestanden wurden. Dies liegt daran, dass die statische Analyse normalerweise doppelt so lange dauert wie die Kompilierung.

Da die Startmethode von der Plattform und den Projektfunktionen abhängt, zeige ich die Option für C++ (Linux) als Beispiel:

pvs-studio-analyzer analyze -j8 
                            -o PVS-Studio.log
plog-converter -t errorfile PVS-Studio.log --cerr -w

Der erste Befehl führt die Analyse durch, der zweite UmschlägeKonvertiert den Bericht in das Textformat, zeigt ihn auf dem Bildschirm an und gibt bei Warnungen einen Returncode ungleich 0 zurück. Ein solcher Mechanismus kann bequem verwendet werden, um einen Build zu blockieren, wenn Fehlermeldungen vorliegen. Sie können die Flagge jedoch jederzeit entfernen -w und blockieren Sie keine Assembly, die Warnungen enthält.

Hinweis. Das Textformat ist unpraktisch. Es dient lediglich als Beispiel. Achten Sie auf ein interessanteres Berichtsformat – FullHtml. Es ermöglicht Ihnen, durch den Code zu navigieren.

Weitere Informationen zum Einrichten der CI-Analyse finden Sie im Artikel „PVS-Studio und kontinuierliche Integration„ (Windows) oder „So richten Sie PVS-Studio in Travis CI ein" (Linux).

Okay, Sie haben den Analysator auf dem Build-Server konfiguriert. Wenn nun jemand ungetesteten Code hochgeladen hat, schlägt die Überprüfungsphase fehl und Sie können das Problem erkennen. Dies ist jedoch nicht ganz praktisch, da es effizienter ist, das Projekt nicht nach dem Zusammenführen der Zweige zu überprüfen, sondern davor, in der Pull-Request-Phase. A.

Im Allgemeinen unterscheidet sich das Einrichten einer Pull-Request-Analyse nicht wesentlich vom üblichen Start einer Analyse auf CI. Abgesehen von der Notwendigkeit, eine Liste der geänderten Dateien zu erhalten. Diese können normalerweise durch Abfragen der Unterschiede zwischen Zweigen mit Git erhalten werden:

git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.list

Jetzt müssen Sie diese Dateiliste als Eingabe an den Analysator übergeben. In PVS-Studio wird dies beispielsweise über das Flag implementiert -S:

pvs-studio-analyzer analyze -j8 
                            -o PVS-Studio.log 
                            -S .pvs-pr.list

Mehr zur Analyse von Pull Requests erfahren Sie *hier*. Auch wenn Ihr CI nicht auf der Liste der im Artikel erwähnten Dienste aufgeführt ist, werden Sie den allgemeinen Abschnitt zur Theorie dieser Art von Analyse hilfreich finden.

Indem Sie die Analyse von Pull-Requests einrichten, können Sie Commits mit Warnungen blockieren und so eine Grenze schaffen, die ungetesteter Code nicht überschreiten kann.

Das ist sicherlich alles gut, aber ich möchte alle Warnungen an einem Ort sehen können. Nicht nur vom statischen Analysator, sondern auch von Unit-Tests oder vom dynamischen Analysator. Hierfür gibt es verschiedene Dienste und Plugins. PVS-Studio hat zum Beispiel Plugin zur Integration in SonarQube.

2. Integration auf Entwicklermaschinen

Jetzt ist es an der Zeit, den Analysator für den täglichen Entwicklungseinsatz zu installieren und zu konfigurieren. Zu diesem Zeitpunkt sind Sie bereits mit den meisten Arbeitsweisen vertraut, sodass dies als der einfachste Teil bezeichnet werden kann.

Als einfachste Möglichkeit können Entwickler den notwendigen Analysator selbst installieren. Dies nimmt jedoch viel Zeit in Anspruch und lenkt sie von der Entwicklung ab. Daher können Sie diesen Prozess mithilfe eines Installationsprogramms und der erforderlichen Flags automatisieren. Für PVS-Studio gibt es verschiedene Flags für die automatisierte Installation. Es gibt jedoch immer Paketmanager, zum Beispiel Chocolatey (Windows), Homebrew (macOS) oder Dutzende Optionen für Linux.

Dann müssen Sie die notwendigen Plugins installieren, zum Beispiel für Visual Studio, IDEA, Fahrer usw.

3. Täglicher Gebrauch

An dieser Stelle ist es an der Zeit, ein paar Worte zu den Möglichkeiten zu sagen, wie man den Analysator im täglichen Gebrauch beschleunigen kann. Eine vollständige Analyse des gesamten Projekts nimmt viel Zeit in Anspruch, aber wie oft ändern wir den Code im gesamten Projekt auf einmal? Es gibt kaum ein Refactoring, das so groß ist, dass es sich sofort auf die gesamte Codebasis auswirkt. Die Anzahl der gleichzeitig geänderten Dateien übersteigt selten ein Dutzend, daher ist es sinnvoll, sie zu analysieren. Für eine solche Situation gibt es inkrementeller Analysemodus. Seien Sie einfach nicht beunruhigt, dies ist kein weiteres Tool. Dies ist ein spezieller Modus, der es Ihnen ermöglicht, nur geänderte Dateien und ihre Abhängigkeiten zu analysieren. Dies geschieht automatisch nach dem Erstellen, wenn Sie in einer IDE mit installiertem Plugin arbeiten.

Wenn der Analysator Probleme im kürzlich geänderten Code erkennt, meldet er dies selbstständig. PVS-Studio informiert Sie beispielsweise über eine Warnung darüber:

Statische Analyse – vom Kennenlernen bis zur Integration
Natürlich reicht es nicht aus, den Entwicklern zu sagen, dass sie das Tool verwenden sollen. Wir müssen ihnen irgendwie sagen, was es ist und wie es ist. Hier finden Sie beispielsweise Artikel über einen Schnellstart für PVS-Studio, aber Sie können ähnliche Tutorials für jedes von Ihnen bevorzugte Tool finden:

Solche Artikel liefern alle für den täglichen Gebrauch notwendigen Informationen und nehmen nicht viel Zeit in Anspruch. 🙂

Schon beim Kennenlernen des Tools haben wir bei einem der ersten Starts viele Warnungen unterdrückt. Leider sind statische Analysegeräte nicht perfekt und liefern daher von Zeit zu Zeit falsch positive Ergebnisse. Normalerweise ist es einfach, sie zu unterdrücken. Im PVS-Studio-Plugin für Visual Studio müssen Sie beispielsweise nur auf eine Schaltfläche klicken:

Statische Analyse – vom Kennenlernen bis zur Integration
Sie können jedoch mehr tun, als sie nur zu unterdrücken. Beispielsweise können Sie dem Support ein Problem melden. Wenn das falsch positive Ergebnis korrigiert werden kann, können Sie in zukünftigen Updates feststellen, dass es jedes Mal immer weniger falsch positive Ergebnisse speziell für Ihre Codebasis gibt.

Nach der Integration

Wir haben also alle Phasen der Integration der statischen Analyse in den Entwicklungsprozess durchlaufen. Obwohl es wichtig ist, solche Tools auf CI einzurichten, ist der Computer des Entwicklers der wichtigste Ort für deren Ausführung. Schließlich ist ein statischer Analysator kein Richter, der irgendwo weit weg von Ihnen sagt, dass der Code nicht gut ist. Im Gegenteil, es ist ein Assistent, der Ihnen sagt, ob Sie müde sind, und Sie daran erinnert, wenn Sie etwas vergessen haben.

Ohne regelmäßige Verwendung dürfte die statische Analyse die Entwicklung zwar nicht wesentlich vereinfachen. Denn der Hauptvorteil für einen Entwickler liegt nicht so sehr in der Suche nach komplexen und kontroversen Codeabschnitten, sondern in deren Früherkennung. Stimmen Sie zu, dass es nicht nur unangenehm, sondern auch sehr zeitaufwändig ist, ein Problem zu entdecken, nachdem die Änderungen zum Testen gesendet wurden. Bei regelmäßiger Anwendung prüft die statische Analyse jede Änderung direkt auf Ihrem Computer und meldet verdächtige Stellen während der Arbeit am Code.

Und wenn Sie oder Ihre Kollegen immer noch nicht sicher sind, ob sich die Implementierung des Analysegeräts lohnt, dann empfehle ich Ihnen, jetzt mit der Lektüre des Artikels zu beginnen.Gründe, den statischen Code-Analysator PVS-Studio in den Entwicklungsprozess einzuführen„Es geht auf typische Bedenken von Entwicklern ein, dass die statische Analyse ihre Zeit in Anspruch nimmt und so weiter.“

Statische Analyse – vom Kennenlernen bis zur Integration

Wenn Sie diesen Artikel einem englischsprachigen Publikum zugänglich machen möchten, verwenden Sie bitte den Übersetzungslink: Maxim Zvyagintsev. Statische Analyse: Vom Einstieg bis zur Integration.

Source: habr.com

Kommentar hinzufügen