Softwarefehler kosten Entwickler und Softwareunternehmen viel Zeit und Geld. Nehmen wir als Beispiel das Jahr 2014: Ein Fehler („goto fail“) in der weit verbreiteten Implementierung des SSL-Protokolls führte dazu, dass ungültige SSL-Zertifikate akzeptiert wurden, und ein weiterer Fehler im Zusammenhang mit der Datumsformatierung führte zu weit verbreiteten Dienstausfällen auf Twitter. Solche Fehler können häufig durch statische Analyse erkannt werden. Tatsächlich können sie beim Lesen von Code oder Dokumentation schnell identifiziert werden, und letztendlich tritt die Situation immer noch in der Produktionsumgebung auf.
Frühere Arbeiten haben ausführlich über die Erfahrungen mit der Anwendung von Fehlererkennungstools in der Softwareentwicklung berichtet. Aber obwohl es so viele erfolgreiche Fälle von Entwicklern gibt, die statische Analysetools verwenden, gibt es immer noch die folgenden Gründe, warum Ingenieure nicht immer bereit sind, statische Analysetools zu verwenden oder die von den Tools generierten Warninformationen aktiv zu ignorieren:
Nicht richtig integriert . Das Tool ist nicht in den Workflow des Entwicklers integriert oder die Ausführung des Programms dauert zu lange
Ungültige Warnungen. Alarminformationen sind schlecht umsetzbar;
ist nicht vertrauenswürdig. Benutzer vertrauen den Ergebnissen aufgrund von Fehlalarmen nicht mehr.
Das tatsächliche Nutzungsszenario des Defekts ist unklar. Der gemeldete Fehler ist theoretisch machbar, aber in tatsächlichen Nutzungsszenarien ist der Fehler nicht klar
Die Reparaturkosten sind zu hoch. Das Beheben erkannter Codefehler ist zu kostspielig oder anderweitig riskant.
Warnungen sind schwer zu verstehen. Benutzer verstehen die spezifischen Informationen und Prinzipien der Alarminformationen nicht.
Der folgende Artikel beschreibt, wie wir aus den bisherigen Erfahrungen und Lehren von Google bei der Verwendung von FindBug für die Java-Sprachanalyse und der wissenschaftlichen Literatur gelernt haben und schließlich erfolgreich eine statische Analyse-Infrastrukturarchitektur für den täglichen Gebrauch durch Softwareentwickler bei Google erstellt haben. Anhand der Eingaben von Ingenieuren können die Tools von Google Tausende von Problemen erkennen, die Ingenieure jeden Tag beheben, bevor problematischer Code in unternehmensweite Code-Repositorys zusammengeführt wird.
In Bezug auf den Toolumfang konzentrieren wir uns auf die Integration der statischen Analyse in den Kernentwicklungsprozess von Google und bedienen die Mehrheit der Google-Entwickler. Viele statische Code-Analysetools werden durch die 2 Milliarden Codezeilen, die bei Google bereitgestellt werden, in den Schatten gestellt, sodass die Technologie zur Durchführung komplexer Analysen in groß angelegten Szenarien keine hohe Priorität hat.
Natürlich muss berücksichtigt werden, dass Entwickler außerhalb von Google, die in Berufsfeldern (z. B. Luft- und Raumfahrt und medizinische Geräte) arbeiten, möglicherweise bestimmte statische Analysetools und Arbeitsabläufe verwenden. Auch Entwickler, deren Entwicklungsprojekte bestimmte Typen (z. B. Kernel-Code und Gerätetreiber) umfassen, benötigen möglicherweise spezielle Analysemethoden. Es gab viele hervorragende Ergebnisse bei der statischen Analyse. Wir glauben nicht, dass die Erfahrungen und Erkenntnisse, die wir zurückgemeldet haben, einzigartig sind, aber wir sind fest davon überzeugt, dass es von Vorteil ist, unsere Arbeit zur Verbesserung der Codequalität und Entwicklungserfahrung von Google zu organisieren und zu teilen .
Begriffsdefinitionen. Wir verwenden die folgende Definition des Begriffs: Ein Analysetool führt einen oder mehrere „Prüfer“ für den Quellcode aus und identifiziert „Defekte“, die zu Softwarefehlern führen können. Wenn ein Entwickler keine proaktiven Maßnahmen ergreift, nachdem er ein Problem entdeckt hat, betrachten wir es als „tatsächliches Fehlalarm“, wenn ein Entwickler auf einen identifizierten Fehler stößt und nicht die entsprechende Lösung ergreift. Wenn die statische Analyse einen gemeldeten Fehler nicht genau identifiziert, der Entwickler aber proaktiv Schritte unternimmt, um den Code zu ändern, um die Lesbarkeit und Wartbarkeit zu verbessern, dann ist dies kein gültiges „falsch positives Ergebnis“. Wenn eine Analyse einen tatsächlichen Codefehler meldet, der Entwickler das Codeproblem jedoch nicht verstanden und keine Maßnahmen ergriffen hat, wird dies als „tatsächliches falsch positives Ergebnis“ betrachtet. Wir nutzen diese konzeptionelle Unterscheidung, um die Bedeutung der F&E-Perspektive hervorzuheben. Der Entwickler, nicht der Tool-Autor, nimmt die Falsch-Positiv-Rate des Tools wahr und beeinflusst sie direkt.
Wie Google Software kompiliert und erstellt
Nachfolgend skizzieren wir die wichtigsten Punkte des Softwareentwicklungsprozesses von Google. Bei Google sind fast alle Entwicklungstools (außer Entwicklungsumgebungen) zentralisiert und standardisiert. Viele Teile der Infrastruktur werden mit Scratch von internen Teams erstellt, wodurch die Flexibilität zum Experimentieren erhalten bleibt.
Quellcodekontrolle und Codebesitz. Google hat ein Single-Source-Codeverwaltungssystem entwickelt und verwendet es. Und experimentieren Sie mit einem einzigen Zweig, der (fast) den gesamten proprietären Code von Google speichert. Entwickler verwenden einen „Trunk-basierten“ Entwicklungsansatz, der Zweige einschränkt und oft nach Releases und nicht nach Features unterteilt. Jeder Ingenieur kann jeden Code mit Zustimmung des Codeeigentümers ändern. Der Codebesitz basiert auf Pfaden; der Besitzer eines Verzeichnisses hat die gleichen Berechtigungen für Unterverzeichnisse.
Systembau. Der gesamte Code in der Google-Codebasis wird mit einer kompilierungsunabhängigen Version von Bazel kompiliert. Das bedeutet, dass alle Eingaben explizit deklariert und in der Quellcodeverwaltung gespeichert werden müssen, um eine einfache Verteilung und Parallelisierung des Builds zu ermöglichen. Java-Regeln im Build-System von Google basieren auf dem JDK und dem quellgesteuerten Java-Compiler, und diese Binärdateien können durch die schnelle Einführung neuer Versionen für alle Benutzer aktualisiert werden. Builds stammen normalerweise aus dem Quellcode (über den Header) und enthalten selten binäre Komponenten, die in Zweige eingecheckt werden. Da alle Entwickler dasselbe Build-System verwenden, kann jeder Code erfolgreich und fehlerfrei kompiliert werden.
Analysetools. Die von Google verwendeten statischen Analysetools sind im Allgemeinen nicht komplex. Die Google-Infrastruktur unterstützt weder die Ausführung interprozeduraler oder programmbasierter Integritätsanalysen auf Systemen auf dieser Ebene noch nutzt sie fortgeschrittene statische Analysetechniken (z. B. Trennungslogik-Technologie) im großen Maßstab. Selbst ein einfacher Prüfer benötigt eine Analyseinfrastruktur, um die Integration in den Workflow zu unterstützen. Zu den Analysetypen, die im Rahmen des allgemeinen Entwicklungsprozesses eingesetzt wurden, gehören:
Stilprüfer (wie Checkstyle, Pylint und Golint);
Erweiterbare Fehlersuch-Compiler (wie Error Prone, ClangTidy, Clang Thread SafetyAnalysis, Govet und CheckerFramework), einschließlich, aber nicht beschränkt auf abstrakte Mustervergleichstools für Syntaxbäume, typbasierte Prüfer und Analysatoren, die nicht aufgerufene Variablen erkennen.
Rufen Sie den Profiler des Produktionsdienstes auf (z. B. prüfen Sie, ob der im Codekommentar erwähnte Mitarbeiter noch bei Google arbeitet);
Überprüfen Sie die Eigenschaften der Build-Ausgabe (z. B. die Größe der Ausgabebinärdatei).
Der C++-Linter von Google kann „goto fail“-Schwachstellen erkennen, indem er überprüft, ob nach der if-Anweisung Klammern stehen. Ein auf Mustervergleich basierender Prüfer würde Datumsformatierungsfehler identifizieren, sodass der Code, der Twitter zum Absturz brachte, nicht mit Google kompiliert werden konnte. Google-Entwickler verwenden außerdem dynamische Analysetools wie AddressSanitizer, um Pufferschwachstellen zu finden, und ThreadSanitizer, um Probleme mit dem Datenwettlauf zu finden. Diese Tools werden während des Testens und manchmal sogar in Umgebungen mit Produktionsverkehr ausgeführt.
Integrierte Entwicklungsumgebung (IDE). Der Einstiegspunkt für statische Analyseprobleme zu Beginn des Entwicklungsprozesses soll in die IDE integriert werden. Da Google-Entwickler jedoch eine Vielzahl von Editoren verwenden, ist es schwierig, Fehler aller Entwickler vor dem Aufrufen des Build-Tools konsistent zu erkennen. Während Google Analysen verwendet, die in beliebte interne IDEs integriert sind, ist es ein langer und mühsamer Weg, eine bestimmte IDE zu benötigen, die Analysen durchführen kann.
Testen. Fast der gesamte Google-Code enthält entsprechende Testlinks, vom Unit-Test bis zum groß angelegten Integrationstest. Testaktivitäten sind die ersten Konzepte, die in den Systemaufbau integriert werden müssen. Sie sind ebenso wie der Kompilierungsprozess unabhängig und verteilt. Bei den meisten Projekten schreiben und pflegen Entwickler Testfälle für den Code; für Projekte gibt es normalerweise keine separate Test- oder Qualitätssicherungsgruppe.
Das kontinuierliche Build- und Testsystem von Google führt jedes Mal Tests durch, wenn der Code übermittelt wird, und liefert zeitnahes Feedback zu Build-Fehlern oder Testfällen, die aufgrund von Codeänderungen der Entwickler fehlschlagen. Es unterstützt auch das Testen von Änderungen vor dem Festschreiben, um eine Unterbrechung der Projektabhängigkeiten zu vermeiden.
Codeüberprüfung. Jeder an Google übermittelte Code durchläuft zunächst die Codeprüfung. Während jeder Entwickler Änderungen an jedem Teil des Google-Codes vornehmen kann, muss der Eigentümer des Codes die Änderungen prüfen und genehmigen, bevor sie zur Zusammenführung eingereicht werden. Darüber hinaus müssen selbst Codebesitzer ihren Code überprüfen, bevor sie Änderungen vornehmen. Codeüberprüfungen werden über ein zentralisiertes, webbasiertes Tool durchgeführt, das eng in andere Entwicklungsinfrastrukturen integriert ist. Statische Analyseergebnisse können in Codeüberprüfungen angezeigt werden.
Code-Veröffentlichung. Google-Teams veröffentlichen häufig Releases, und der Großteil des Release-Überprüfungs- und Bereitstellungsprozesses wird durch „Push-on-Green“-Methoden automatisiert, was bedeutet, dass es schwierig ist, sich auf den mühsamen manuellen Release-Überprüfungsprozess zu verlassen. Wenn ein Google-Ingenieur einen Fehler in der Produktion entdeckt, kann eine neue Version zu relativ geringen Kosten, verglichen mit einer Unterbrechung des Dienstes, zurückgesetzt und auf Produktionsservern bereitgestellt werden.
Lernen von FindBugs
Seit seiner frühen explorativen Forschungsphase von 2008 bis 2010 konzentrierte sich die statische Analysetechnologie von Google auf die Java-Analyse mit FindBug: einem unabhängigen Tool, das von William Pugh von der University of Maryland und David Hovemeyer vom York College of Pennsylvania entwickelt wurde. Werkzeug. Das Prinzip besteht darin, kompilierte Java-Klassendateien zu analysieren und Codestrukturmodelle zu extrahieren, die Fehler verursachen können. Seit Januar 2018 ist FindBugs nur noch ein Befehlszeilentool, das von einer sehr kleinen Anzahl von Ingenieuren bei Google verwendet wird. Ein kleines Google-Team namens „BugBot“ arbeitete mit dem ursprünglichen Autor Pugh zusammen und unternahm drei große Versuche, FindBugs in den Google-Entwicklungsprozess zu integrieren.
Durch Ausprobieren haben wir die folgenden Punkte gelernt:
Versuchen 1: Fehler-Dashboard. Im Jahr 2006 wurde FindBugs erstmals in ein zentralisiertes Tool integriert, das jede Nacht die gesamte Google-Codebasis scannt und die Ergebnisse protokolliert, damit Ingenieure sie über das Dashboard einsehen können. Obwohl FindBugs Hunderte von Fehlern in der Java-Codebasis von Google fand, hatte das Dashboard nur geringe Auswirkungen, da das Fehlermeldungs-Dashboard vom täglichen Entwicklungsprozess getrennt war und nicht in andere vorhandene statische Analyseergebnisse integriert werden konnte.
Versuch 2: Konzentrieren Sie sich auf die Verbesserung von Fehlern.
Dann begann das BugBot-Team, die jede Nacht neu gefundenen Probleme manuell zu klassifizieren und relativ wichtige Fehlerberichte zu identifizieren und zu verarbeiten. Im Mai 2009 nahmen Hunderte von Google-Ingenieuren an einer unternehmensweiten „Fix it“-Woche teil, die sich auf die Behebung von FindBugs-Warnungen konzentrierte. Insgesamt wurden 3.954 Warnungen überprüft (42 % der insgesamt 9.473), aber nur 16 % (640) behoben. Tatsächlich wurden 44 % der gemeldeten Ergebnisse (1746) zur Fehlerrückmeldungsverfolgung eingereicht. Obwohl die Fixit-Kampagne bestätigte, dass es sich bei vielen der von FindBugs gefundenen Probleme um tatsächliche Codefehler handelte, waren viele davon nicht wichtig genug, um tatsächliche Korrekturen zu rechtfertigen. In einer großen Umgebung ist es schwierig, Probleme manuell zu klassifizieren und Fehlerberichte einzureichen.
Versuch 3: In die Codeüberprüfung integrieren. Als nächstes hat das BugBot-Team ein solches System integriert und implementiert: Wenn der Prüfer benachrichtigt wird, dass die Überprüfung aussteht, wird FindBugs automatisch ausgeführt und die Scanergebnisse werden als Kommentare für die Codeüberprüfung angezeigt. Das oben genannte Codeüberprüfungsteam hat das bereits implementiert Codierungsstandards/Stilprobleme Fertig. Google-Entwickler können Fehlalarme ignorieren und FindBugs-Ergebnisse auf Glaubwürdigkeit filtern. Das Tool versucht außerdem, nur neue FindBugs-Warnungen anzuzeigen, behandelt sie jedoch aufgrund einer falschen Klassifizierung manchmal als neue Probleme. Als das Code-Review-Tool im Jahr 2011 ersetzt wurde, endete diese Integration aus zwei Gründen: Hohe Falsch-Positiv-Raten in der Praxis führten dazu, dass Entwickler das Vertrauen in das Tool verloren, und die Freiheit der Entwickler, die Filterung anzupassen, führte dazu, dass alle Parteien die Analyse in Frage stellten . Die Ergebnisse sind inkonsistent.
In den Kompilierungsprozess integriert
Gleichzeitig mit dem FindBugs-Experiment wurde der C++-Entwicklungsprozess von Google weiter verbessert, indem dem Clang-Compiler neue Prüfregeln hinzugefügt wurden. Das Clang-Team implementierte einen neuen Compiler-Checker, einschließlich Korrekturempfehlungsinformationen, führte mit ClangMR in einem verteilten Ansatz eine aktualisierte Compiler-Optimierungsprüfung über die gesamte Google-Codebasis durch und codierte Implementierungskorrekturen für bestehende Fehler in der Codebasis-Frage. Sobald die Codebasis mit behobenen Problemen markiert wurde, wendet das Clang-Team einen neuen Prüfer an, um neue Probleme als Compilerfehler zu kennzeichnen (und nicht als Warnungen, die die Google-Entwickler ignorieren würden), um den Build abzubrechen, der behoben werden muss passieren. Dem Clang-Team ist es mit dieser Strategie sehr gelungen, die Qualität der Codebasis zu verbessern.
Wir sind dieser Idee gefolgt und haben ein einfaches und benutzerfreundliches statisches Java-Analysetool basierend auf der Musteranalyse namens Error Prone entwickelt, das auf dem Javac-Compiler basiert. Die erste eingeführte Prüfregel heißt PreconditionsCheckNotNull und wird verwendet, um zu erkennen, ob der Eingabeparameter für die Methodenerkennung zu Beginn der Programmausführung leer ist, z. B. checkNotNull („uid is null“, uid) anstelle von checkNotNull (uid, „uid“) war null").
Um einen Prüfer wie PreconditionsCheckNotNull zu starten, ohne aufeinanderfolgende Builds zu beschädigen, verwendet das Error Prone-Team ihn, um solche Prüfungen anhand der gesamten Codebasis mithilfe eines Javac-basierten MapReduce-Programms, analog zu ClangMR, unter Verwendung eines FlumeJava-Builds namens JavacFlume durchzuführen. JavacFlume generiert eine Reihe von Korrekturvorschlägen, vergleicht die Unterschiede und wendet diese Korrekturen dann auf die gesamte Codebasis an. Das Error Prone-Team verwendet das interne Tool Rosie, um umfangreiche Codeänderungen in kleinere Änderungen aufzuteilen. Jede Änderung wirkt sich nur auf ein einzelnes Projekt aus, testet diese Änderungen und sendet sie zur Codeüberprüfung an das entsprechende Team. Teams überprüfen nur Korrekturen, die für ihren Code gelten, und nur wenn sie zur Aufnahme genehmigt werden, übernimmt Rosie die tatsächlichen Änderungen. Am Ende wurden alle Reparaturen und Änderungen bestehender Probleme genehmigt und alle vorhandenen Mängel behoben. Das Team hat die Compiler-Fehlermethode offiziell eröffnet.
Als wir Entwickler befragten, die diese Patches erhalten haben, waren 57 % derjenigen, die Fixes erhalten haben, die in den Code integriert wurden, froh, solche Informationen zu erhalten, und 41 % waren neutral. Nur 2 % der Leute reagierten negativ und sagten: „Das erhöht nur meine Arbeitsbelastung.“
Der Wert von Compiler-Prüfungen
Kompilierungsfehler werden frühzeitig im Entwicklungsprozess angezeigt und in den Entwickler-Workflow integriert. Wir haben festgestellt, dass die Erweiterung des Kompilierungsprüfers die Codequalität bei Google effektiv verbessert hat. Da die Prüfungen in Error Prone intern anhand des abstrakten Syntaxbaums von Javac und nicht anhand von Bytecode geschrieben werden (im Gegensatz zu FindBugs), können Entwickler außerhalb des Teams Prüfungen relativ einfach durchführen. Die Nutzung dieser externen Beiträge ist entscheidend für die Steigerung der Gesamtwirkung von Error Prone. Im Januar 2018 haben 162 Autoren 733 Prüfer beigesteuert.
Je früher Sie ein Problem melden, desto besser
Das zentralisierte Build-System von Google zeichnet alle Build-Prozesse und Build-Ergebnisse auf, sodass wir sicherstellen, dass alle Benutzer Fehlermeldungen innerhalb des angegebenen Zeitfensters sehen können. Wir haben ein Umfrage-Feedback an Entwickler gesendet, bei denen kürzlich ein Compilerfehler aufgetreten war, und an Entwickler, die Empfehlungen für eine Behebung desselben Problems erhalten hatten. Google-Entwickler gehen davon aus, dass Probleme, die zur Kompilierzeit gemeldet werden (im Gegensatz zu Patches, die in den Code eingefügt werden), wichtigere Fehler aufdecken. Beispielsweise waren die Umfrageteilnehmer der Meinung, dass 74 % der Probleme zur Kompilierungszeit als „echte Probleme“ gekennzeichnet wurden, verglichen mit nur 21 %; der Probleme wurden im zusammengeführten Code gefunden. Darüber hinaus bewerteten die Umfrageteilnehmer 6 % der zur Kompilierungszeit gefundenen Probleme (gegenüber 0 % während der Zusammenführungsphase) als „kritisch“. Dieses Ergebnis kann durch den „Survivor-Bias-Effekt“ erklärt werden, d. Das Erzwingen möglichst vieler Prüfungen im Compiler ist eine sichere Möglichkeit, diese Kosten zu vermeiden.
Standards für Compiler-Prüfungen
Um unsere Arbeit zu skalieren, da das Unterbrechen der Kompilierung eine größere Aktion sein wird, haben wir Standards für die Aktivierung von Prüfungen im Compiler definiert und ihn auf den strengen High-Note-Modus eingestellt. Compilerprüfungen bei Google sollten einfach zu lesen, umsetzbar und leicht zu beheben sein (wenn möglich sollten Fehlermeldungen allgemein umsetzbare Korrekturvorschläge enthalten) und fehlerfrei sein Code); und melden Sie nur echte Fehler und keine Probleme mit Stil- oder Codierungskonventionen. Das Hauptziel von Messanalysatoren, die diese Kriterien erfüllen, besteht nicht nur darin, Probleme zu erkennen, sondern diese Compilerfehler automatisch in der gesamten Codebasis zu beheben. Diese Standards schränken jedoch auch den Umfang der Überprüfungen ein, die das Error Prone-Team beim Kompilieren von Code ermöglichen kann. Viele Probleme, die nicht genau erkannt oder allgemein behoben werden können, stehen uns immer noch bevor.
Warnmeldungen während der Codeüberprüfungsphase anzeigen
Sobald das Error Prone-Team die erforderliche Infrastruktur zur Erkennung von Problemen zur Kompilierungszeit aufgebaut und bewiesen hat, dass dieser Ansatz effektiv ist, hoffen wir, weitere schwerwiegende Fehler zu finden Wir beschränken uns auf die Überprüfung von Compilerfehlern und liefern Analyseergebnisse für andere Sprachen als Java und C++. Der zweite Integrationseinstiegspunkt für statische Analyseergebnisse ist das Code-Review-Tool von Google – Critique; statische Analyseergebnisse werden in Critique, der Programmanalyseplattform von Google, mithilfe von Tricorder angezeigt. Seit Januar 2018 weisen die C++- und Java-Versionen von Google keine Compilerfehler auf und alle Analyseergebnisse werden in Compilerfehlern oder während der Codeüberprüfungsphase angezeigt.
Standards für Codeüberprüfungsprüfungen
Im Gegensatz zu Überprüfungen zur Kompilierungszeit ermöglichen die während der Codeüberprüfung angezeigten Analyseergebnisse eine effektive Falsch-Positiv-Rate von bis zu 10 %. Das bei Codeüberprüfungen erwartete Feedback ist nicht immer perfekt und Entwickler müssen vorgeschlagene Korrekturen bewerten, bevor sie sie tatsächlich übernehmen. Der Checker von Google während der Code-Audit-Phase sollte die folgenden Kriterien erfüllen:
Einfach zu verstehen. Es ist für Ingenieure klar und leicht verständlich.
Die Lösung ist machbar und leicht zu beheben. Korrekturen erfordern möglicherweise mehr Zeit, Überlegung und Aufwand als die Compiler-Prüfungsphase, und die Ergebnisse der Prüfung sollten Hinweise zur Qualifizierung des Problems enthalten.
Effektive Falsch-Positiv-Rate von weniger als 10 %. Entwickler sollten das Gefühl haben, dass der Prüfer in mindestens 90 % der Fälle tatsächliche Fehler findet – was einen erheblichen Einfluss auf die Codequalität hat. Gefundene Probleme verhindern möglicherweise nicht die ordnungsgemäße Ausführung des Programms, Entwickler sollten sie jedoch ernst nehmen und sich für die Behebung entscheiden.
Einige Probleme sind schwerwiegend genug, um im Compiler gemeldet zu werden, es ist jedoch nicht möglich, sie zu reduzieren oder automatische Korrekturen zu entwickeln. Um beispielsweise einige Probleme zu beheben, ist möglicherweise eine Umgestaltung des Codes erforderlich. Die Aktivierung dieser Prüfungen als Compilerfehler würde eine manuelle Bereinigung der vorhandenen Implementierung erfordern, was bei einer so großen Codebasis wie der von Google nicht möglich ist. Analysetools, die diese Prüfungen in Codeüberprüfungen anzeigen, vermeiden die Einführung neuer Probleme und ermöglichen es Entwicklern zu entscheiden, ob sie Maßnahmen ergreifen, um entsprechende Korrekturen vorzunehmen. Codeüberprüfungen sind auch ein guter Zeitpunkt, um relativ unwichtige Probleme zu melden, wie etwa Spezifikationsprobleme oder die Vereinfachung von optimiertem Code. Unserer Erfahrung nach ist die Berichterstellung während der Kompilierung für Entwickler immer schwierig zu akzeptieren und erschwert eine schnelle Iteration und das Debuggen. Beispielsweise kann ein Detektor für nicht erreichbare Codepfade das Debuggen eines Codeblocks behindern. Aber während einer Codeüberprüfung bereiten sich Entwickler sorgfältig auf die Fertigstellung ihres Codes vor; sie sind empfänglicher für Probleme mit der Lesbarkeit und stilistischen Details.
Tricorder
Tricorder ist leicht erweiterbar und unterstützt viele verschiedene Arten von Programmanalysetools, einschließlich statischer und dynamischer Analysetools. Wir zeigen einige fehleranfällige Prüfer in Tricorder, die nicht als Compilerfehler aktiviert werden können. Error Prone hat außerdem einen neuen Satz von C++-Analysekomponenten namens ClangTidy erstellt, die in Tricorder integriert sind. Die Berichte des Tricorder-Analysators unterstützen Ergebnisse in über 30 Sprachen, unterstützen einfache Syntaxanalysen wie Stilprüfungen, nutzen Compiler-Informationen für Java, JavaScript und C++ und können direkt in Produktionsdaten integriert werden (z. B. Informationen zur aktuell ausgeführten Aufgabenzuweisung). Tricorder ist bei Google weiterhin erfolgreich, da es sich um ein Plug-in-Modell handelt, das eine ökologische Plattform für Analysator-Autoren unterstützt, mögliche Korrekturen während des Codeüberprüfungsprozesses hervorhebt und einen Feedback-Kanal zur Verbesserung des Analysators bietet und sicherstellt, dass Analysator-Entwickler entsprechende Maßnahmen ergreifen positives Feedback.
Ermöglichen Sie Benutzern, Beiträge zu leisten. Mit Stand Januar 2018 umfasst Tricorder 146 Analysegeräte, davon 125 von außerhalb des Tricorder-Teams, und sieben Plugin-Systeme für Hunderte zusätzlicher Prüfungen (z. B. ErrorProne und ClangTidy), davon zwei).
Rezensenten beteiligen sich an der Lösungsvorschläge.
Der Tricorder-Checker kann Codeüberprüfungstools mit angemessenen Reparaturvorschlägen bereitstellen, die für Codeüberprüfer und Entwickler sichtbar sind. Prüfer können Entwickler auffordern, fehlerhaften Code zu beheben, indem sie in den Analyseergebnissen auf die Schaltfläche „Bitte beheben“ klicken. Prüfer genehmigen Codeänderungen in der Regel erst dann zur Aufnahme, wenn alle ihre Kommentare (manuell und automatisch erkannt) berücksichtigt wurden.
Iterieren Sie das Feedback der Benutzer. Zusätzlich zur Schaltfläche „Bitte korrigieren“ bietet Tricorder auch eine Schaltfläche „Nutzlos“, auf die Gutachter oder Antragsteller klicken können, um anzugeben, dass sie mit den Ergebnissen der Analyse nicht einverstanden sind. Durch die Klickaktion wird der Fehler automatisch im Bug-Tracker übermittelt und an das Team weitergeleitet, zu dem der Analysator gehört. Das Tricorder-Team geht diesen „nutzlosen“ Klicks nach und berechnet das Klickverhältnis zwischen „Bitte beheben“- und „nutzlosen“ Klicks. Wenn das Verhältnis des Analysators 10 % überschreitet, deaktiviert das Tricorder-Team den Analysator, bis der Autor ihn verbessert. Während das Tricorder-Team Analysegeräte selten dauerhaft deaktiviert, hat es einige Analysegeräte (in einigen wenigen Szenarien) deaktiviert, bis die Autoren des Analysegeräts Prüfer entfernt und geändert haben, die sich als umständlich und nutzlos herausgestellt haben.
Eingereichte Fehler verbessern häufig die Leistung von Analysatoren und erhöhen dadurch die Zufriedenheit der Entwickler mit diesen Analysatoren erheblich. Beispielsweise hat das Error Prone-Team 2014 eine Prüfung entwickelt, die anzeigt, wenn zu viele Parameter in Guava Passed an eine Funktion wie printf übergeben werden. Printf-ähnliche Funktionen akzeptieren nicht alle printf-Bezeichner, sondern nur %S. Ungefähr einmal pro Woche erhält das Error-Prone-Team einen „dummen“ Fehler, der behauptet, dass die Analyse falsch sei und dass die Anzahl der Format-Platzhalter im Bug-Matching-Code tatsächlich mit der Anzahl der tatsächlich übergebenen Argumente übereinstimme. Wenn der Benutzer versucht, einen anderen Platzhalter als %s zu übergeben, ist der Parser tatsächlich in jedem Fall falsch. Deshalb änderte das Team den Beschreibungstext der Code-Inspektion, um direkt anzugeben, dass die Funktion nur %s Platzhalter akzeptiert und keine Fehler mehr bei dieser Prüfung erhält.
Nutzungsskala des Tricorders. Bis Januar 2018 hat Tricorder etwa 50.000 Codeüberprüfungsänderungen pro Tag analysiert. Zu Spitzenzeiten wird die Analyse dreimal pro Sekunde durchgeführt. Rezensenten klicken mehr als 5.000 Mal am Tag auf „Bitte reparieren“, und Autoren wenden etwa 3.000 Mal am Tag automatische Reparaturlösungen an. Der Tricorder-Analysator erhält eine Rückmeldung von 250 „nutzlosen“ Klicks pro Tag.
Der Erfolg der Code-Review-Analyse zeigt, dass sie den „Sweet Spot“ im Entwickler-Workflow von Google einnimmt. Die zur Kompilierungszeit angezeigten Analyseergebnisse müssen von einer relativen Qualität und Genauigkeit sein, die nicht erreicht werden kann, wenn man sich darauf verlässt, dass der Analysator weiterhin schwerwiegende Probleme erkennt. Nachdem Überprüfungen und Code zusammengeführt wurden, stoßen Entwickler auf zunehmenden Widerstand gegen Änderungen. Infolgedessen fällt es Entwicklern schwer, Änderungen an Code vorzunehmen, der bereits getestet und veröffentlicht wurde, und es ist weniger wahrscheinlich, dass sie risikoarme und weniger wichtige Probleme angehen. Viele andere Analyseprojekte in Softwareentwicklungsorganisationen (z. B. Facebook Infer Analytics für Android-/iOS-Apps) betonen ebenfalls die Codeüberprüfung als wichtigen Einstiegspunkt für die Berichterstattung über Analyseergebnisse.
Erweiterter Analysator
Während Google-Entwickler die Ergebnisse des Tricorder-Analysators akzeptieren, fordern sie weiterhin weitere Erweiterungen des Analysators. Tricorder löst dieses Problem auf zwei Arten: durch die Möglichkeit der Anpassung auf Projektebene und durch das Hinzufügen von Ergebnissen der Präsentationsanalyse zu anderen Zeitpunkten im Entwicklungsprozess. In diesem Abschnitt diskutieren wir auch einige der Gründe, warum Google noch keine ausgefeilteren Analysen als Kernentwicklungsprozess genutzt hat.
Anpassung auf Projektebene
Nicht alle angeforderten Analysatoren sind in der gesamten Google-Codebasis von gleichem Wert. Beispielsweise sind einige Analysatoren mit höheren Falsch-Positiv-Raten verbunden, sodass möglicherweise ein Prüfer mit einer entsprechend hohen Falsch-Positiv-Rate erforderlich ist nur gültig, wenn es in einem bestimmten Projekt aktiviert ist. Diese Profiler sind nur für die richtigen Teams nützlich.
Um diese Anforderungen zu erfüllen, ist es unser Ziel, Tricorder anpassbar zu machen. Unsere bisherigen Erfahrungen mit der Anpassung von FindBugs waren weniger effektiv; die Anpassung auf Benutzerebene führte zu einer Differenzierung innerhalb und zwischen Teams, was zu einer geringeren Tool-Nutzung führte. Da jeder Benutzer eine andere Ansicht eines Problems sehen kann, kann nicht sichergestellt werden, dass jeder, der an demselben Projekt arbeitet, ein bestimmtes Problem sehen kann. Wenn ein Entwickler alle nicht verwendeten Importe aus dem Code seines Teams entfernt, wird die Änderung durch das Rollback schnell abgelehnt, selbst wenn ein anderer Entwickler beim Entfernen nicht verwendeter Importe inkonsistent ist.
Um solche Probleme zu vermeiden, erlaubt Tricorder nur die Konfiguration auf Projektebene und stellt so sicher, dass jeder, der Änderungen an einem bestimmten Projekt vornimmt, eine konsistente Ansicht der Analyseergebnisse im Zusammenhang mit diesem Projekt sieht. Durch die Wahrung der Konsistenz in der Ergebnisansicht können verschiedene Arten von Analysegeräten die folgenden Aktionen ausführen:
Binäre Ergebnisse erzeugen. Tricorder enthält beispielsweise einen Parser für Protokollpufferdefinitionen, der abwärtsinkompatible Änderungen identifiziert. Dies wird von Entwicklerteams verwendet, um persistente Informationen in Protokollpuffern in serialisierter Form sicherzustellen, ist jedoch für Teams, die Daten nicht in dieser Form speichern, ärgerlich. Ein weiteres Beispiel sind Analysatoren, die für die Verwendung durch Guava- oder Java-Code-Implementierungen empfohlen werden, die für Projekte, die diese Bibliotheken oder Sprachfunktionen nicht nutzen können,
keine spezifischen Einrichtungs- oder In-Code-Anmerkungen erfordern. Beispielsweise können Teams die Nullheit des Checker-Frameworks nur zur Analyse verwenden, wenn ihr Code ordnungsgemäß mit Anmerkungen versehen ist. Ein weiterer Analysator, der bei richtiger Konfiguration das Wachstum der Binärgröße und die Anzahl der Funktionsaufrufe für eine bestimmte Android-Binärdatei überprüft und Entwickler warnt, wenn das Wachstum zu erwarten ist oder sich dem Limit nähert.
Unterstützung für domänenspezifische Sprachen (DSL) ) und teamspezifische Kodierungsrichtlinien. Einige Softwareentwicklungsteams von Google haben einige kleine DSLs entwickelt und möchten entsprechende Prüfer ausführen. Andere Teams haben Best Practices für Lesbarkeit und Wartbarkeit implementiert und möchten diese Prüfungen weiterhin durchsetzen, obwohl sie sehr ressourcenintensiv sind. Ein Fall einer Hybridanalyse basierend auf den Ergebnissen der enthaltenen dynamischen Analyse. Eine solche Analyse bietet für einige Teams einen hohen Mehrwert, ist jedoch für alle zu kostspielig oder zu zeitaufwändig.
Stand Januar 2018 gibt es bei Google etwa 70 optionale Analysen, wobei 2.500 Projekte mindestens eine davon ermöglichen. Dutzende Teams im gesamten Unternehmen entwickeln aktiv neue Analysegeräte, die meisten davon außerhalb der Entwicklungstools-Gruppe.
Andere Workflow-Integrationspunkte
Da das Vertrauen der Entwickler in diese Tools wächst, fordern sie auch eine weitere Integration in ihre Workflows. Tricorder liefert jetzt Analyseergebnisse durch die Bereitstellung von Befehlszeilentools, kontinuierlichen Integrationssystemen und Codeüberprüfungstools.
Befehlszeilenunterstützung. Das Tricorder-Team hat Befehlszeilenunterstützung für Entwickler hinzugefügt, die im Wesentlichen Code-Manager sind und häufig verschiedene Alarmanalysen in der Codebasis des Teams durchsuchen und bereinigen. Diese Entwickler sind auch mit den Arten von Korrekturen, die jeder Analysator erzeugen wird, bestens vertraut und haben ein hohes Maß an Vertrauen in einen bestimmten Analysator. So können Entwickler Befehlszeilentools verwenden, um alle Korrekturen in einer bestimmten Analyse automatisch anzuwenden und saubere Änderungen vorzunehmen
Code-Commit-Schwellenwert. Einige Teams möchten, dass bestimmte Analysatoren Code-Commits blockieren, anstatt nur in Code-Review-Tools aufzutauchen. Typischerweise werden Anfragen nach der Möglichkeit, Commits zu blockieren, von Teams mit hochgradig angepassten Prüfern gestellt, die garantieren, dass keine Fehlalarme auftreten, häufig in benutzerdefinierten DSLs oder Bibliotheken.
Code zeigt die Ergebnisse. Codepräsentationen eignen sich am besten, um das Ausmaß von Problemen in großen Projekten (oder ganzen Codebasen) darzustellen. Beispielsweise können Analyseergebnisse beim Durchsuchen von Code für eine veraltete API zeigen, wie viel Arbeit für die Migration erforderlich ist, oder einige Sicherheits- und Datenschutzanalysen sind global und erfordern die Überprüfung der Ergebnisse durch ein professionelles Team, bevor festgestellt wird, ob ein Problem vorliegt. Da Analyseergebnisse nicht standardmäßig angezeigt werden, ermöglicht der Code Browser bestimmten Teams, Analyseansichten zu aktivieren und dann die gesamte Codebasis zu scannen und die Ergebnisse zu überprüfen, ohne andere Entwickler von diesen Analysatoren abzulenken. Wenn den Analyseergebnissen ein Fix zugeordnet ist, kann der Entwickler den Fix anwenden, indem er einfach auf das Code-Browsing-Tool klickt. Code Browser eignet sich auch hervorragend zum Anzeigen von Analyseergebnissen der Produktionsdatennutzung, da diese Daten erst verfügbar sind, wenn der Code festgeschrieben und ausgeführt wird.
Komplexe Analyse
Alle bei Google weit verbreiteten statischen Analysen sind relativ einfach, obwohl einige Teams prozessübergreifende Analysen mit projektspezifischen Analyse-Frameworks durchführen, die auf bestimmte Domänen abzielen (z. B. Android-Apps). Prozessanalysen im Google-Maßstab sind technisch machbar. Die Umsetzung einer solchen Analyse ist jedoch sehr schwierig. Wie oben erwähnt, wird der gesamte Google-Code in einem separaten Gesamtquellcode-Repository gespeichert, sodass konzeptionell jeder Code im Code-Repository Teil einer beliebigen Binärdatei sein kann. Man kann sich daher eine Situation vorstellen, in der die Analyseergebnisse einer bestimmten Codeüberprüfung eine Analyse des gesamten Code-Repositorys erfordern würden. Während sich Facebooks Infer auf die interprozedurale Analyse konzentriert, erfordert die Skalierung von Split-Logic-basierten Analysatoren auf Codebasen mit mehreren Millionen Zeilen immer noch einen erheblichen technischen Aufwand für die Skalierung eines solchen Analysators auf die Code-Repositorys mit mehreren Milliarden Zeilen. Stand Januar 2018: Die Implementierung eines ausgefeilteren Analysesystems hat für Google keine Priorität:
Erhebliche Investition. Die Vorabinvestitionen in die Infrastruktur werden unerschwinglich sein.
Es sind Anstrengungen erforderlich, um die Fehlalarmraten zu reduzieren. Analyseteams müssen Techniken entwickeln, um die Falsch-Positiv-Rate bei vielen Analysegeräten deutlich zu reduzieren und/oder die Anzeige von Fehlermeldungen streng einzuschränken, wie Figureinfer es tut
Es gibt noch mehr zu implementieren; Analytics-Teams verfügen immer noch über „einfacher“ zu implementierende und zu integrierende Analysegeräte.
Hohe Vorabkosten. Wir finden, dass dieser „einfache“ Analysator sehr kostengünstig ist, was eine der Hauptmotivationen für FindBugs ist. Im Vergleich dazu sind die Vorabkosten hoch, selbst wenn der Kosten-ROI für anspruchsvollere Prüfer ermittelt wird.
Bitte beachten Sie, dass dieser ROI für Entwickler außerhalb von Google, die in Spezialbereichen (z. B. Luft- und Raumfahrt und medizinische Geräte) oder an bestimmten Projekten (z. B. Gerätetreibern und mobilen Anwendungen) arbeiten, erheblich variieren kann.
Einblicke
Unsere Erfahrung beim Versuch, statische Analysen in Google-Workflows zu integrieren, hat uns die folgenden wertvollen Erkenntnisse gelehrt:
Fehler zu finden ist einfach. Wenn eine Codebasis groß genug ist, enthält sie nahezu jedes erdenkliche Codemuster. Selbst in ausgereiften Codebasen mit vollständiger Testabdeckung und strengen Codeüberprüfungsprozessen sind Fehler groß. Manchmal sind Probleme bei einer Inspektion vor Ort nicht offensichtlich, und manchmal werden Fehler durch scheinbar harmlose Umgestaltungen eingeführt. Betrachten Sie zum Beispiel den folgenden Codeausschnitt, der das Feld f vom Typ long verwendet:
result =
31 * result
Stellen Sie sich als nächstes vor, was passiert, wenn der Entwickler den Typ von f in int ändert. Der Code wird weiter kompiliert, aber der rechte Offset von 32 wird zu einer No-Op-Operation, das Feld wird mit sich selbst XOR-verknüpft und der Hash-Wert der Variablen wird zu einer konstanten 0. Das Ergebnis ist, dass f den von erzeugten Wert nicht mehr beeinflusst die hashCode-Methode. Jedes Tool, das den Typ von f berechnen kann, kann den richtigen Offset von mehr als 31 korrekt erkennen. Wir haben diesen Fehler im 31-Code in der Codebasis von Google behoben und die Prüfung auch in die Kompilierung in Error Pone Server Error aufgenommen.
Da es einfach ist, Fehler zu erkennen, verwendet Google einfache Tools, um Fehlertypen zu erkennen. Als Nächstes führt der Analyseautor basierend auf den Ergebnissen der Ausführung von Google-Code eine Feinabstimmung durch.
Die meisten Entwickler verwenden statische Analysetools nicht so oft, wie sie denken. Wie bei der Entwicklung vieler kommerzieller Tools verließen sich Google zunächst auf die Implementierung von FindBugs. Die Ingenieure entschieden sich für den Zugriff auf ein zentrales Dashboard, um die in ihren Projekten gefundenen Probleme anzuzeigen, aber nur wenige von ihnen sahen dies tatsächlich so. Es ist zu spät, Fehler zu finden, die in den Code integriert wurden (der möglicherweise bereitgestellt und ausgeführt wurde, ohne dass Benutzer das Problem bemerkten). Um sicherzustellen, dass die meisten oder alle Ingenieure statische Analysewarnungen sehen, muss das Analysetool in den Workflow integriert und standardmäßig für alle aktiviert sein. Projekte wie Error Prone stellen kein Fehler-Dashboard zur Verfügung, sondern erweitern den Compiler um zusätzliche Checker und zeigen die Analyseergebnisse beim Code-Review an.
Entwicklergefühle sind entscheidend. Nach unserer Erfahrung und Materialsammlung sind viele Versuche, statische Analysen in Softwareentwicklungsorganisationen zu integrieren, gescheitert. Ingenieure sind von der Google-Verwaltung im Allgemeinen nicht dazu autorisiert, statische Analysetools zu verwenden. Ingenieure, die an statischen Analysen arbeiten, müssen ihre Auswirkungen anhand gültiger realer Daten nachweisen. Damit ein statisches Analyseprojekt erfolgreich ist, müssen Entwickler erkennen, dass sie davon profitieren und den Wert seiner Nutzung genießen.
Um eine erfolgreiche Analyseplattform aufzubauen, entwickeln wir Tools, die Entwicklern einen hohen Mehrwert bieten. Das Tricorder-Team wird die behobenen Probleme sorgfältig prüfen, tatsächliche Umfragen durchführen, um zu verstehen, wie Entwickler denken, es mithilfe von Analysetools einfacher machen, Fehler einzureichen, und alle diese Daten zur kontinuierlichen Verbesserung nutzen. Entwickler müssen Vertrauen in Analysetools aufbauen. Wenn ein Tool Entwicklerzeit mit Fehlalarmen und Rückmeldungen zu Problemen auf niedriger Ebene verschwendet, verlieren Entwickler das Vertrauen und ignorieren die Ergebnisse.
Finden Sie Fehler nicht nur, sondern beheben Sie sie. Ein typischer Ansatz zur Förderung statischer Analysetools besteht darin, eine große Anzahl von Problemen in der Codebasis aufzulisten. Der Zweck besteht darin, das Handeln zu beeinflussen, indem auf mögliche Fehler hingewiesen wird, die behoben werden müssen, oder das Auftreten von Fehlern in der Zukunft zu verhindern. Wenn Entwickler jedoch keinen Anreiz erhalten, Maßnahmen zu ergreifen, bleibt dieses potenziell gewünschte Ergebnis unerfüllt. Das ist ein grundlegender Fehler: Analysetools messen ihren Nutzen an der Anzahl der identifizierten Probleme, während die Prozessintegration bereits an einer Handvoll Fehlerbehebungen scheitert. Im Gegenteil, das statische Analyseteam von Google ist für die entsprechenden Reparaturarbeiten sowie das Auffinden von Fehlern verantwortlich und nutzt dies als Kriterium für einen erfolgreichen geschlossenen Regelkreis. Durch die Konzentration auf die Behebung von Fehlern wird sichergestellt, dass das Tool umsetzbare Empfehlungen liefert und Fehlalarme minimiert. In vielen Fällen ist das Beheben von Fehlern so einfach wie das Auffinden mithilfe automatisierter Tools. Selbst für schwer lösbare Probleme hat die Forschung der letzten fünf Jahre neue Techniken zur automatischen Erstellung von Lösungen für statische Analyseprobleme aufgezeigt.
Analysatorentwicklung erfordert gemeinsame Anstrengungen. Während für bestimmte statische Analysetools erfahrene Entwickler das Verfassen der Analyse erfordern, wissen möglicherweise nur wenige Experten tatsächlich, welche Prüfungen größere Einflussfaktoren erzeugen. Darüber hinaus sind Analysator-Experten oft keine Domänenexperten (z. B. diejenigen, die mit APIs, Sprachen und Sicherheit arbeiten). Integration über FindBugs Nur eine Handvoll Google-Mitarbeiter wussten, wie man den neuen Checker schreibt, sodass das kleine BugBot-Team die gesamte Arbeit selbst erledigen musste. Dies begrenzt die Geschwindigkeit, mit der neue Prüfungen hinzugefügt werden können, und verhindert effektiv, dass andere von ihren Domänenwissensbeiträgen profitieren. Teams wie Tricorder konzentrieren sich nun darauf, die Standards für von Entwicklern bereitgestellte Prüfungen zu senken, ohne dass dafür vorherige Erfahrung in der statischen Analyse erforderlich ist. Mit dem Google-Tool Refaster beispielsweise können Entwickler Checker schreiben, indem sie Beispiele vor und nach Codeschnipseln angeben. Da Mitwirkende oft motiviert sind, einen Beitrag zu leisten, nachdem sie fehlerhaften Code selbst debuggt haben, werden die neuen Prüfungen den Entwicklern im Laufe der Zeit Zeit sparen.
Fazit
Unsere Erfahrung ist, dass die Integration in den Entwicklungsprozess der Schlüssel zur Implementierung statischer Analysetools ist. Während die Autoren von Prüftools glauben, dass Entwickler froh sein sollten, wenn sie mit Fehlerlisten in dem von ihnen geschriebenen Code konfrontiert werden, stellen wir tatsächlich nicht fest, dass solche Listen Entwickler dazu motivieren, diese Fehler zu beheben. Als Entwickler von Analysetools müssen wir die Messeffektivität anhand der tatsächlich behobenen Fehler definieren, anstatt den Entwicklern Zahlen zu nennen. Das bedeutet, dass unsere Verantwortung weit über die eigentlichen Analysetools hinausgeht.
Wir plädieren für ein System, das darauf ausgerichtet ist, die Workflow-Integration so früh wie möglich voranzutreiben. Aktivieren Sie den Prüfer nach Möglichkeit als Compilerfehler. Um zu vermeiden, dass störende Build-Tool-Autoren zunächst alle vorhandenen Probleme in der Codebasis beheben müssen, können wir die Qualität der Codebasis von Google Schritt für Schritt kontinuierlich verbessern. Da wir Fehlerwarnungen im Compiler anzeigen, beheben Entwickler diese sofort nach dem Schreiben des Codes, sodass sie dennoch rechtzeitig Änderungen vornehmen können. Um dies zu erreichen, haben wir die Infrastruktur entwickelt, um Analysen durchzuführen und Korrekturen in der umfangreichen Google-Codebasis zu generieren. Wir profitieren auch von Codeüberprüfungen und Commit-Automatisierung, die Änderungen an Hunderten von Dateien ermöglichen, und natürlich von einer Ingenieurskultur, die häufig Änderungen toleriert, die in Legacy-Code integriert werden, weil die Verbesserung des Codes die Abneigung gegenüber dem Risiko einer Änderung überwiegt.
Die Codeüberprüfung ist der beste Einstiegspunkt, um Analysewarnungen anzuzeigen, bevor Code festgeschrieben wird. Um sicherzustellen, dass Entwickler die Analyseergebnisse akzeptieren, zeigt Tricorder nur Probleme während der Codeänderungsphase des Entwicklers an, bevor die Änderung übernommen wird, und das Tricorder-Team wendet eine Reihe von Kriterien an, um auszuwählen, welche Warnungen angezeigt werden sollen. Darüber hinaus sammelt Tricorder Statistiken im Code-Review-Tool, mit denen die Grundursache dafür ermittelt wird, dass der Analysator eine große Anzahl ungültiger Warnungen generiert.
Um die Vernachlässigung von Alarmen zu überwinden, haben wir hart daran gearbeitet, das Vertrauen der Google-Ingenieure zurückzugewinnen, und haben herausgefunden, dass Google-Entwickler eine starke Tendenz haben, statische Analysen zu ignorieren, und jeder Bericht mit einer unbefriedigenden Falsch-Positiv-Rate gibt ihnen einen Grund dazu Nichts. Das Analyseteam achtet sehr darauf, Inspektionsergebnisse erst dann als Fehler oder Warnungen anzuzeigen, wenn sie anhand beschreibender objektiver Kriterien überprüft wurden, sodass Entwickler selten von Analyseergebnissen überwältigt, verwirrt oder verärgert werden. Umfragen und Feedbackkanäle sind für diesen Prozess wichtige Methoden zur Qualitätskontrolle. Nachdem Entwickler nun wieder Vertrauen in die Analyseergebnisse gewonnen haben, befasst sich das Tricorder-Team mit der Notwendigkeit, mehr Analysen stärker in die Arbeitsabläufe der Google-Entwickler einzubeziehen.
Wir haben bei Google eine erfolgreiche statische Analyseinfrastruktur aufgebaut, die verhindert, dass täglich Hunderte von Fehlern in die Google-Codebasis gelangen, sowohl zur Kompilierungszeit als auch während der Codeüberprüfung. Wir hoffen, dass andere von unserer Erfahrung profitieren und statische Analysen erfolgreich in ihre eigenen Arbeitsabläufe integrieren können.
Das obige ist der detaillierte Inhalt vonGoogles Fallstudie zum Aufbau statischer Code-Analysetools. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
