🥇Statisk analyse - fra introduksjon til integrering

Lei av endeløs kodegjennomgang eller feilsøking, noen ganger tenker du på hvordan du kan forenkle livet ditt. Og etter å ha søkt litt, eller ved et uhell snublet over det, kan du se den magiske setningen: "Statisk analyse". La oss se hva det er og hvordan det kan samhandle med prosjektet ditt.

Faktisk, hvis du skriver på et moderne språk, så kjørte du det gjennom en statisk analysator uten å være klar over det. Faktum er at enhver moderne kompilator gir, om enn et lite sett, advarsler om potensielle problemer i koden. For eksempel, når du kompilerer C++-kode i Visual Studio, kan du se følgende:

I denne utgangen ser vi at variabelen var ble aldri brukt noe sted i funksjonen. Så i virkeligheten brukte du nesten alltid en enkel statisk kodeanalysator. I motsetning til profesjonelle analysatorer som Coverity, Klocwork eller PVS-Studio, kan imidlertid advarslene fra kompilatoren bare indikere et lite utvalg problemer.

Hvis du ikke er sikker på hva statisk analyse er og hvordan du implementerer den, les denne artikkelenfor å lære mer om denne metoden.

Hvorfor trenger du statisk analyse?

I et nøtteskall: akselerasjon og forenkling.

Statisk analyse lar deg finne mange forskjellige problemer i koden: fra feil bruk av språkkonstruksjoner til skrivefeil. For eksempel i stedet for

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

Du skrev følgende kode:

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

Som du ser er det en skrivefeil i siste linje. For eksempel utsteder PVS-Studio følgende advarsel:

V537 Vurder å vurdere riktigheten til bruken av "y"-elementet.

Hvis du vil stikke hendene inn i denne feilen, prøv et ferdig eksempel i Compiler Explorer: *klikk*.

Og som du forstår, er det ikke alltid mulig å ta hensyn til slike deler av koden med en gang, og på grunn av dette kan du sette deg ned og feilsøke i en god time og lure på hvorfor alt fungerer så rart.

Dette er imidlertid helt klart en feil. Hva om utvikleren skrev suboptimal kode fordi han glemte en viss subtilitet i språket? Eller til og med tillatt det i koden udefinert oppførsel? Dessverre er slike tilfeller helt vanlige og brorparten av tiden går med til å feilsøke spesifikk fungerende kode som inneholder skrivefeil, typiske feil eller udefinert oppførsel.

Det er for disse situasjonene at statisk analyse dukket opp. Dette er en assistent for utvikleren som vil peke på ulike problemer i koden og forklare i dokumentasjonen hvorfor det ikke er nødvendig å skrive på denne måten, hva det kan føre til og hvordan man fikser det. Her er et eksempel på hvordan det kan se ut: *klikk*.

Du kan finne flere interessante feil som analysatoren kan oppdage i artiklene:

Nå som du har lest dette materialet og er overbevist om fordelene med statisk analyse, kan det være lurt å prøve det ut. Men hvor skal man begynne? Hvordan integrere et nytt verktøy i ditt nåværende prosjekt? Og hvordan introdusere teamet for ham? Du finner svar på disse spørsmålene nedenfor.

Note. Statisk analyse erstatter eller avbryter ikke noe så nyttig som kodegjennomganger. Den utfyller denne prosessen, og hjelper til med å legge merke til og korrigere skrivefeil, unøyaktigheter og farlige design på forhånd. Det er mye mer produktivt å fokusere på kodegjennomganger på algoritmer og kodeklarhet, i stedet for å lete etter en feilplassert parentes eller les kjedelige sammenligningsfunksjoner.

0. Bli kjent med verktøyet

Det hele starter med en prøveversjon. Det er faktisk vanskelig å bestemme seg for å implementere noe i utviklingsprosessen hvis du aldri har sett verktøyet live før. Derfor er det første du bør gjøre å laste ned prøveversjon.

Hva du vil lære på dette stadiet:

Hva er måtene å samhandle med analysatoren på;
Er analysatoren kompatibel med utviklingsmiljøet ditt?
Hvilke problemer er det for øyeblikket i prosjektene dine?

Etter at du har installert alt du trenger, er det første du bør gjøre å kjøre en analyse av hele prosjektet (Windows, Linux, macOS). Når det gjelder PVS-Studio i Visual Studio vil du se et lignende bilde (klikkbart):

Faktum er at statiske analysatorer vanligvis utsteder et stort antall advarsler for prosjekter med en stor kodebase. Det er ikke nødvendig å fikse dem alle, siden prosjektet ditt allerede fungerer, noe som betyr at disse problemene ikke er kritiske. Men du du kan se på de mest interessante advarslene og korriger dem om nødvendig. For å gjøre dette må du filtrere utdataene og bare legge igjen de mest pålitelige meldingene. I PVS-Studio plugin for Visual Studio gjøres dette ved å filtrere etter feilnivåer og kategorier. For den mest nøyaktige utgangen, la bare stå Høy и general (også klikkbar):

Faktisk er 178 advarsler mye lettere å se enn flere tusen...

I faner Medium и Lav Ofte er det gode advarsler, men disse kategoriene inkluderer de diagnostikkene som har mindre nøyaktighet (pålitelighet). Mer informasjon om advarselsnivåer og alternativer for arbeid under Windows finner du her: *klikk*.

Å ha gjennomgått de mest interessante feilene (og korrigert dem) er verdt undertrykke gjenværende advarsler. Dette er nødvendig for at nye advarsler ikke skal forsvinne blant de gamle. I tillegg er en statisk analysator en assistent for programmereren, og ikke en liste over feil. 🙂

1. Automatisering

Etter å ha blitt kjent, er det på tide å konfigurere plugins og integrere i CI. Dette må gjøres før programmerere begynner å bruke den statiske analysatoren. Faktum er at programmereren kan glemme å aktivere analyse eller ikke vil gjøre det i det hele tatt. For å gjøre dette, må du gjøre litt siste kontroll av alt slik at uprøvd kode ikke kan komme inn i den generelle utviklingsgrenen.

Hva du vil lære på dette stadiet:

Hvilke automatiseringsmuligheter gir verktøyet;
Er analysatoren kompatibel med monteringssystemet ditt?

Siden perfekt dokumentasjon ikke finnes, må du noen ganger skrive inn Brukerstøtte. Dette er normalt og vi hjelper deg gjerne. 🙂

La oss nå gå videre til tjenester for kontinuerlig integrasjon (CI). Enhver analysator kan implementeres i dem uten alvorlige problemer. For å gjøre dette må du opprette et eget trinn i rørledningen, som vanligvis er plassert etter bygge- og enhetstestene. Dette gjøres ved hjelp av ulike konsollverktøy. For eksempel tilbyr PVS-Studio følgende verktøy:

PVS-Studio_Cmd.exe (analyse av løsninger, C#, C++ prosjekter på Windows)
CLMonitor.exe (sammenstillingsovervåking)
pvs-studio-analyzer (analyse av C++-prosjekter på Linux / macOS)
pvs-studio-dotnet (løsningsanalyse, C#-prosjekter på Linux / macOS)
pvs-studio.jar (analyse av Java-prosjekter)
PlogConverter (rapportfilkonvertering)

For å integrere analyse i CI, må du gjøre tre ting:

Installer analysatoren;
Kjør analyse;
Lever resultater.

For eksempel, for å installere PVS-Studio på Linux (Debian-base), må du kjøre følgende kommandoer:

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

På systemer som kjører Windows, er det ingen måte å installere analysatoren fra pakkebehandlingen, men det er mulig å distribuere analysatoren fra kommandolinjen:

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

Du kan lese mer om distribusjon av PVS-Studio på systemer som kjører Windows *her*.

Etter installasjonen må du kjøre analysen direkte. Det anbefales imidlertid å gjøre dette først etter at kompilering og tester er bestått. Dette er fordi statisk analyse vanligvis tar dobbelt så lang tid som kompilering.

Siden lanseringsmetoden avhenger av plattformen og prosjektfunksjonene, vil jeg vise alternativet for C++ (Linux) som et eksempel:

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

Den første kommandoen vil utføre analysen, og den andre konvolutterkonverterer rapporten til tekstformat, viser den på skjermen og returnerer en annen returkode enn 0 hvis det er advarsler. En mekanisme som denne kan enkelt brukes til å blokkere en build når det er feilmeldinger. Du kan imidlertid alltid fjerne flagget -w og ikke blokker en enhet som inneholder advarsler.

Note. Tekstformatet er upraktisk. Det er bare gitt som et eksempel. Vær oppmerksom på et mer interessant rapportformat - FullHtml. Den lar deg navigere gjennom koden.

Du kan lese mer om å sette opp analyse på CI i artikkelen "PVS-Studio og kontinuerlig integrasjon" (Windows) eller "Hvordan sette opp PVS-Studio i Travis CI" (Linux).

Ok, du har konfigurert analysatoren på byggeserveren. Nå, hvis noen lastet opp utestet kode, vil bekreftelsesstadiet mislykkes, og du vil kunne oppdage problemet, men dette er ikke helt praktisk, siden det er mer effektivt å sjekke prosjektet ikke etter at grenene er slått sammen, men før det, på pull request-stadiet. A.

Generelt sett er det ikke mye forskjellig å sette opp en pull request-analyse fra den vanlige lanseringen av en analyse på CI. Bortsett fra behovet for å få en liste over endrede filer. Disse kan vanligvis oppnås ved å spørre etter forskjellene mellom grener ved å bruke git:

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

Nå må du sende denne listen over filer til analysatoren som input. For eksempel, i PVS-Studio er dette implementert ved hjelp av flagget -S:

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

Du kan finne ut mer om å analysere pull-forespørsler *her*. Selv om din CI ikke er på listen over tjenester nevnt i artikkelen, vil du finne den generelle delen viet til teorien om denne typen analyse nyttig.

Ved å sette opp analyse av pull-forespørsler kan du blokkere commits som inneholder advarsler, og dermed skape en grense som ikke-testet kode ikke kan krysse.

Dette er absolutt bra, men jeg vil gjerne kunne se alle advarslene på ett sted. Ikke bare fra den statiske analysatoren, men også fra enhetstester eller fra den dynamiske analysatoren. Det finnes ulike tjenester og plugins for dette. PVS-Studio har for eksempel plugin for integrering i SonarQube.

2. Integrasjon på utviklermaskiner

Nå er det på tide å installere og konfigurere analysatoren for daglig bruk. På dette tidspunktet har du allerede blitt kjent med de fleste måtene å jobbe på, så dette kan kalles den enkleste delen.

Som det enkleste alternativet kan utviklere installere den nødvendige analysatoren selv. Dette vil imidlertid ta mye tid og distrahere dem fra utviklingen, slik at du kan automatisere denne prosessen ved å bruke et installasjonsprogram og de nødvendige flaggene. For PVS-Studio er det ulike flagg for automatisert installasjon. Imidlertid er det alltid pakkebehandlere, for eksempel Chocolatey (Windows), Homebrew (macOS) eller dusinvis av alternativer for Linux.

Da må du installere nødvendige plugins, for eksempel for Visual Studio, IDÉ, Rider og så videre

3. Daglig bruk

På dette stadiet er det på tide å si noen ord om måter å øke hastigheten på analysatoren under daglig bruk. En fullstendig analyse av hele prosjektet tar mye tid, men hvor ofte endrer vi kode gjennom hele prosjektet på en gang? Det er knapt noen refaktorering som er så stor at den umiddelbart vil påvirke hele kodebasen. Antall filer som endres om gangen overstiger sjelden et dusin, så det er fornuftig å analysere dem. For en slik situasjon er det inkrementell analysemodus. Bare ikke vær redd, dette er ikke et annet verktøy. Dette er en spesiell modus som lar deg analysere kun endrede filer og deres avhengigheter, og dette skjer automatisk etter bygging hvis du jobber i en IDE med plugin installert.

Hvis analysatoren oppdager problemer i den nylig endrede koden, vil den rapportere dette uavhengig. For eksempel vil PVS-Studio fortelle deg om dette ved å bruke et varsel:

Det er selvfølgelig ikke nok å fortelle utviklere om å bruke verktøyet. Vi må på en eller annen måte fortelle dem hva det er og hvordan det er. Her er for eksempel artikler om en rask start for PVS-Studio, men du kan finne lignende opplæringsprogrammer for alle verktøy du foretrekker:

Slike artikler gir all nødvendig informasjon for daglig bruk og tar ikke mye tid. 🙂

Selv på stadiet da vi ble kjent med verktøyet, undertrykte vi mange advarsler under en av de første lanseringene. Dessverre er statiske analysatorer ikke perfekte, så fra tid til annen gir de falske positiver. Det er vanligvis lett å undertrykke dem; for eksempel i PVS-Studio-plugin for Visual Studio trenger du bare å klikke på én knapp:

Du kan imidlertid gjøre mer enn å bare undertrykke dem. Du kan for eksempel rapportere et problem til support. Hvis den falske positive kan korrigeres, kan du i fremtidige oppdateringer legge merke til at hver gang det er færre og færre falske positive spesifikke for kodebasen din.

Etter integrering

Så vi har gått gjennom alle stadier med å integrere statisk analyse i utviklingsprosessen. Til tross for viktigheten av å sette opp slike verktøy på CI, er det viktigste stedet å kjøre dem på utviklerens datamaskin. Tross alt er en statisk analysator ikke en dommer som sier et sted langt unna deg at koden ikke er bra. Tvert imot er det en assistent som forteller deg om du er sliten og minner deg på om du har glemt noe.

Det er sant, uten regelmessig bruk, vil statisk analyse neppe forenkle utviklingen betydelig. Tross alt ligger hovedfordelen for en utvikler ikke så mye i å søke etter komplekse og kontroversielle deler av kode, men i tidlig oppdagelse. Enig i at det å oppdage et problem etter at redigeringene er sendt til testing ikke bare er ubehagelig, men også veldig tidkrevende. Statisk analyse, når den brukes regelmessig, ser på hver endring direkte på datamaskinen din og rapporterer mistenkelige steder mens du arbeider med koden.

Og hvis du eller kollegene dine fortsatt ikke er sikre på om det er verdt å implementere analysatoren, foreslår jeg at du nå begynner å lese artikkelen "Grunner til å introdusere den statiske kodeanalysatoren PVS-Studio i utviklingsprosessen". Den adresserer typiske bekymringer for utviklere om at statisk analyse vil ta tid og så videre.

Hvis du vil dele denne artikkelen med et engelsktalende publikum, vennligst bruk oversettelseslenken: Maxim Zvyagintsev. Statisk analyse: Fra å komme i gang til integrering.

Kilde: www.habr.com

Statisk analyse - fra introduksjon til integrasjon