Træt af uendelig kodegennemgang eller fejlfinding, tænker du nogle gange på, hvordan du kan forenkle dit liv. Og efter at have søgt lidt, eller ved et uheld stødt på det, kan du se den magiske sætning: "Statisk analyse." Lad os se, hvad det er, og hvordan det kan interagere med dit projekt.
Faktisk, hvis du skriver på et moderne sprog, så kørte du det gennem en statisk analysator uden selv at være klar over det. Faktum er, at enhver moderne compiler giver, om end et lille sæt advarsler om potentielle problemer i koden. For eksempel, når du kompilerer C++-kode i Visual Studio, kan du muligvis se følgende:
I dette output ser vi, at variablen var blev aldrig brugt nogen steder i funktionen. Så i virkeligheden brugte du næsten altid en simpel statisk kodeanalysator. Men i modsætning til professionelle analysatorer såsom Coverity, Klocwork eller PVS-Studio, kan advarslerne fra compileren muligvis kun indikere en lille række problemer.
Hvis du ikke ved med sikkerhed, hvad statisk analyse er, og hvordan du implementerer den, for at lære mere om denne metode.
Hvorfor har du brug for statisk analyse?
I en nøddeskal: acceleration og forenkling.
Statisk analyse giver dig mulighed for at finde en masse forskellige problemer i koden: fra forkert brug af sprogkonstruktioner til stavefejl. 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 kan se, er der en tastefejl i sidste linje. For eksempel udsender PVS-Studio følgende advarsel:
Overvej at gennemgå rigtigheden af 'y'-elementets brug.
Hvis du vil stikke dine hænder ind i denne fejl, så prøv et færdigt eksempel i Compiler Explorer: **.
Og som du forstår, er det ikke altid muligt at være opmærksom på sådanne sektioner af kode med det samme, og på grund af dette kan du sidde ned og fejlfinde i en god time og undre dig over, hvorfor alt fungerer så mærkeligt.
Dette er dog klart en fejl. Hvad hvis udvikleren skrev suboptimal kode, fordi han glemte en eller anden finesse af sproget? Eller endda tilladt det i koden ? Desværre er sådanne sager helt almindelige, og brorparten af tiden bruges på at fejlsøge specifikt fungerende kode, der indeholder tastefejl, typiske fejl eller udefineret adfærd.
Det er for disse situationer, at statisk analyse dukkede op. Dette er en assistent for udvikleren, som vil påpege forskellige problemer i koden og forklare i dokumentationen, hvorfor det ikke er nødvendigt at skrive på denne måde, hvad det kan føre til, og hvordan det løses. Her er et eksempel på, hvordan det kan se ud: **.
Du kan finde flere interessante fejl, som analysatoren kan opdage i artiklerne:
Nu hvor du har læst dette materiale og er overbevist om fordelene ved statisk analyse, vil du måske prøve det. Men hvor skal man begynde? Hvordan integrerer man et nyt værktøj i dit nuværende projekt? Og hvordan præsenterer man holdet for ham? Du finder svar på disse spørgsmål nedenfor.
Bemærk. Statisk analyse erstatter eller annullerer ikke noget så nyttigt som kodegennemgange. Det supplerer denne proces og hjælper med at bemærke og rette slåfejl, unøjagtigheder og farlige designs på forhånd. Det er meget mere produktivt at fokusere på kodegennemgange på algoritmer og kodeklarhed i stedet for at lede efter en malplaceret parentes eller .
0. Lær værktøjet at kende
Det hele starter med en prøveversion. Det er faktisk svært at beslutte sig for at implementere noget i udviklingsprocessen, hvis du aldrig har set værktøjet live før. Derfor er det første du skal gøre at downloade .
Hvad vil du lære på dette stadium:
- Hvad er måderne at interagere med analysatoren på;
- Er analysatoren kompatibel med dit udviklingsmiljø?
- Hvilke problemer er der i øjeblikket i dine projekter?
Når du har installeret alt, hvad du skal bruge, er den første ting, du skal gøre, at køre en analyse af hele projektet (, , ). I tilfælde af PVS-Studio i Visual Studio vil du se et lignende billede (klikbart):
Faktum er, at statiske analysatorer normalt udsender et stort antal advarsler til projekter med en stor kodebase. Der er ingen grund til at rette dem alle, da dit projekt allerede fungerer, hvilket betyder, at disse problemer ikke er kritiske. Dog du og ret dem om nødvendigt. For at gøre dette skal du filtrere outputtet og kun efterlade de mest pålidelige beskeder. I PVS-Studio plugin til Visual Studio gøres dette ved at filtrere efter fejlniveauer og kategorier. For det mest nøjagtige output, lad kun være Høj и Generelt (også klikbar):
Faktisk er 178 advarsler meget nemmere at se end flere tusinde...
I faner Medium и Lav Ofte er der gode advarsler, men disse kategorier inkluderer de diagnostik, der har mindre nøjagtighed (pålidelighed). Mere information om advarselsniveauer og muligheder for at arbejde under Windows kan findes her: **.
Det er værd at have gennemgået de mest interessante fejl (og rettet dem med succes). . Dette er nødvendigt, for at nye advarsler ikke forsvinder blandt de gamle. Derudover er en statisk analysator en assistent for programmøren og ikke en liste over fejl. 🙂
1. Automatisering
Efter at have stiftet bekendtskab, er det tid til at konfigurere plugins og integrere i CI. Dette skal gøres, før programmører begynder at bruge den statiske analysator. Faktum er, at programmøren kan glemme at aktivere analyse eller slet ikke ønsker at gøre det. For at gøre dette skal du foretage en sidste kontrol af alt, så utestet kode ikke kan komme ind i den generelle udviklingsgren.
Hvad vil du lære på dette stadium:
- Hvilke automatiseringsmuligheder giver værktøjet;
- Er analysatoren kompatibel med dit montagesystem?
Da perfekt dokumentation ikke eksisterer, er man nogle gange nødt til at skrive ind . Dette er normalt, og vi hjælper dig gerne. 🙂
Lad os nu gå videre til kontinuerlig integration (CI)-tjenester. Enhver analysator kan implementeres i dem uden alvorlige problemer. For at gøre dette skal du oprette et separat trin i rørledningen, som normalt er placeret efter bygge- og enhedstesten. Dette gøres ved hjælp af forskellige konsolværktøjer. For eksempel leverer PVS-Studio følgende hjælpeprogrammer:
- (analyse af løsninger, C#, C++ projekter på Windows)
- (kompileringsovervågning)
- (analyse af C++ projekter på Linux/macOS)
- (løsningsanalyse, C#-projekter på Linux / macOS)
- (analyse af Java-projekter)
- (rapport fil konverter)
For at integrere analyse i CI skal du gøre tre ting:
- Installer analysatoren;
- Kør analyse;
- Lever resultater.
For eksempel, for at installere PVS-Studio på Linux (Debian-base), skal du kø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-studioPå systemer, der kører Windows, er der ingen måde at installere analysatoren fra pakkehåndteringen, men det er muligt at implementere analysatoren fra kommandolinjen:
PVS-Studio_setup.exe /verysilent /suppressmsgboxes
/norestart /nocloseapplicationsDu kan læse mere om implementering af PVS-Studio på systemer, der kører Windows **.
Efter installationen skal du køre analysen direkte. Det anbefales dog kun at gøre dette efter kompilering og test er bestået. Dette skyldes, at statisk analyse typisk tager dobbelt så lang tid som kompilering.
Da lanceringsmetoden afhænger af platformen og projektfunktionerne, vil jeg vise muligheden for C++ (Linux) som et eksempel:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
plog-converter -t errorfile PVS-Studio.log --cerr -wDen første kommando udfører analysen, og den anden konverterer rapporten til tekstformat, viser den på skærmen og returnerer en anden returkode end 0, hvis der er advarsler. En mekanisme som denne kan bekvemt bruges til at blokere en build, når der er fejlmeddelelser. Du kan dog altid fjerne flaget -w og bloker ikke en enhed, der indeholder advarsler.
Bemærk. Tekstformatet er ubelejligt. Det er blot givet som et eksempel. Vær opmærksom på et mere interessant rapportformat - FullHtml. Det giver dig mulighed for at navigere gennem koden.
Du kan læse mere om opsætning af analyse på CI i artiklen "" (Windows) eller "" (Linux).
Okay, du har konfigureret analysatoren på build-serveren. Nu, hvis nogen uploadede utestet kode, vil verifikationsstadiet mislykkes, og du vil være i stand til at opdage problemet, men dette er ikke helt bekvemt, da det er mere effektivt at kontrollere projektet ikke efter at grenene er blevet flettet, men før det, på pull request-stadiet. A.
Generelt er opsætning af en pull-anmodningsanalyse ikke meget forskellig fra den sædvanlige lancering af en analyse på CI. Bortset fra behovet for at få en liste over ændrede filer. Disse kan normalt opnås ved at forespørge på forskellene mellem grene ved hjælp af git:
git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.listNu skal du sende denne liste over filer til analysatoren som input. For eksempel implementeres dette i PVS-Studio ved hjælp af flaget -S:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
-S .pvs-pr.listDu kan finde ud af mere om at analysere pull-anmodninger **. Selvom din CI ikke er på listen over tjenester, der er nævnt i artiklen, vil du finde den generelle sektion afsat til teorien om denne type analyse nyttig.
Ved at opsætte analyse af pull-anmodninger kan du blokere commits, der indeholder advarsler, og derved skabe en grænse, som ikke-testet kode ikke kan krydse.
Det her er helt sikkert godt, men jeg vil gerne kunne se alle advarslerne på ét sted. Ikke kun fra den statiske analysator, men også fra enhedstests eller fra den dynamiske analysator. Der er forskellige tjenester og plugins til dette. PVS-Studio har f.eks .
2. Integration på udviklermaskiner
Nu er det tid til at installere og konfigurere analysatoren til daglig udviklingsbrug. På dette tidspunkt er du allerede blevet fortrolig med de fleste måder at arbejde på, så dette kan kaldes den nemmeste del.
Som den enkleste mulighed kan udviklere selv installere den nødvendige analysator. Dette vil dog tage meget tid og distrahere dem fra udviklingen, så du kan automatisere denne proces ved hjælp af et installationsprogram og de nødvendige flag. Til PVS-Studio er der forskellige . Der er dog altid pakkeadministratorer, for eksempel Chocolatey (Windows), Homebrew (macOS) eller snesevis af muligheder for Linux.
Så skal du installere de nødvendige plugins, f.eks , , etc.
3. Daglig brug
På dette tidspunkt er det tid til at sige et par ord om måder at fremskynde analysatoren under daglig brug. En komplet analyse af hele projektet tager meget tid, men hvor ofte ændrer vi kode gennem hele projektet på én gang? Der er næppe nogen refactoring, der er så stor, at den umiddelbart vil påvirke hele kodebasen. Antallet af filer, der ændres ad gangen, overstiger sjældent et dusin, så det giver mening at analysere dem. For sådan en situation er der . Bare vær ikke forskrækket, dette er ikke et andet værktøj. Dette er en speciel tilstand, der giver dig mulighed for kun at analysere ændrede filer og deres afhængigheder, og dette sker automatisk efter opbygning, hvis du arbejder i en IDE med plugin installeret.
Hvis analysatoren opdager problemer i den nyligt ændrede kode, vil den rapportere dette uafhængigt. For eksempel vil PVS-Studio fortælle dig om dette ved hjælp af en advarsel:
Det er selvfølgelig ikke nok at fortælle udviklerne om at bruge værktøjet. Vi skal på en eller anden måde fortælle dem, hvad det er, og hvordan det er. Her er for eksempel artikler om en hurtig start til PVS-Studio, men du kan finde lignende tutorials til ethvert værktøj, du foretrækker:
Sådanne artikler giver alle de nødvendige oplysninger til daglig brug og tager ikke meget tid. 🙂
Selv på tidspunktet for at lære værktøjet at kende, undertrykte vi en masse advarsler under en af de første lanceringer. Desværre er statiske analysatorer ikke perfekte, så fra tid til anden giver de falske positiver. Det er normalt nemt at undertrykke dem; for eksempel i PVS-Studio plugin til Visual Studio skal du blot klikke på en knap:
Du kan dog gøre mere end blot at undertrykke dem. For eksempel kan du rapportere et problem til support. Hvis den falske positive kan rettes, så kan du i fremtidige opdateringer bemærke, at der hver gang er færre og færre falske positive, der er specifikke for din kodebase.
Efter integration
Så vi har gennemgået alle stadier af integration af statisk analyse i udviklingsprocessen. På trods af vigtigheden af at opsætte sådanne værktøjer på CI, er det vigtigste sted at køre dem udviklerens computer. En statisk analysator er jo ikke en dommer, der siger et sted langt væk fra dig, at koden ikke er god. Det er tværtimod en assistent, der fortæller dig, hvis du er træt, og minder dig om, hvis du har glemt noget.
Sandt nok, uden regelmæssig brug, vil statisk analyse næppe forenkle udviklingen markant. Dens største fordel for en udvikler ligger trods alt ikke så meget i at søge efter komplekse og kontroversielle dele af kode, men i deres tidlige opdagelse. Enig i, at det ikke kun er ubehageligt, men også meget tidskrævende at opdage et problem, efter at redigeringerne er sendt til test. Statisk analyse, når den bruges regelmæssigt, ser på hver ændring direkte på din computer og rapporterer mistænkelige steder, mens du arbejder med koden.
Og hvis du eller dine kolleger stadig ikke er sikre på, om det er værd at implementere analysatoren, så foreslår jeg, at du nu begynder at læse artiklen "". Det adresserer udviklere typiske bekymringer om, at statisk analyse vil tage deres tid og så videre.
Hvis du vil dele denne artikel med et engelsktalende publikum, så brug venligst oversættelseslinket: Maxim Zvyagintsev. .
Kilde: www.habr.com