Når du er træt af den endeløse code review eller debugging, kan du nogle gange overveje, hvordan du kan gøre dit liv lettere. Og efter lidt søgen, eller ved et tilfælde, kan du støde på det magiske udtryk: "Statisk analyse". Lad os se nærmere på, hvad det er, og hvordan det kan interagere med dit projekt.
Faktisk, hvis du skriver i et moderne programmeringssprog, så har du, uden at vide det, brugt en statisk analyserer. Det skyldes, at enhver moderne compiler tilbyder et lille, men væsentligt set af advarsler om potentielle problemer i koden. For eksempel, når du kompilerer C++ kode i Visual Studio, kan du se følgende:
I denne output ser vi, at variablen var ikke blev brugt nogen steder i funktionen. Så du har faktisk næsten altid benyttet en simpel statisk kodeanalysator. Men i modsætning til professionelle analyser som Coverity, Klocwork eller PVS-Studio, kan de advarsler, som compilers tilbyder, kun pege på en begrænset række af problemer.
Hvis du ikke er helt sikker på, hvad statisk analyse er, og hvordan man implementerer det, , for at lære mere om denne metodologi.
Hvorfor er statisk analyse nødvendig?
Kort sagt: acceleration og forenkling.
Statisk analyse gør det muligt at finde mange forskellige problemer i koden: fra forkert brug af sprogkonstruktioner til tastefejl. For eksempel, i stedet for
auto x = obj.x;
auto y = obj.y;
auto z = obj.z;skrev du følgende kode:
auto x = obj.x;
auto y = obj.y;
auto z = obj.x;Som du kan se, er der en tastefejl i den sidste linje. For eksempel giver PVS-Studio følgende advarsel:
Overvej at gennemgå korrektheden af 'y' elementets brug.
Hvis du ønsker at teste denne fejl manuelt, så prøv det færdige eksempel på Compiler Explorer: **.
Og som du forstår, er det ikke altid muligt at lægge mærke til sådanne kodeområder med det samme, og derfor kan man ende med at sidde fast i debugging i lang tid, undrende over, hvorfor alt fungerer så mærkeligt.
Men det er en åbenlys fejl. Hvad hvis udvikleren skrev suboptimal kode, fordi han glemte en nuance i sproget? Eller forårsagede en ? К сожалению, подобные случаи совершенно обыденны и львиная часть времени тратится на то, чтобы отладить специфично работающий код, который содержит опечатки, типичные ошибки или undefined behavior.
Det er netop i disse situationer, at statisk analyse blev introduceret. Det er en hjælper for udvikleren, som vil påpege forskellige problemer i koden og forklare i dokumentationen, hvorfor det ikke er nødvendigt at skrive sådan, hvilke konsekvenser det kan have, og hvordan man kan rette det. Her er et eksempel på, hvordan det kan se ud: **.
Flere interessante fejl, som analysatoren kan opdage, kan du finde i artiklerne:
Nu, efter at have læst dette materiale og bekræftet fordelene ved statisk analyse, kan du have lyst til at prøve det i praksis. Men hvordan kommer man i gang? Hvordan integrerer man et nyt værktøj i det nuværende projekt? Og hvordan introducerer man teamet for det? Du vil finde svarene på disse spørgsmål nedenfor.
Bemærkning. Statisk analyse erstatter ikke og annullerer ikke noget så nyttigt som kodegennemgange. Den supplerer denne proces ved at hjælpe med at opdage og rette stavefejl, unøjagtigheder og farlige konstruktioner på forhånd. Det er langt mere produktivt at fokusere på algoritmer og kodeforståelse under kodegennemgange, frem for at lede efter forkert placerede parenteser eller .
0. Introduktion til værktøjet
Det hele starter med en prøveversion. Det er i sandhed svært at tage skridtet til at implementere noget i udviklingsprocessen, hvis man aldrig har set værktøjet i aktion før. Så det første skridt er at downloade .
Hvad du vil lære på dette trin:
- Hvilke måder der er til interaktion med analysatoren;
- Om analysatoren er kompatibel med dit udviklingsmiljø;
- Hvilke problemer der i øjeblikket er i dine projekter.
Når du har installeret alt det nødvendige, så er det første skridt at køre analysen af hele projektet (, , ). I tilfælde af PVS-Studio i Visual Studio vil du se et lignende billede (klikbart):
Problemet er, at statiske analysatorer normalt viser et enormt antal advarsler for projekter med store kodebaser. Det er ikke nødvendigt at rette dem alle, da dit projekt allerede fungerer, og derfor er disse problemer ikke kritiske. Men du og filtrere output og efterlade kun de mest pålidelige meddelelser. I PVS-Studio-plugin'et til Visual Studio gøres dette ved at filtrere efter niveauer og fejltyper. For det mest præcise output skal du kun holde følgende aktiveret Høj og Generelt (også klikbart):
Virkelig, det er meget lettere at gennemgå 178 advarsler end flere tusinde...
Under fanerne Medium og Lav findes der ofte gode advarsler, men i disse kategorier er der also diagnosticeringer, som har lavere nøjagtighed (pålidelighed). Du kan læse mere om advarselsniveauer og arbejdsmetoder under Windows her: **.
Når du har gennemgået de mest interessante fejl (og succesfuldt rettet dem), er det tid til . Dette er nødvendigt, så nye advarsler ikke går tabt blandt de gamle. Desuden er en statisk analyser bare en hjælp til programmøren, ikke en liste over fejl. 🙂
1. Automatisering
Efter introduktionen er det tid til at konfigurere plugins og integrere i CI. Dette skal gøres, inden programmørerne begynder at bruge den statiske analyser. Problemet er, at programmøren kan glemme at aktivere analysen eller simpelthen ikke ønsker det. Derfor er det nødvendigt at gennemføre en sidste kontrol af alt, så ikke-godkendt kode ikke kan komme ind i den fælles udviklingsgren.
Hvad du vil lære på dette trin:
- Hvilke automatiseringsmuligheder værktøjet tilbyder;
- Om analysatoren er kompatibel med dit buildsystem.
Da der ikke findes nogen perfekt dokumentation, må vi nogle gange skrive til . Det er helt normalt, og vi er glade for at hjælpe. 🙂
Og nu lad os se på tjenester til kontinuerlig integration (CI). Enhver analyser kan implementeres i dem uden alvorlige problemer. Dette kræver, at der oprettes et separat trin i pipeline, som normalt er efter build og unit-tests. Dette gøres ved hjælp af forskellige konsolværktøjer. For eksempel tilbyder PVS-Studio følgende værktøjer:
- (analyse af løsninger, C#, C++ projekter på Windows)
- (kompileringsmonitor)
- (analyse af C++ projekter på Linux / macOS)
- (analyse af løsninger, C# projekter på Linux / macOS)
- (analyse af Java projekter)
- (filkonverteringsværktøj til rapporter)
For at integrere analysen i CI skal tre ting gøres:
- Installere analyseren;
- Køre analysen;
- Lever resultatet.
For eksempel, for at installere PVS-Studio på Linux (Debian-baseret) 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-studioI Windows-systemer er der ikke mulighed for at installere analysatoren fra pakkestyringssystemet, men der er mulighed for at implementere analysatoren fra kommandolinjen:
PVS-Studio_setup.exe /verysilent /suppressmsgboxes
/norestart /nocloseapplicationsDu kan læse mere om implementering af PVS-Studio i Windows-systemer **.
Efter installationen skal du starte selve analysen. Det anbefales dog at gøre det først, efter at kompileringen og testene er gennemført. Dette skyldes, at statisk analyse typisk kræver dobbelt så lang tid som kompilering.
Da måden at starte afhænger af platformen og projektets egenskaber, vil jeg vise et eksempel for C++ (Linux):
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
plog-converter -t errorfile PVS-Studio.log --cerr -wDen første kommando udfører analysen, mens den anden rapporten til tekstformat, viser den på skærmen og returnerer en kode forskellig fra 0 i tilfælde af advarsler. Denne mekanisme er praktisk at bruge til at blokere byggeriet, når der er fejlmeddelelser. Du kan dog altid fjerne flaget -w og ikke blokere byggeriet, der indeholder advarsler.
Bemærkning. Tekstformatet er ikke bekvemt. Det gives blot som et eksempel. Vær opmærksom på det mere interessante rapportformat - FullHtml. Det giver mulighed for at navigere i koden.
Du kan læse mere om indstilling af analysen på CI i artiklen "" (Windows) eller "" (Linux).
Godt, du har indstillet analysatorens arbejde på build-serveren. Nu, hvis nogen uploader ukontrolleret kode, vil den tjekke etape fejle, og du kan opdage problemet. Det er dog ikke helt praktisk, da det er mere effektivt at kontrollere projektet før sammenlægningen af grene, snarere end efter, på pull request-trinene.
Generelt adskiller indstillingen af en pull request-analyse sig ikke meget fra en almindelig analyse på CI. Bortset fra nødvendigheden af at få listen over ændrede filer. Normalt kan de fås ved at anmode om forskellen mellem grenene ved hjælp af git:
git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.listNu skal vi give denne fil liste til analysatoren. For eksempel er dette implementeret i PVS-Studio ved hjælp af flaget -S:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
-S .pvs-pr.listDu kan finde mere information om analysen af pull requests **. Selvom din CI ikke er på listen over nævnte tjenester i artiklen, vil du finde den generelle sektion om teorien bag denne type analyse nyttig.
Ved at konfigurere analysen af pull requests kan du blokere commits, der indeholder advarsler, og dermed skabe en grænse, som uchecket kode ikke kan krydse.
Dette er alt sammen godt, men man ville gerne have muligheden for at se alle advarsler ét sted. Ikke kun fra statiske analysetools, men også fra unit tests eller dynamiske analyseværktøjer. Til dette findes der forskellige tjenester og plugins. PVS-Studio har for eksempel en .
2. Integration på udvikler-maskiner
Nu er det tid til at installere og konfigurere analysatoren til hverdagsbrug under udviklingen. På dette tidspunkt har du allerede lært det meste af arbejdsmetoderne, så dette kan kaldes den nemmeste del.
Som den nemmeste mulighed kan udviklerne selv installere den nødvendige analyser. Men det vil tage meget tid og aflede dem fra udviklingen, så du kan automatisere denne proces ved hjælp af en installer og de nødvendige flags. For PVS-Studio er der forskellige . I øvrigt er der altid pakkemanagere, som for eksempel Chocolatey (Windows), Homebrew (macOS) eller dusinvis af muligheder for Linux.
Først skal du installere de nødvendige plugins, for eksempel til , , etc.
3. Dagligt brug
På dette stadium er det tid til at sige et par ord om måder at fremskynde analyserens arbejdsproces på i daglig brug. En fuld analyse af hele projektet tager meget lang tid, men hvor ofte ændrer vi koden i hele projektet på én gang? Der findes næppe et så stort refaktor, der straks påvirker hele kodebasen. Antallet af filer, der ændres ad gangen, overstiger sjældent et dusin, så det giver mening at analysere dem. Der findes en . Bare ikke vær bange, det er ikke et endnu et værktøj. Det er en specialtilstand, der tillader at analysere kun de ændrede filer og deres afhængigheder, og dette sker automatisk efter bygning, hvis du arbejder i en IDE med den installerede plugin.
I tilfælde af, at analysatoren opdager problemer i den nyligt ændrede kode, vil den informere dig selv. For eksempel vil PVS-Studio fortælle dig dette via en notifikation:
Det er ikke nok bare at sige til udviklerne at bruge værktøjet. Man skal på en eller anden måde fortælle dem, hvad det er, og hvordan det fungerer. Her er for eksempel artikler om hurtig start for PVS-Studio, men du kan finde sådanne tutorials for ethvert af de værktøjer, du foretrækker:
Sådanne artikler giver al den nødvendige information til daglig brug og tager ikke meget tid. 🙂
Allerede i begyndelsen af bekendtskabet med værktøjet har vi undertrykt mange advarsler under en af de første opstarter. Desværre er statiske analysatorer ikke perfekte, så de giver nogle gange falske positiver. At undertrykke dem er normalt let, for eksempel i PVS-Studio plugin til Visual Studio behøver du bare at trykke på en knap:
Men du kan ikke kun undertrykke dem. For eksempel kan du rapportere til supporten om, at der er et problem. Hvis den falske positiv kan rettes, kan du i fremtidige opdateringer bemærke, at der bliver færre og færre specifikke falske positiver for din kodebase.
Efter integrationen
Vi har nu gennemgået alle trin til at integrere statisk analyse i udviklingsprocessen. På trods af vigtigheden af at konfigurere sådanne værktøjer i CI, er det vigtigste sted for opstart faktisk computerens udvikler. For en statisk analysator er ikke en dommer, der siger et eller andet sted langt væk, at koden ikke er god nok. Nej, det er en hjælper, der skulle vejlede dig, hvis du er træt og minder dig om, hvis du har glemt noget.
Sandhedens er det uden regelmæssig brug, at statisk analyse næppe vil forenkle udviklingen betydeligt. For udvikleren ligger den største fordel ikke så meget i at finde komplekse og tvivlsomme dele af koden, men i at opdage dem tidligt. Enig, det er ikke kun ubehageligt, men også meget tidskrævende at opdage problemer, når ændringerne er sendt til test. Statisk analyse, når den bruges regelmæssigt, gennemgår hver ændring direkte på din computer og giver besked om mistænkelige steder under arbejdet med koden.
Og hvis du eller dine kolleger stadig er usikre på, om I skal implementere en analyser, vil jeg foreslå at gå videre til at læse artiklen "". Den behandler typiske bekymringer fra udviklere om, at statisk analyse vil tage deres tid og så videre.
Hvis du ønsker at dele denne artikel med et engelsktalende publikum, bedes du bruge linket til oversættelsen: Maxim Zvyagintsev. .
Kilde: habr.com
