🥇Statisk analys – från introduktion till integration

I stadiet av oändlig kodgranskning eller felsökning, tänker man ibland på hur man kan förenkla sitt liv. Efter lite letande, eller kanske av en slump, kan man stöta på det magiska uttrycket: "Statisk analys". Låt oss titta på vad detta innebär och hur det kan interagera med ditt projekt.

Egentligen, om du skriver i något modernt programmeringsspråk, har du, även utan att veta om det, redan kört det genom en statisk analysator. Det är så att varje modern kompilator tillhandahåller en, om än minimal, uppsättning av varningar om potentiella problem i koden. Till exempel, när du kompilerar C++-kod i Visual Studio kan du se följande:

I detta utdata ser vi att variabeln var aldrig användes någonstans i funktionen. Så i själva verket har du nästan alltid använt en enkel statisk kodanalysator. Men till skillnad från professionella analysatorer som Coverity, Klocwork eller PVS-Studio, kan varningarna som kompilatorn ger endast påpeka en liten mängd problem.

Om du inte vet säkert vad statisk analys är och hur man implementerar det, denna artikel, för att fördjupa dig mer i denna metodologi.

Vad behövs statisk analys för?

Kort sagt: hastighet och förenkling.

Statisk analys gör det möjligt att hitta mängder av 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 ser finns det ett stavfel i den sista raden. Till exempel ger PVS-Studio följande varning:

V537 Överväg att granska korrektheten av användningen av 'y'-objektet.

Om du vill testa detta fel manuellt, prova ett färdigt exempel på Compiler Explorer: *klicka*.

Och som du kanske förstår, är det inte alltid möjligt att lägga märke till sådana kodstycken direkt, vilket kan leda till att man sitter fast i felsökning i en timme, förundrad över varför allt verkar så konstigt.

Men detta är ett uppenbart fel. Vad händer om utvecklaren skrev ineffektiv kod eftersom han glömde någon nyans av språket? Eller om han helt enkelt slutade med undefined behavior? К сожалению, подобные случаи совершенно обыденны и львиная часть времени тратится на то, чтобы отладить специфично работающий код, который содержит опечатки, типичные ошибки или undefined behavior.

Det var just för dessa situationer som statisk analys uppstod. Det är en assistent för utvecklaren som visar på olika problem i koden och förklarar i dokumentationen varför det är fel att skriva på det sättet, vilka konsekvenser det kan få och hur man åtgärdar det. Här är ett exempel på hur det kan se ut: *klicka*.

Fler intressanta fel som analysatorn kan upptäcka kan du hitta i artiklar:

Nu, efter att ha läst detta material och övertygat dig om fördelarna med statisk analys, kanske du vill prova det i praktiken. Men hur börjar man? Hur integrerar man ett nytt verktyg i ett pågående projekt? Och hur introducerar man det för teamet? Du hittar svaren på dessa frågor nedan.

Anteckning. Statisk analys ersätter inte och avskaffar inte något så värdefullt som kodgranskningar. Den kompletterar denna process genom att hjälpa till att förutse och korrigera stavfel, felaktigheter och farliga konstruktioner. Det är mycket mer produktivt att fokusera på algoritmer och kodens tydlighet under kodgranskningarna, snarare än att jaga efter en felplacerad parentes eller läsa tråkiga jämföringsfunktioner.

0. Bekanta dig med verktyget

Allt börjar med en testversion. Det är verkligen svårt att bestämma sig för att införa något i utvecklingsprocessen om man aldrig har sett verktyget i aktion tidigare. Så det första steget är att ladda ner en provversion.

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

Vilka sätt det finns att interagera med analysatorn;
Om analysatorn är kompatibel med din utvecklingsmiljö;
Vilka problem som finns i dina projekt just nu.

När du har installerat allt du behöver är det första steget att köra en analys av hela projektet (Windows, Linux, macOS). I fallet med PVS-Studio i Visual Studio kommer du att se något som detta (klickbart):

Faktum är att statiska analysatorer vanligtvis genererar en stor mängd varningar för projekt med en stor kodbas. Det är inte nödvändigt att åtgärda dem alla, eftersom ditt projekt redan fungerar, vilket innebär att dessa problem inte är kritiska. Men du kan titta på de mest intressanta varningarna. och vid behov rätta dem. För detta behöver man filtrera utdata och behålla endast de mest tillförlitliga meddelandena. I PVS-Studio plugin för Visual Studio görs detta genom att filtrera efter nivåer och kategorier av fel. För att få den mest exakta utdata, låt endast följande vara aktiverat Hög och General (även klickbart):

Verkligen, att granska 178 varningar är betydligt enklare än flera tusen...

I flikarna Medium och Låg finns det ofta bra varningar, men i dessa kategorier ingår diagnoser som har lägre precision (tillförlitlighet). Mer information om varningsnivåer och alternativ för Windows kan ses här: *klicka*.

Efter att ha granskats de mest intressanta felen (och framgångsrikt åtgärdat dem) ska man dämpa de återstående varningarna. Detta behövs för att nya varningar inte ska försvinna bland de gamla. Dessutom är den statiska analysatorn en hjälpare för programmeraren, och inte en lista över buggar. 🙂

1. Automatisering

Efter introduktionen kommer tiden för att ställa in plugins och integrera dem i CI. Detta måste göras innan programmerarna börjar använda den statiska analysatorn. Anledningen är att en programmerare kan glömma att aktivera analysen eller helt enkelt inte vilja göra det. För detta måste en slutlig kontroll göras så att obevakad kod inte kan hamna i den allmänna utvecklingsgrenen.

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

Vilka automatiseringsalternativ verktyget erbjuder;
Är analysatorn kompatibel med ditt byggsystem.

Eftersom det inte finns någon perfekt dokumentation, måste man ibland skriva till supporten. Det är helt okej, och vi är glada att hjälpa dig. 🙂

Låt oss nu gå vidare till kontinuerlig integrations (CI) tjänster. Varje analysator kan implementeras i dem utan allvarliga problem. För detta behöver du skapa ett separat steg i pipelinen, som vanligtvis ligger efter bygget och enhetstester. Detta görs med hjälp av olika konsolverktyg. Till exempel erbjuder PVS-Studio följande verktyg:

PVS-Studio_Cmd.exe (analys av lösningar, C#, C++ projekt på Windows)
CLMonitor.exe (övervakning av kompilering)
pvs-studio-analyzer (analys av C++ projekt på Linux / macOS)
pvs-studio-dotnet (analys av lösningar, C# projekt på Linux / macOS)
pvs-studio.jar (analys av Java projekt)
PlogConverter (konverterare av rapportfiler)

För att integrera analysen i CI måste tre saker göras:

Installera analysatorn;
Starta analysen;
Leverera resultaten.

Till exempel, för att installera PVS-Studio på Linux (Debian-baserat) behöver 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

I system som körs under Windows finns det ingen möjlighet att installera analysatorn via paketförvaltaren, men det är möjligt att starta analysatorn från kommandoraden:

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

Mer om distribution av PVS-Studio i Windows-system kan läsas *). Ett typiskt exempel på användning:*.

Efter installationen måste du starta själva analysen. Men det rekommenderas att göra detta först efter att kompileringen och testerna har genomförts. Detta beror på att statisk analys vanligtvis tar dubbelt så lång tid som kompilering.

Eftersom sättet att starta beror på plattformen och projektets särdrag, visar jag ett alternativ för C++ (Linux) som exempel:

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

Det första kommandot kommer att utföra analysen, och det andra konverterarrapporten till textformat, skriver ut den på skärmen och returnerar en kod som skiljer sig från 0 om det finns varningar. En sådan mekanism är användbar för att blockera bygget om det finns felmeddelanden. Men du kan alltid ta bort flaggan -w och inte blockera bygget som innehåller varningar.

Anteckning. Textformatet är inte bekvämt. Det anges bara som exempel. Observera det mer intressanta rapportformatet - FullHtml. Det tillåter navigering i koden.

Mer om inställningen av analysen på CI kan läsas i artikeln "PVS-Studio och Continuous Integration" (Windows) eller "Hur man konfigurerar PVS-Studio i Travis CI" (Linux).

Bra, du har konfigurerat analysatorns arbete på byggservern. Nu, om någon har laddat upp osäker kod, kommer verifieringssteget att misslyckas, och du kan upptäcka problemet, men det är inte helt bekvämt, eftersom det är mer effektivt att kontrollera projektet innan sammanslagningen av grenarna, utan under pull request-steget.

Generellt sett skiljer sig inställningen av analysen för pull requests inte mycket från den vanliga analysen i CI. Med undantag för att det är nödvändigt att få en lista över ändrade filer. Vanligtvis kan de erhållas genom att begära skillnaden mellan grenarna med hjälp av git:

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

Nu måste vi överföra denna lista med filer till analysatorn. Till exempel i PVS-Studio görs detta med hjälp av flaggan -S:

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

Du kan läsa mer om analys av pull requestar *). Ett typiskt exempel på användning:*. Även om din CI inte finns med i listan över de angivna tjänsterna i artikeln, kommer den allmänna sektionen som handlar om teorin för denna typ av analys att vara nyttig för dig.

Genom att konfigurera analys av pull requestar kan du blockera commits som innehåller varningar, vilket skapar en gräns som obearbetad kod inte kan överskrida.

Detta är självklart bra, men det skulle vara trevligt att kunna se alla varningar på ett ställe. Inte bara från den statiska analysatorn utan också från enhetstester eller den dynamiska analysatorn. För detta finns det olika tjänster och plugins. PVS-Studio har till exempel en plugin för integration med SonarQube.

2. Integration på utvecklarnas maskiner

Nu är det dags att installera och konfigurera analysatorn för dagligt bruk i utvecklingen. Vid det här laget har du redan bekantat dig med de flesta arbetsmetoder, så detta kan kallas den enklaste delen.

Som det enklaste alternativet kan utvecklarna själva installera den nödvändiga analysatorn. Men detta kommer att ta mycket tid och avleda dem från utvecklingen, så du kan automatisera denna process genom att använda installationsprogrammet och nödvändiga flaggor. För PVS-Studio finns det olika flaggar för automatiserad installation. Det finns alltid paketmanagerare, såsom Chocolatey (Windows), Homebrew (macOS) eller dussintals alternativ för Linux.

Därefter behöver du installera de nödvändiga plugins, till exempel för Visual Studio, IDEA, Rider med flera.

3. Daglig användning

Vid denna punkt är det dags att säga några ord om sätt att påskynda analysatorns arbete vid daglig användning. En fullständig analys av hela projektet tar mycket tid, men hur ofta ändrar vi koden på en gång i hela projektet? Det finns knappt något så omfattande refaktorisering som omedelbart påverkar hela kodbasen. Antalet ändrade filer på en gång överstiger sällan ett tiotal, därför är det meningsfullt att analysera just dem. För sådana situationer finns det en inkrementell analysläge. Bara bli inte rädda, det är inte ett nytt verktyg. Det är ett speciellt läge som tillåter analys av endast ändrade filer och deras beroenden, och detta sker automatiskt efter kompilering om du arbetar i en IDE med den installerade plugin.

Om analysatorn hittar problem i den nyligen ändrade koden, kommer den att meddela om detta automatiskt. Till exempel, PVS-Studio kommer att informera dig om detta med ett meddelande:

Det räcker inte med att säga till utvecklarna att använda verktyget. Vi behöver på något sätt berätta för dem vad det är och hur det fungerar. Här är till exempel artiklar om snabbstart för PVS-Studio, men liknande handledningar kan du hitta för vilket verktyg du än föredrar:

Sådana artiklar ger all nödvändig information för dagligt bruk och tar inte mycket tid. 🙂

Redan i inledningen till verktyget undertryckte vi många varningar under en av de första körningarna. Tyvärr är statiska analysatorer inte perfekta, så de ger ibland falska positiva. Att undertrycka dem är vanligtvis enkelt, till exempel i PVS-Studio-plugin för Visual Studio räcker det med att trycka på en knapp:

Men du kan inte bara undertrycka dem. Du kan till exempel rapportera ett problem till supporten. Om en falsk positiv kan åtgärdas, kan du i framtida uppdateringar märka att antalet specifika falska positiva för din kodbas minskar mer och mer.

Efter integrationen

Vi har nu gått igenom alla steg för att integrera statisk analys i utvecklingsprocessen. Trots vikten av att konfigurera sådana verktyg på CI, är den viktigaste platsen för körning just utvecklarens dator. För en statisk analysator är det inte en domare som säger att koden inte duger från en avlägsen plats. Tvärtom, det är en assistent som ger råd när du är trött och påminner dig om du har glömt något.

Sanningen är att utan regelbunden användning av statisk analys knappast kommer utvecklingen att bli enklare. Den största fördelen för utvecklaren ligger inte så mycket i att hitta komplexa och tveksamma kodavsnitt, utan snarare i att tidigt upptäcka dem. Håller ni inte med om att det är frustrerande att upptäcka ett problem när ändringarna har skickats för testning, och att det dessutom kan ta lång tid? Statisk analys, vid regelbunden användning, granskar varje förändring direkt på din dator och informerar om misstänkta områden medan du arbetar med koden.

Och om du eller dina kollegor fortfarande är osäkra på om ni ska implementera en analysator, föreslår jag att ni nu går vidare till att läsa artikeln "Anledningar till att införa en statistisk kodanalysator PVS-Studio i utvecklingsprocessen". I den diskuterade typiska farhågor bland utvecklare om att statisk analys skulle ta deras tid och så vidare.

Om du vill dela denna artikel med en engelsktalande publik, vänligen använd länken till översättningen: Maxim Zvyagintsev. Statisk analys: Från att komma igång till integration.

Källa: habr.com