🥇Statische Analyse – vom Einstieg bis zur Integration

Das ständige Code-Review oder Debugging kann dazu führen, dass man darüber nachdenkt, wie man sich das Leben erleichtern kann. Mit ein wenig Suche oder durch Zufall stößt man auf den zauberhaften Begriff: "Statische Analyse". Lassen Sie uns untersuchen, was das ist und wie es mit Ihrem Projekt interagieren kann.

Wenn Sie also in einer modernen Programmiersprache schreiben, dann haben Sie, ohne es zu wissen, Ihren Code durch einen statischen Analyzer laufen lassen. Jeder moderne Compiler liefert zwar nur eine kleine Menge an Warnungen über potenzielle Probleme im Code. Zum Beispiel, wenn Sie C++-Code in Visual Studio kompilieren, könnten Sie Folgendes sehen:

In dieser Ausgabe sehen wir, dass die Variable var nirgendwo in der Funktion verwendet wurde. Tatsächlich haben Sie also fast immer einen einfachen statischen Code-Analyzer genutzt. Allerdings können die vom Compiler gelieferten Warnungen nur auf einen kleinen Bereich von Problemen hinweisen, im Gegensatz zu professionellen Analyzern wie Coverity, Klocwork oder PVS-Studio.

Wenn Sie nicht genau wissen, was statische Analyse ist und wie man sie implementiert, diesen Artikel, um detaillierter mit dieser Methodik vertraut zu werden.

Warum ist statische Analyse notwendig?

Kurz gesagt: Beschleunigung und Vereinfachung.

Statische Analyse hilft dabei, eine Vielzahl von Problemen im Code zu finden: von falscher Nutzung der Sprachkonstrukte bis hin zu Tippfehlern. Zum Beispiel anstelle von

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

haben Sie den folgenden Code geschrieben:

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

Wie Sie sehen, gab es in der letzten Zeile einen Tippfehler. Zum Beispiel gibt PVS-Studio folgende Warnung aus:

V537 Bitte überprüfen Sie die Korrektheit der Nutzung des Elements 'y'.

Wenn Sie möchten, können Sie dieses Fehlerbeispiel selbst ausprobieren: *klicken*.

Und wie Sie verstehen, kann man nicht immer sofort auf solche Codeabschnitte achten, weshalb man beim Debuggen leicht einige Stunden in Anspruch nehmen kann, ohne zu verstehen, warum alles so seltsam funktioniert.

Das ist jedoch ein klarer Fehler. Was ist, wenn der Entwickler aufgrund einer vergessenen Nuance der Sprache suboptimalen Code geschrieben hat? Oder wenn er sogar im Code undefined behavior? К сожалению, подобные случаи совершенно обыденны и львиная часть времени тратится на то, чтобы отладить специфично работающий код, который содержит опечатки, типичные ошибки или undefined behavior.

verursacht hat? Genau für solche Situationen wurde die statische Analyse entwickelt. Sie ist ein Helfer für den Entwickler, der auf verschiedene Probleme im Code hinweist und in der Dokumentation erklärt, warum es nicht so geschrieben werden sollte, welche Folgen das haben kann und wie man es beheben kann. So könnte das aussehen: *klicken*.

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

Jetzt, wo Sie dieses Material gelesen haben und von den Vorteilen der statischen Analyse überzeugt sind, möchten Sie vielleicht herausfinden, wie man sie in der Praxis anwendet. Aber wo fängt man an? Wie integriert man ein neues Tool in ein bestehendes Projekt? Und wie macht man das Team damit vertraut? Auf diese Fragen finden Sie weiter unten Antworten.

Hinweis. Statische Analyse ersetzt und annulliert nicht den so nützlichen Prozess der Code-Reviews. Sie ergänzt diesen Prozess, indem sie hilft, Tippfehler, Ungenauigkeiten und gefährliche Konstrukte im Voraus zu erkennen und zu korrigieren. Es ist wesentlich produktiver, sich in Code-Reviews auf Algorithmen und die Verständlichkeit des Codes zu konzentrieren, anstatt nach einer falsch gesetzten Klammer oder langweiligen Vergleichsfunktionen zu suchen..

0. Einführung in das Tool

Alles beginnt mit einer Testversion. Es ist wirklich schwierig, sich zu entscheiden, etwas in den Entwicklungsprozess zu integrieren, wenn man das Tool noch nie live gesehen hat. Deshalb sollten Sie als Erstes Testversion.

Was Sie in dieser Phase erfahren werden:

Welche Möglichkeiten der Interaktion mit dem Analyzer bestehen;
Ob der Analyzer mit Ihrer Entwicklungsumgebung kompatibel ist;
Welche Probleme momentan in Ihren Projekten bestehen.

Nachdem Sie alles Notwendige installiert haben, sollten Sie gleich zu Beginn eine Analyse des gesamten Projekts starten (Windows, Linux, macOS). Bei PVS-Studio in Visual Studio sehen Sie ein ähnliches Bild (klickbar):

Das Problem ist, dass statische Analyzer bei Projekten mit einer großen Codebasis in der Regel eine enorme Anzahl von Warnungen ausgeben. Es ist nicht notwendig, sie alle zu beheben, da Ihr Projekt bereits funktioniert, was bedeutet, dass diese Probleme nicht kritisch sind. Sie können jedoch die interessantesten Warnungen betrachten und sie bei Bedarf beheben. Dazu müssen Sie die Ausgabe filtern und nur die zuverlässigsten Meldungen belassen. Im PVS-Studio-Plugin für Visual Studio geschieht dies durch Filterung nach Fehlerlevels und -kategorien. Für die genauesten Ergebnisse lassen Sie nur die ein, die ebenfalls klickbar sind: Hoch und Allgemein Tatsächlich ist es viel einfacher, 178 Warnungen zu prüfen, als mehrere Tausend…

In den Tabs

In den Reitern Medium und Niedrig Es gibt oft gute Warnungen, aber in diese Kategorien fallen Diagnosen, die eine geringere Genauigkeit (Zuverlässigkeit) aufweisen. Mehr über die Warnstufen und die Arbeitsmöglichkeiten unter Windows erfahren Sie hier: *klicken*.

Nachdem Sie die interessantesten Fehler erfolgreich angesehen (und behoben) haben, sollten Sie die verbleibenden Warnungen unterdrücken. Dies ist notwendig, damit neue Warnungen nicht unter den alten verloren gehen. Zudem soll der statischeAnalyzer ein Hilfsmittel für den Programmierer sein und keine Fehlerliste. 🙂

1. Automatisierung

Nach dem Kennenlernen folgt die Zeit für die Konfiguration von Plugins und die Integration in CI. Dies muss erfolgen, bevor die Programmierer mit dem statischen Analyzer arbeiten. Der Grund ist, dass ein Programmierer das Analysieren vergessen oder ganz darauf verzichten könnte. Dazu ist eine abschließende Überprüfung erforderlich, um sicherzustellen, dass unverifiziertes Code nicht in den Hauptentwicklungszweig gelangt.

Was Sie in dieser Phase lernen werden:

Welche Automatisierungsoptionen das Werkzeug bietet;
Ob der Analyzer mit Ihrem Build-System kompatibel ist.

Da es keine ideale Dokumentation gibt, muss man manchmal nachfragen in Support. Das ist in Ordnung, und wir sind froh, Ihnen helfen zu können. 🙂

Nun kommen wir zu den Continuous Integration (CI) Services. Jeder Analyzer kann problemlos integriert werden. Dazu muss eine separate Stufe im Pipeline erstellt werden, die in der Regel nach dem Build und den Unit-Tests liegt. Dies geschieht mit verschiedenen Konsolenwerkzeugen. Zum Beispiel bietet PVS-Studio folgende Werkzeuge an:

PVS-Studio_Cmd.exe (Analyse von Lösungen, C#, C++ Projekten auf Windows)
CLMonitor.exe (Überwachung des Builds)
pvs-studio-analyzer (Analyse von C++ Projekten auf Linux / macOS)
pvs-studio-dotnet (Analyse von Lösungen, C# Projekten auf Linux / macOS)
pvs-studio.jar (Analyse von Java Projekten)
PlogConverter (Bericht-Datei Konverter)

Für die Integration der Analyse in CI müssen drei Dinge getan werden:

Den Analyzer installieren;
Die Analyse starten;
Die Ergebnisse bereitstellen.

Zum Beispiel müssen die folgenden Befehle ausgeführt werden, um PVS-Studio auf Linux (Debian-basiert) zu installieren:

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

In Windows-basierten Systemen gibt es keine Möglichkeit, den Analyzer über einen Paketmanager zu installieren, aber es ist möglich, den Analyzer über die Befehlszeile zu entpacken:

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

Mehr über die Bereitstellung von PVS-Studio in Windows-basierten Systemen können Sie hier lesen *hier*.

Nach der Installation muss die Analyse selbst gestartet werden. Es wird jedoch empfohlen, dies erst nach der Kompilierung und den Tests zu tun. Dies liegt daran, dass der statische Analyse in der Regel doppelt so viel Zeit wie die Kompilierung benötigt.

Da die Art des Starts von der Plattform und den Besonderheiten des Projekts abhängt, zeige ich eine Variante 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, und der zweite konvertiertden Bericht in ein Textformat, gibt ihn auf dem Bildschirm aus und liefert einen Rückgabewert ungleich 0 zurück, falls Warnungen vorhanden sind. Ein solches Verfahren ist praktisch, um das Build bei Fehlernachrichten zu blockieren. Sie können jedoch immer das Flag -w entfernen und das Build nicht blockieren, wenn es Warnungen enthält.

Hinweis. Das Textformat ist unpraktisch. Es wird nur als Beispiel genannt. Beachten Sie das interessantere Berichtformat – FullHtml. Es ermöglicht die Navigation im Code.

Mehr über die Einstellung der Analyse in CI kann in dem Artikel "PVS-Studio und Continuous Integration" (Windows) oder "Wie PVS-Studio in Travis CI zu konfigurieren" (Linux) nachgelesen werden.

Gut, Sie haben die Arbeit des Analyzers auf dem Build-Server eingerichtet. Nun, wenn jemand unverifiziertes Code hochgeladen hat, wird die Prüfphase fehlschlagen, und Sie können das Problem erkennen, aber das ist nicht besonders praktisch, da es effizienter ist, das Projekt nicht erst nach dem Merge der Branches zu prüfen, sondern davor, in der Phase des Pull Requests.

Im Allgemeinen unterscheidet sich die Einrichtung der Analyse des Pull Requests nicht stark von dem üblichen Start der Analyse in CI. Abgesehen von der Notwendigkeit, die Liste der geänderten Dateien zu erhalten. Normalerweise können diese durch Anfordern der Differenz zwischen den Branches mit git erhalten werden:

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

Jetzt müssen Sie dieser Liste von Dateien als Eingabe an den Analyzer übergeben. Zum Beispiel wird dies in PVS-Studio mit dem Flag realisiert -S:

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

Mehr über die Analyse von Pull Requests erfahren Sie *hier*. Selbst wenn Ihr CI nicht in der Liste der genannten Dienste ist, wird Ihnen der allgemeine Abschnitt, der sich mit der Theorie dieser Art von Analyse beschäftigt, nützlich sein.

Indem Sie die Analyse von Pull-Requests konfigurieren, können Sie Commits mit Warnungen blockieren und somit eine Grenze schaffen, die unüberprüfter Code nicht überschreiten kann.

Das ist alles zweifellos gut, jedoch würde ich mir wünschen, alle Warnungen an einem Ort sehen zu können. Nicht nur von dem statischen Analyzer, sondern auch von Unit-Tests oder dem dynamischen Analyzer. Dafür gibt es verschiedene Dienste und Plugins. PVS-Studio hat beispielsweise ein Plugin zur Integration in SonarQube.

2. Integration auf den Maschinen der Entwickler

Jetzt ist es an der Zeit, den Analyzer für den regelmäßigen Einsatz bei der Entwicklung zu installieren und einzurichten. Zu diesem Zeitpunkt haben Sie bereits die meisten Arbeitsmethoden kennengelernt, sodass man dies als den einfachsten Teil bezeichnen kann.

Als einfachste Variante können die Entwickler selbst den benötigten Analyzer installieren. Das kann jedoch viel Zeit in Anspruch nehmen und sie von der Entwicklung ablenken, weshalb Sie diesen Prozess automatisieren können, indem Sie einen Installer und die erforderlichen Flags verwenden. Für PVS-Studio gibt es verschiedene Flags für die automatisierte Installation. Es gibt jedoch immer Paketmanager, wie zum Beispiel Chocolatey (Windows), Homebrew (macOS) oder dutzende Alternativen für Linux.

Anschließend müssen die erforderlichen Plugins installiert werden, beispielsweise für Visual Studio, IDEA, Rider etc.

3. Tägliche Nutzung

An diesem Punkt ist es an der Zeit, ein paar Worte über Möglichkeiten zur Beschleunigung der Analysearbeit bei der täglichen Nutzung zu sagen. Eine vollständige Analyse des gesamten Projekts dauert sehr lange, allerdings ändern wir nicht oft den Code im gesamten Projekt auf einmal. Es gibt kaum einen so umfassenden Refactoring-Prozess, der sofort die gesamte Code-Basis betrifft. Die Anzahl der gleichzeitig geänderten Dateien übersteigt selten ein Dutzend, daher macht es Sinn, diese zu analysieren. Für solche Situationen gibt es den inkrementellen Analysemodus.Keine Panik, das ist kein weiteres Tool. Dies ist ein spezieller Modus, der es ermöglicht, nur die geänderten Dateien und ihre Abhängigkeiten zu analysieren, und dies geschieht automatisch nach dem Build, wenn Sie in einer IDE mit dem installierten Plugin arbeiten.

Wenn der Analyzer Probleme im kürzlich geänderten Code feststellt, wird er dies selbstständig melden. Beispielsweise wird PVS-Studio Sie mit einer Benachrichtigung darüber informieren:

Natürlich ist es nicht genug, den Entwicklern zu sagen, sie sollen das Tool verwenden. Man muss ihnen erklären, was es ist und wie es funktioniert. Hier sind beispielsweise Artikel für einen schnellen Einstieg in PVS-Studio, aber ähnliche Tutorials finden Sie für jedes bevorzugte Tool:

Solche Artikel bieten alle notwendigen Informationen für die alltägliche Nutzung und nehmen nicht viel Zeit in Anspruch. 🙂

Schon in der Anfangsphase, als wir das Tool kennenlernten, haben wir viele Warnungen während eines der ersten Starts unterdrückt. Leider sind statische Analyzer nicht perfekt und geben hin und wieder Fehlalarme aus. Diese zu unterdrücken, ist in der Regel einfach, zum Beispiel muss man im PVS-Studio-Plugin für Visual Studio nur einen Knopf drücken:

Sie können jedoch nicht nur die Warnungen unterdrücken. Beispielsweise können Sie den Support über ein bestehendes Problem informieren. Wenn der Fehlalarm behoben werden kann, können Sie in zukünftigen Updates darauf achten, dass mit jeder neuen Version die für Ihre Code-Basis spezifischen Fehlalarme immer weniger werden.

Nach der Integration

So, wir haben alle Schritte durchlaufen, um die statische Analyse in den Entwicklungsprozess zu integrieren. Trotz der Wichtigkeit solcher Werkzeuge in CI ist der wichtigste Ort für den Einsatz der Computer des Entwicklers. Denn der statische Analyzer ist kein Richter, der irgendwo weit entfernt erklärt, dass der Code nicht funktioniert. Vielmehr ist er ein Helfer, der Sie unterstützt, wenn Sie müde sind, und erinnert, wenn Sie etwas vergessen haben.

Wahrlich, ohne regelmäßige Nutzung wird die statische Analyse kaum die Entwicklung erheblich erleichtern. Denn ihr größter Nutzen für den Entwickler liegt nicht so sehr darin, schwierige und strittige Stellen im Code zu finden, sondern sie frühzeitig zu erkennen. Sie stimmen zu, dass es unangenehm und langwierig ist, ein Problem zu entdecken, wenn die Änderungen bereits zur Testung geschickt wurden. Bei regelmäßiger Nutzung hingegen überprüft die statische Analyse jede Veränderung direkt auf Ihrem Computer und meldet verdächtige Stellen während der Arbeit am Code.

Und falls Sie oder Ihre Kollegen sich dennoch unsicher sind, ob es sich lohnt, den Analyzer zu implementieren, schlage ich vor, jetzt den Artikel "Gründe für die Einführung eines statischen Code-Analysetools wie PVS-Studio in den Entwicklungsprozess". Dabei werden häufige Bedenken der Entwickler behandelt, dass die statische Analyse ihre Zeit in Anspruch nehmen wird und so weiter.

Wenn Sie diesen Artikel mit einem englischsprachigen Publikum teilen möchten, verwenden Sie bitte den Link zur Übersetzung: Maxim Zvyagintsev. Statische Analyse: Vom Einstieg bis zur Integration.

Quelle: habr.com