Als u het eindeloze reviewen of debuggen van code beu bent, denkt u er soms over na hoe u uw leven kunt vereenvoudigen. En na een beetje zoeken, of als je er per ongeluk op stuit, zie je de magische uitdrukking: “Statische analyse”. Laten we eens kijken wat het is en hoe het kan interageren met uw project.
Als je in welke moderne taal dan ook schrijft, heb je het, zonder het zelfs maar te beseffen, door een statische analysator gehaald. Feit is dat elke moderne compiler, zij het een klein aantal, waarschuwingen geeft over mogelijke problemen in de code. Wanneer u bijvoorbeeld C++-code compileert in Visual Studio, ziet u mogelijk het volgende:
In deze uitvoer zien we dat de variabele var werd nooit ergens in de functie gebruikt. Dus in werkelijkheid gebruikte je bijna altijd een eenvoudige statische code-analysator. In tegenstelling tot professionele analysers zoals Coverity, Klocwork of PVS-Studio kunnen de waarschuwingen van de compiler echter slechts een klein aantal problemen aangeven.
Als u niet zeker weet wat statische analyse is en hoe u dit moet implementeren, om meer te weten te komen over deze methodiek.
Waarom heb je statische analyse nodig?
Kortom: versnelling en vereenvoudiging.
Met statische analyse kunt u veel verschillende problemen in de code vinden: van onjuist gebruik van taalconstructies tot typefouten. In plaats van bijvoorbeeld
auto x = obj.x;
auto y = obj.y;
auto z = obj.z;Je hebt de volgende code geschreven:
auto x = obj.x;
auto y = obj.y;
auto z = obj.x;Zoals je kunt zien, staat er een typefout in de laatste regel. PVS-Studio geeft bijvoorbeeld de volgende waarschuwing:
Overweeg om de juistheid van het gebruik van 'y'-item te controleren.
Als je deze fout wilt ontdekken, probeer dan een kant-en-klaar voorbeeld in Compiler Explorer: **.
En zoals je begrijpt, is het niet altijd mogelijk om meteen aandacht aan dergelijke delen van de code te besteden, en daarom kun je een goed uur gaan zitten debuggen en je afvragen waarom alles zo vreemd werkt.
Dit is echter duidelijk een vergissing. Wat als de ontwikkelaar suboptimale code schreef omdat hij een subtiliteit van de taal vergat? Of stond het zelfs toe in de code ? Helaas zijn dergelijke gevallen heel gewoon en wordt het leeuwendeel van de tijd besteed aan het debuggen van specifiek werkende code die typefouten, typische fouten of ongedefinieerd gedrag bevat.
Het is voor deze situaties dat statische analyse verscheen. Dit is een assistent voor de ontwikkelaar die verschillende problemen in de code aanwijst en in de documentatie uitlegt waarom het niet nodig is om op deze manier te schrijven, waar dit toe kan leiden en hoe u dit kunt oplossen. Hier is een voorbeeld van hoe het eruit zou kunnen zien: **.
Meer interessante fouten die de analysator kan detecteren, vindt u in de artikelen:
Nu u dit materiaal heeft gelezen en overtuigd bent van de voordelen van statische analyse, wilt u het misschien eens uitproberen. Maar waar te beginnen? Hoe integreer je een nieuwe tool in je huidige project? En hoe stel je het team aan hem voor? Antwoorden op deze vragen vindt u hieronder.
Opmerking. Statische analyse vervangt of annuleert zoiets nuttigs als codebeoordelingen niet. Het vormt een aanvulling op dit proces en helpt typefouten, onnauwkeurigheden en gevaarlijke ontwerpen vooraf op te merken en te corrigeren. Het is veel productiever om je te concentreren op codebeoordelingen van algoritmen en duidelijkheid van de code, in plaats van te zoeken naar verkeerd geplaatste haakjes of .
0. Kennismaken met de tool
Het begint allemaal met een proefversie. Het is inderdaad moeilijk om te beslissen iets in het ontwikkelingsproces te introduceren als je de tool nog nooit eerder live hebt gezien. Daarom is het eerste wat u moet doen downloaden .
Wat je in deze fase leert:
- Wat zijn de manieren om met de analysator te communiceren;
- Is de analyser compatibel met uw ontwikkelomgeving?
- Welke problemen zijn er momenteel in uw projecten?
Nadat u alles heeft geïnstalleerd wat u nodig heeft, moet u eerst een analyse van het hele project uitvoeren (, , ). In het geval van PVS-Studio in Visual Studio ziet u een soortgelijke afbeelding (klikbaar):
Feit is dat statische analysatoren meestal een groot aantal waarschuwingen geven voor projecten met een grote codebasis. Het is niet nodig om ze allemaal op te lossen, omdat uw project al werkt, wat betekent dat deze problemen niet kritiek zijn. Echter, jij en corrigeer deze indien nodig. Om dit te doen, moet u de uitvoer filteren en alleen de meest betrouwbare berichten achterlaten. In de PVS-Studio plugin voor Visual Studio gebeurt dit door te filteren op foutniveaus en categorieën. Voor de meest nauwkeurige uitvoer hoeft u alleen maar te laten Hoge и Algemeen (ook klikbaar):
178 waarschuwingen zijn inderdaad veel gemakkelijker te bekijken dan enkele duizenden...
In tabbladen Medium и Laag Vaak zijn er goede waarschuwingen, maar deze categorieën omvatten diagnostiek die minder nauwkeurig zijn (betrouwbaarheid). Meer informatie over waarschuwingsniveaus en opties voor het werken onder Windows vindt u hier: **.
Het is de moeite waard om de meest interessante fouten met succes te hebben beoordeeld (en met succes te hebben gecorrigeerd). . Dit is nodig zodat nieuwe waarschuwingen niet verloren gaan tussen de oude. Bovendien is een statische analysator een assistent voor de programmeur, en geen lijst met bugs. 🙂
1. Automatisering
Nadat u kennis heeft gemaakt, is het tijd om plug-ins te configureren en in CI te integreren. Dit moet worden gedaan voordat programmeurs de statische analysator gaan gebruiken. Het is een feit dat de programmeur mogelijk vergeet analyse in te schakelen of dit helemaal niet wil doen. Om dit te doen, moet je alles nog een laatste keer controleren, zodat niet-geteste code niet in de algemene ontwikkelingstak terecht kan komen.
Wat je in deze fase leert:
- Welke automatiseringsmogelijkheden biedt de tool;
- Is de analyser compatibel met uw montagesysteem?
Omdat perfecte documentatie niet bestaat, moet je soms iets schrijven . Dit is normaal en wij helpen u graag verder. 🙂
Laten we nu verder gaan met continue integratiediensten (CI). Elke analysator kan er zonder ernstige problemen in worden geïmplementeerd. Om dit te doen, moet u een aparte fase in de pijplijn creëren, die zich meestal na de build- en unit-tests bevindt. Dit wordt gedaan met behulp van verschillende consolehulpprogramma's. PVS-Studio biedt bijvoorbeeld de volgende hulpprogramma's:
- (analyse van oplossingen, C#, C++ projecten op Windows)
- (compilatiebewaking)
- (analyse van C++-projecten op Linux / macOS)
- (oplossingsanalyse, C#-projecten op Linux / macOS)
- (analyse van Java-projecten)
- (rapportbestandsconverter)
Om analyse in CI te integreren, moet u drie dingen doen:
- Installeer de analysator;
- Analyse uitvoeren;
- Lever resultaten.
Om PVS-Studio bijvoorbeeld op Linux (Debian-basis) te installeren, moet u de volgende opdrachten uitvoeren:
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-studioOp systemen met Windows is het niet mogelijk om de analyser vanuit de pakketbeheerder te installeren, maar het is wel mogelijk om de analyser vanaf de opdrachtregel te implementeren:
PVS-Studio_setup.exe /verysilent /suppressmsgboxes
/norestart /nocloseapplicationsU kunt meer lezen over het implementeren van PVS-Studio op systemen met Windows **.
Na de installatie moet u de analyse direct uitvoeren. Het wordt echter aanbevolen om dit pas te doen nadat de compilatie en tests zijn geslaagd. Dit komt omdat statische analyse doorgaans twee keer zo lang duurt als compilatie.
Omdat de startmethode afhankelijk is van het platform en de projectfuncties, zal ik als voorbeeld de optie voor C++ (Linux) tonen:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
plog-converter -t errorfile PVS-Studio.log --cerr -wDe eerste opdracht voert de analyse uit, en de tweede converteert het rapport naar tekstformaat, geeft het weer op het scherm en retourneert een andere retourcode dan 0 als er waarschuwingen zijn. Een dergelijk mechanisme kan handig worden gebruikt om een build te blokkeren als er foutmeldingen zijn. U kunt de vlag echter altijd verwijderen -w en blokkeer geen assembly die waarschuwingen bevat.
Opmerking. Het tekstformaat is onhandig. Het wordt louter als voorbeeld gegeven. Besteed aandacht aan een interessanter rapportformaat: FullHtml. Hiermee kunt u door de code navigeren.
Meer over het opzetten van analyses op CI lees je in het artikel "" (Windows) of ""(Linux).
Oké, je hebt de analyser op de buildserver geconfigureerd. Als iemand nu niet-geteste code heeft geüpload, mislukt de verificatiefase en kunt u het probleem detecteren. Dit is echter niet helemaal handig, omdat het efficiënter is om het project niet te controleren nadat de branches zijn samengevoegd, maar ervoor, in de fase van het pull-verzoek.
Over het algemeen verschilt het opzetten van een pull request-analyse niet veel van de gebruikelijke lancering van een analyse op CI. Behalve de noodzaak om een lijst met gewijzigde bestanden te krijgen. Deze kunnen meestal worden verkregen door de verschillen tussen branches op te vragen met behulp van git:
git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.listNu moet u deze lijst met bestanden als invoer aan de analysator doorgeven. In PVS-Studio wordt dit bijvoorbeeld geïmplementeerd met behulp van de vlag -S:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
-S .pvs-pr.listU kunt meer informatie vinden over het analyseren van pull-aanvragen **. Zelfs als uw CI niet op de lijst van diensten staat die in het artikel worden genoemd, vindt u het algemene gedeelte gewijd aan de theorie van dit soort analyses nuttig.
Door analyse van pull-aanvragen in te stellen, kunt u commits met waarschuwingen blokkeren, waardoor een grens ontstaat die niet-geteste code niet kan overschrijden.
Dit is allemaal zeker goed, maar ik zou graag alle waarschuwingen op één plek willen zien. Niet alleen van de statische analyser, maar ook van unittests of van de dynamische analyser. Hiervoor zijn verschillende diensten en plug-ins beschikbaar. PVS-Studio heeft dat bijvoorbeeld .
2. Integratie op ontwikkelaarsmachines
Nu is het tijd om de analyser te installeren en configureren voor dagelijks ontwikkelingsgebruik. Op dit punt ben je al bekend met de meeste manieren van werken, dus dit kan het gemakkelijkste deel worden genoemd.
Als de eenvoudigste optie kunnen ontwikkelaars zelf de benodigde analysator installeren. Dit zal echter veel tijd kosten en hen afleiden van de ontwikkeling, dus u kunt dit proces automatiseren met behulp van een installatieprogramma en de benodigde vlaggen. Voor PVS-Studio zijn er verschillende . Er zijn echter altijd pakketbeheerders, bijvoorbeeld Chocolatey (Windows), Homebrew (macOS) of tientallen opties voor Linux.
Dan zul je de benodigde plug-ins moeten installeren voor bijvoorbeeld , , enz.
3. Dagelijks gebruik
In dit stadium is het tijd om iets te zeggen over manieren om de analysator tijdens het dagelijks gebruik te versnellen. Een volledige analyse van het hele project kost veel tijd, maar hoe vaak veranderen we de code gedurende het hele project in één keer? Er is nauwelijks sprake van een refactoring die zo groot is dat deze direct de gehele codebasis beïnvloedt. Het aantal bestanden dat tegelijkertijd wordt gewijzigd, overschrijdt zelden een dozijn, dus het is zinvol om ze te analyseren. Voor een dergelijke situatie is er . Wees niet ongerust, dit is geen ander hulpmiddel. Dit is een speciale modus waarmee u alleen gewijzigde bestanden en hun afhankelijkheden kunt analyseren, en dit gebeurt automatisch na het bouwen als u in een IDE werkt waarop de plug-in is geïnstalleerd.
Als de analyser problemen constateert in de recentelijk gewijzigde code, meldt hij dit zelfstandig. PVS-Studio informeert u hierover bijvoorbeeld via een alert:
Het is natuurlijk niet voldoende om ontwikkelaars te vertellen dat ze de tool moeten gebruiken. We moeten ze op de een of andere manier vertellen wat het is en hoe het is. Hier vindt u bijvoorbeeld artikelen over een snelle start voor PVS-Studio, maar u kunt vergelijkbare tutorials vinden voor elke gewenste tool:
Dergelijke artikelen bieden alle informatie die nodig is voor dagelijks gebruik en kosten niet veel tijd. 🙂
Zelfs toen we de tool leerden kennen, hebben we tijdens een van de eerste lanceringen veel waarschuwingen onderdrukt. Helaas zijn statische analysatoren niet perfect, dus geven ze af en toe valse positieven. Het is meestal gemakkelijk om ze te onderdrukken; in de PVS-Studio-plug-in voor Visual Studio hoeft u bijvoorbeeld maar op één knop te klikken:
U kunt echter meer doen dan ze alleen onderdrukken. U kunt bijvoorbeeld een probleem melden bij de ondersteuning. Als de valse positieven kunnen worden gecorrigeerd, kunt u bij toekomstige updates merken dat er elke keer steeds minder valse positieven zijn die specifiek zijn voor uw codebase.
Na integratie
We hebben dus alle fasen doorlopen van het integreren van statische analyse in het ontwikkelingsproces. Ondanks het belang van het opzetten van dergelijke tools op CI, is de computer van de ontwikkelaar de belangrijkste plaats om ze uit te voeren. Een statische analysator is immers geen rechter die ergens ver weg van je zegt dat de code niet goed is. Integendeel, het is een assistent die je vertelt of je moe bent en je eraan herinnert als je iets vergeten bent.
Toegegeven, zonder regelmatig gebruik is het onwaarschijnlijk dat statische analyse de ontwikkeling aanzienlijk zal vereenvoudigen. Het belangrijkste voordeel voor een ontwikkelaar ligt immers niet zozeer in het zoeken naar complexe en controversiële delen van de code, maar in het vroegtijdig ontdekken ervan. Ben het ermee eens dat het ontdekken van een probleem nadat de bewerkingen ter test zijn verzonden, niet alleen onaangenaam is, maar ook erg tijdrovend. Bij regelmatig gebruik bekijkt statische analyse elke wijziging rechtstreeks op uw computer en rapporteert verdachte plaatsen terwijl u aan de code werkt.
En als u of uw collega's er nog steeds niet zeker van zijn of het de moeite waard is om de analyser te implementeren, dan raad ik u aan nu het artikel te gaan lezen "". Het komt tegemoet aan de typische zorgen van ontwikkelaars dat statische analyse hun tijd in beslag zal nemen, enzovoort.
Als u dit artikel wilt delen met een Engelssprekend publiek, gebruik dan de vertaallink: Maxim Zvyagintsev. .
Bron: www.habr.com