🥇Statisk analys - från introduktion till integration

Trött på oändlig kodgranskning eller felsökning, ibland tänker du på hur du kan förenkla ditt liv. Och efter att ha letat lite, eller av misstag snubblat på det, kan du se den magiska frasen: "Statisk analys". Låt oss se vad det är och hur det kan interagera med ditt projekt.

Faktum är att om du skriver på något modernt språk så körde du det genom en statisk analysator utan att ens inse det. Faktum är att vilken modern kompilator som helst ger, om än en liten, uppsättning varningar om potentiella problem i koden. Till exempel, när du kompilerar C++-kod i Visual Studio kan du se följande:

I denna utdata ser vi att variabeln var användes aldrig någonstans i funktionen. Så i verkligheten använde du nästan alltid en enkel statisk kodanalysator. Men till skillnad från professionella analysatorer som Coverity, Klocwork eller PVS-Studio, kan varningarna från kompilatorn bara indikera ett litet antal problem.

Om du inte vet säkert vad statisk analys är och hur man implementerar den, läs den här artikelnför att lära dig mer om denna metod.

Varför behöver du statisk analys?

I ett nötskal: acceleration och förenkling.

Statisk analys gör att du kan hitta många olika problem i koden: från felaktig användning av språkkonstruktioner till stavfel. Till exempel istället för

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

Du skrev följande kod:

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

Som du kan se är det ett stavfel på sista raden. Till exempel utfärdar PVS-Studio följande varning:

V537 Överväg att granska riktigheten av "y"-objektets användning.

Om du vill sticka händerna i det här felet, prova ett färdigt exempel i Compiler Explorer: *gråta*.

Och som du förstår är det inte alltid möjligt att uppmärksamma sådana kodavsnitt direkt, och på grund av detta kan du sitta och felsöka i en timme och undra varför allt fungerar så konstigt.

Detta är dock helt klart ett misstag. Tänk om utvecklaren skrev suboptimal kod för att han glömde lite subtilitet i språket? Eller till och med tillåtit det i koden odefinierat beteende? Tyvärr är sådana fall helt vanliga och lejonparten av tiden går åt till att felsöka specifikt fungerande kod som innehåller stavfel, typiska fel eller odefinierat beteende.

Det är för dessa situationer som statisk analys dök upp. Detta är en assistent för utvecklaren som kommer att peka ut olika problem i koden och förklara i dokumentationen varför det inte är nödvändigt att skriva på det här sättet, vad det kan leda till och hur man fixar det. Här är ett exempel på hur det kan se ut: *gråta*.

Du kan hitta fler intressanta fel som analysatorn kan upptäcka i artiklarna:

Nu när du har läst det här materialet och är övertygad om fördelarna med statisk analys, kanske du vill prova det. Men var ska man börja? Hur integrerar man ett nytt verktyg i ditt nuvarande projekt? Och hur presenterar man laget för honom? Du hittar svar på dessa frågor nedan.

Observera. Statisk analys ersätter eller avbryter inte en sådan användbar sak som kodgranskning. Det kompletterar denna process och hjälper till att upptäcka och korrigera stavfel, felaktigheter och farliga mönster i förväg. Det är mycket mer produktivt att fokusera på kodgranskning på algoritmer och kodtydlighet, snarare än att leta efter en felplacerad parentes eller läs tråkiga jämförelsefunktioner.

0. Lär känna verktyget

Det hela börjar med en testversion. Det är faktiskt svårt att bestämma sig för att implementera något i utvecklingsprocessen om du aldrig har sett verktyget live tidigare. Därför är det första du bör göra att ladda ner testversion.

Vad du kommer att lära dig i detta skede:

Vilka är sätten att interagera med analysatorn;
Är analysatorn kompatibel med din utvecklingsmiljö?
Vilka problem finns det för närvarande i dina projekt?

När du har installerat allt du behöver är det första du bör göra att göra en analys av hela projektet (Windows, Linux, MacOS). När det gäller PVS-Studio i Visual Studio kommer du att se en liknande bild (klickbar):

Faktum är att statiska analysatorer vanligtvis utfärdar ett stort antal varningar för projekt med en stor kodbas. Det finns ingen anledning att fixa dem alla, eftersom ditt projekt redan fungerar, vilket innebär att dessa problem inte är kritiska. Men du du kan titta på de mest intressanta varningarna och korrigera dem vid behov. För att göra detta måste du filtrera utdata och lämna bara de mest pålitliga meddelandena. I plugin-programmet PVS-Studio för Visual Studio görs detta genom att filtrera efter felnivåer och kategorier. Lämna endast för den mest exakta utmatningen Hög и Allmänt (även klickbar):

Faktum är att 178 varningar är mycket lättare att se än flera tusen...

I flikar Medium и Låg Ofta finns det bra varningar, men dessa kategorier inkluderar de diagnostik som har mindre noggrannhet (tillförlitlighet). Mer information om varningsnivåer och alternativ för att arbeta under Windows finns här: *gråta*.

Att framgångsrikt ha granskat de mest intressanta felen (och framgångsrikt korrigerat dem) är värt undertrycka återstående varningar. Detta är nödvändigt för att nya varningar inte ska gå vilse bland de gamla. Dessutom är en statisk analysator en assistent för programmeraren, och inte en lista över buggar. 🙂

1. Automation

Efter att ha blivit bekant är det dags att konfigurera plugins och integrera i CI. Detta måste göras innan programmerare börjar använda den statiska analysatorn. Faktum är att programmeraren kanske glömmer att aktivera analys eller inte vill göra det alls. För att göra detta måste du göra en sista kontroll av allt så att oprövad kod inte kan komma in i den allmänna utvecklingsgrenen.

Vad du kommer att lära dig i detta skede:

Vilka automationsalternativ ger verktyget;
Är analysatorn kompatibel med ditt monteringssystem?

Eftersom perfekt dokumentation inte finns måste man ibland skriva in sig Stöd. Detta är normalt och vi hjälper dig gärna. 🙂

Låt oss nu gå vidare till tjänster för kontinuerlig integration (CI). Vilken analysator som helst kan implementeras i dem utan några allvarliga problem. För att göra detta måste du skapa ett separat steg i pipelinen, som vanligtvis ligger efter bygg- och enhetstesten. Detta görs med hjälp av olika konsolverktyg. Till exempel tillhandahåller PVS-Studio följande verktyg:

PVS-Studio_Cmd.exe (analys av lösningar, C#, C++ projekt på Windows)
CLMonitor.exe (sammanställningsövervakning)
pvs-studio-analysator (analys av C++-projekt på Linux/macOS)
pvs-studio-dotnet (lösningsanalys, C#-projekt på Linux/macOS)
pvs-studio.jar (analys av Java-projekt)
PlogConverter (rapportfilkonverterare)

För att integrera analys i CI måste du göra tre saker:

Installera analysatorn;
Kör analys;
Leverera resultat.

Till exempel, för att installera PVS-Studio på Linux (Debian-base), måste du köra följande kommandon:

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å system som kör Windows finns det inget sätt att installera analysatorn från pakethanteraren, men det är möjligt att distribuera analysatorn från kommandoraden:

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

Du kan läsa mer om att distribuera PVS-Studio på system som kör Windows *här*.

Efter installationen måste du köra analysen direkt. Det rekommenderas dock att göra detta först efter att sammanställningen och testerna har godkänts. Detta beror på att statisk analys vanligtvis tar dubbelt så lång tid som kompilering.

Eftersom lanseringsmetoden beror på plattformen och projektfunktionerna kommer jag att visa alternativet för C++ (Linux) som ett exempel:

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

Det första kommandot utför analysen och det andra kuvertkonverterar rapporten till textformat, visar den på skärmen och returnerar en annan returkod än 0 om det finns varningar. En mekanism som denna kan bekvämt användas för att blockera en build när det finns felmeddelanden. Du kan dock alltid ta bort flaggan -w och blockera inte en enhet som innehåller varningar.

Observera. Textformatet är obekvämt. Den tillhandahålls helt enkelt som ett exempel. Var uppmärksam på ett mer intressant rapportformat - FullHtml. Den låter dig navigera genom koden.

Du kan läsa mer om att sätta upp analys på CI i artikeln "PVS-Studio och kontinuerlig integration" (Windows) eller "Hur man ställer in PVS-Studio i Travis CI" (Linux).

Okej, du har konfigurerat analysatorn på byggservern. Nu, om någon laddade upp otestad kod, kommer verifieringsstadiet att misslyckas, och du kommer att kunna upptäcka problemet, men detta är inte helt bekvämt, eftersom det är mer effektivt att kontrollera projektet inte efter att grenarna har slagits samman, men före det, vid dragbegäran. A.

Generellt sett skiljer sig inte inställningen av en pull request-analys mycket från den vanliga lanseringen av en analys på CI. Förutom behovet av att få en lista över ändrade filer. Dessa kan vanligtvis erhållas genom att fråga skillnaderna mellan grenar med git:

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

Nu måste du skicka denna lista med filer till analysatorn som indata. Till exempel, i PVS-Studio implementeras detta med flaggan -S:

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

Du kan ta reda på mer om att analysera pull-förfrågningar *här*. Även om din CI inte finns på listan över tjänster som nämns i artikeln, kommer du att finna det allmänna avsnittet som ägnas åt teorin om denna typ av analys användbart.

Genom att sätta upp analys av pull-förfrågningar kan du blockera commits som innehåller varningar, och därigenom skapa en gräns som otestad kod inte kan passera.

Det här är verkligen bra, men jag skulle vilja kunna se alla varningar på ett ställe. Inte bara från den statiska analysatorn, utan också från enhetstester eller från den dynamiska analysatorn. Det finns olika tjänster och plugins för detta. PVS-Studio har till exempel plugin för integration i SonarQube.

2. Integration på utvecklarmaskiner

Nu är det dags att installera och konfigurera analysatorn för dagligt utvecklingsbruk. Vid det här laget har du redan blivit bekant med de flesta sätten att arbeta, så detta kan kallas den enklaste delen.

Som det enklaste alternativet kan utvecklare själva installera den nödvändiga analysatorn. Detta kommer dock att ta mycket tid och distrahera dem från utvecklingen, så du kan automatisera denna process med hjälp av ett installationsprogram och de nödvändiga flaggorna. För PVS-Studio finns olika flaggor för automatiserad installation. Det finns dock alltid pakethanterare, till exempel Chocolatey (Windows), Homebrew (macOS) eller dussintals alternativ för Linux.

Då måste du installera nödvändiga plugins, till exempel för Visual Studio, ANING, Rider och så vidare

3. Daglig användning

I detta skede är det dags att säga några ord om sätt att snabba upp analysatorn under daglig användning. En fullständig analys av hela projektet tar mycket tid, men hur ofta byter vi kod genom hela projektet på en gång? Det finns knappast någon refaktorering som är så stor att den omedelbart kommer att påverka hela kodbasen. Antalet filer som ändras åt gången överstiger sällan ett dussin, så det är vettigt att analysera dem. För en sådan situation finns inkrementell analysläge. Var bara inte orolig, det här är inget annat verktyg. Detta är ett speciellt läge som låter dig analysera endast ändrade filer och deras beroenden, och detta sker automatiskt efter byggandet om du arbetar i en IDE med plugin installerat.

Om analysatorn upptäcker problem i den nyligen ändrade koden kommer den att rapportera detta oberoende. Till exempel kommer PVS-Studio att berätta om detta med en varning:

Naturligtvis räcker det inte att berätta för utvecklare att använda verktyget. Vi måste på något sätt berätta för dem vad det är och hur det är. Här är till exempel artiklar om en snabbstart för PVS-Studio, men du kan hitta liknande handledningar för alla verktyg du föredrar:

Sådana artiklar ger all information som behövs för dagligt bruk och tar inte mycket tid. 🙂

Redan i stadiet av att lära känna verktyget undertryckte vi många varningar under en av de första lanseringarna. Tyvärr är statiska analysatorer inte perfekta, så då och då ger de falska positiva resultat. Det är vanligtvis lätt att undertrycka dem; till exempel, i plugin-programmet PVS-Studio för Visual Studio behöver du bara klicka på en knapp:

Men du kan göra mer än att bara undertrycka dem. Du kan till exempel rapportera ett problem till supporten. Om den falska positiva kan korrigeras, kan du i framtida uppdateringar märka att det varje gång finns färre och färre falska positiva specifika för din kodbas.

Efter integration

Så vi har gått igenom alla stadier för att integrera statisk analys i utvecklingsprocessen. Trots vikten av att installera sådana verktyg på CI, är den viktigaste platsen att köra dem på utvecklarens dator. En statisk analysator är trots allt inte en domare som säger någonstans långt ifrån dig att koden inte är bra. Det är tvärtom en assistent som säger till om du är trött och påminner dig om du har glömt något.

Det är sant att utan regelbunden användning är det osannolikt att statisk analys kommer att förenkla utvecklingen avsevärt. När allt kommer omkring ligger dess främsta fördel för en utvecklare inte så mycket i att söka efter komplexa och kontroversiella avsnitt av kod, utan i deras tidiga upptäckt. Håller med om att det inte bara är obehagligt, utan också mycket tidskrävande att upptäcka ett problem efter att redigeringarna har skickats för testning. Statisk analys, när den används regelbundet, tittar på varje ändring direkt på din dator och rapporterar misstänkta platser medan du arbetar med koden.

Och om du eller dina kollegor fortfarande inte är säkra på om det är värt att implementera analysatorn, föreslår jag att du nu börjar läsa artikeln "Skäl att introducera den statiska kodanalysatorn PVS-Studio i utvecklingsprocessen". Det tar upp typiska problem för utvecklare att statisk analys kommer att ta deras tid och så vidare.

Om du vill dela den här artikeln med en engelsktalande publik, använd gärna översättningslänken: Maxim Zvyagintsev. Statisk analys: Från att komma igång till integration.

Källa: will.com

Statisk analys - från introduktion till integration