Nehmen Sie die statische Analyse in Babyschritten an

Da immer mehr von uns von zu Hause aus arbeiten, ist es wichtiger denn je, dass der von uns erstellte Code so gut wie möglich ist. Die statische Analyse ist ein perfekter Schwerpunkt für Softwareentwickler sowie Sicherheits- und funktionale Sicherheitsexperten.

Wir alle wissen, dass wir statische Code-Analyse durchführen sollten. Einige von uns wissen, dass wir es tun sollten, weil es uns helfen wird. Andere haben möglicherweise das Gefühl, dass ihnen statische Analysen aufgezwungen werden und dass dies Zeitverschwendung, mühsam oder Arbeit mit geringem Nutzen ist. Obwohl ich sagen möchte, dass diese Leute falsch liegen, haben sie leider wahrscheinlich Recht!

Mehr abbeißen, als Sie kauen können

Wenn die statische Analyse langsam, verrauscht (falsch positiv), schmerzhaft zu verwenden, Arbeit zu schaffen oder keinen Wert zu liefern ist, liegt dies normalerweise daran, dass Sie mehr abgebissen haben, als Sie kauen können. Richtige Konfiguration Die Anzahl der statischen Analysewerkzeuge ist ebenfalls ein wichtiger Faktor, aber das ist an und für sich ein ganz anderes Thema, und das werde ich in einem anderen Beitrag behandeln.

In diesem Beitrag möchte ich mich auf einen Fehler konzentrieren, den viele Erstanwender der statischen Analyse machen – zu früh zu viel zu tun. Insgesamt ist es entscheidend für den Erfolg, dass der Workflow und die Konfiguration der statischen Analyse von Anfang an korrekt sind – weniger Aufwand, mehr Gewinn. Der erste Schritt ist, sicherzustellen, dass Sie es haben das richtige Werkzeug für Ihre Organisation.

Beginnen Sie klein mit der statischen Analyse

Sobald Sie das statische Code-Analyse-Tool ausgewählt haben, müssen Sie es konfigurieren. Welche Checker möchten Sie ausführen? Ich würde mit einer einfachen Richtlinie beginnen: Es ist besser, mit einer kleinen Gruppe von Prüfern zu beginnen, bei Bedarf sogar nur mit einem Prüfer, und sicherzustellen, dass Sie und Ihr Team Ihre statischen Analysefähigkeiten und Ihren Workflow verbessern und nachweislich von den Anstrengungen profitieren. Die häufigste Alternative besteht darin, hundert oder mehr Prüfer einzuschalten, die umfangreiche Berichte erstellen, die Sie sporadisch bearbeiten.

Statische Analysewerkzeuge können viel Rauschen erzeugen, bis sie aufrecht stehen. Wenn ich sage "mehr abbeißen, als Sie kauen können", das Geräusch (manchmal genannt Fehlalarm) überwältigt die wichtigen Warnungen. Eine frühzeitige Einführung beginnt manchmal als akademische Verfolgung mit der Absicht einer frühzeitigen Untersuchung, um ein Gefühl dafür zu bekommen, wie viele Fehler in der Codebasis enthalten sind. Diese Methode berücksichtigt nicht den Entwickler-Workflow und die tägliche Verwendung von Tools. Es passt auch nicht zu der pragmatischen Notwendigkeit, Software zu schreiben, zu testen und auf den Markt zu bringen.

Der beste Ansatz ist, klein anzufangen, um die Qualität des Codes ständig und schrittweise zu verbessern. Beseitigen Sie Ihre problematischsten kritischen Codeprobleme und erweitern Sie sie, um nach anderen Problemen zu suchen, die immer noch wichtig, aber möglicherweise nicht ganz so gefährlich sind. Schauen wir uns an, wie das im praktischen Sinne funktioniert.

Bewältigen Sie zuerst die großen Probleme

Manchmal versuchen Organisationen, eine Konfigurationsliste von Prüfern im Konsens zusammenzustellen, basierend auf einer großen Liste aller möglichen Prüfer, die ein statisches Analysetool bereitstellt. Obwohl plausibel, wenn man bedenkt, dass Parasoft-Tools über tausend Prüfer verfügen, ist der Ansatz fehlerhaft, da er sich auf die Funktionen des Tools konzentriert und nicht auf die tatsächlichen Probleme, mit denen Ihre Anwendung aufgrund des Kundensupports, der erwarteten Umgebung usw. konfrontiert ist auf.

Teams können viel Zeit damit verbringen, Verstöße von Prüfern zu verfolgen, die nicht viel Wert bieten, selbst wenn der Fehlertyp abstrakt wichtig erscheint. Es ist wichtig, die statische Analyse mit den tatsächlichen Problemen zu verbinden, die das Team löst oder denen es voraussichtlich begegnen wird. Es ist wichtig, die Liste der Prüfer einzugrenzen, aber es kann immer noch zu viele Verstöße für ein Team oder Projekt geben, das gerade erst anfängt. Sie müssen sich die Größe des „Bisses“ ansehen, den Sie nehmen.

Begrenzen Sie den „Biss“ der statischen Analyse

Eine gute Möglichkeit, die Größe des Bisses zu minimieren (es ist nicht nur die Anzahl der Prüfer), besteht darin, zu bewerten, gegen welchen Code Sie ihn ausführen. Die meisten Projekte bestehen heutzutage aus vorhandenen, älteren oder geerbten Codebasen. Wenn diese groß genug sind, ist es nicht praktisch, eine statische Analyse dieses Codes durchzuführen und Ressourcen zur Behebung von Problemen bereitzustellen. Sie müssen den „Biss“ in Bezug auf die Menge des analysierten Codes begrenzen.

Ein gängiger Ansatz besteht darin, die Aktion für gemeldete Warnungen auf neu entwickelten oder kürzlich geänderten Code zu beschränken. Zum Beispiel entscheidet der Teamleiter, dass beim nächsten Sprint der gesamte neue Code mit einem Startsatz priorisierter Prüfer analysiert wird. Der erste Satz von Analyseberichten wird verwendet, um den Arbeitsaufwand zu messen. Wenn dies für einen Sprint zu viel ist, kann die Analyse weiter eingeschränkt werden. Wenn dieser Ansatz jedoch nicht genügend Warnungen erzeugt oder Qualitätsziele verfehlt werden, erhöhen Sie den Umfang.

All dies zu sagen: Nehmen Sie einen kleinen Bissen, einen hochwertigen Biss. Repariere es, erreiche etwas, baue es in deinen täglichen Prozess und in deine Kultur ein. Langsam hinzufügen. Setzen Sie ein paar weitere Steine, und schließlich erreichen Sie Ihr angestrebtes Ziel aller zu Beginn gewünschten Steine.

Beobachten und steigern Sie den Wert der statischen Analyse im Laufe der Zeit

Klein anfangen ist mehr als die Steuerung eines überschaubaren Workflows. Es hilft auch den Entwicklern, die neu in der Technik und neu im Werkzeug sind, den Wert schnell zu erkennen. Indem sie ihnen zuerst kritische Ergebnisse geben, sehen sie Fehler, die wichtig sind, um zu beheben und zu verstehen, wie Tests oder Codeüberprüfungen sie möglicherweise übersehen haben. Während Sie die Analyse vorantreiben, erhalten Entwickler immer die umsetzbarsten Ergebnisse. Das Ziel ist es, niemals dahin zu gelangen, wo Sie Entwicklern Warnungen mit geringem Wert geben. Es ist eine Verschwendung von Zeit und Werkzeugen, und Sie sollten Ihre Prozesse nutzen, um diese herauszufiltern.

Vermeiden Sie Triage

Es ist nicht ungewöhnlich, dass bei der Erörterung der Ergebnisse der statischen Code-Analyse eine Triage auftritt. Triage wird im wirklichen Leben nur verwendet, wenn ein Prozess überfordert ist. Softwareteams, die zu viel Geld in Anspruch nehmen, führen statische Analysetools auf einer großen Codebasis mit aktivierten Standardprüfern aus und erhalten unweigerlich viele Warnungen. Sie versuchen dann, sie durchzugehen und zu sagen, welche muss ich reparieren? Welche sind am wichtigsten? Dies ist langwierig, übermäßig subjektiv, fehleranfällig und meistens unnötig.

Werkzeuge sollten für Sie suchen. Wenn nicht, haben Sie wahrscheinlich das falsche Tool, die falsche Konfiguration oder den falschen Ansatz. Ein modernes statisches Analysetool muss in der Lage sein, Warnungen nach Schweregrad, Priorität und inhärentem Risiko zu filtern. Lassen Sie sich nicht vom Werkzeug selbst zwingen, einen zu großen Bissen zu nehmen.

Zusammenfassung

Hoffentlich finden Sie diesen Rat hilfreich. Die erfolgreiche Einführung der statischen Analyse erfordert kleine Schritte, bevor Fortschritte bei der Verbesserung von Qualität, Sicherheit und Sicherheit erzielt werden. Begrenzen Sie, wie viel Ihr Team "abbeißt", indem Sie den Umfang der Analyse sowohl in Bezug auf die Prüfer als auch auf die Menge des Codes einschränken - jeder kann den Wert sehen. Durch das Vermeiden von „zu großen Bissen“ werden viele der häufigsten Beschwerden über statische Analysewerkzeuge vermieden. Kontinuierliche und schrittweise Verbesserungen helfen jedem, den Umgang mit statischen Analysen zu erlernen und einen besseren Wert für die Investition zu erzielen.