🥇 Staatiline analüüs – tutvumisest integreerimiseni

Lõputu koodikontroll või silumine võib ajendada mõtlema, kuidas enda elu lihtsamaks teha. Veidi otsides või juhuslikult kokku puutudes võite näha maagilist mõistet: "Staatchanalyze". Vaatame, mis see on ja kuidas see võib teie projektiga suhelda.

Kui olete mõnes kaasaegses keeles koodi kirjutanud, siis isegi teadmata olete seda juba läbi staatchanalüsaatori jooksutanud. Tõsiasi on see, et iga kaasaegne kompilaator annab väikese, kuid siiski hoiatuste kogumi võimalike probleemide kohta koodis. Näiteks Visual Studios C++ koodi kompileerides võite näha järgmist:

Selles väljundis näeme, et muutuja var ei olnud üldse funktsioonis kasutatud. Seega olete tegelikult peaaegu alati kasutanud lihtsat staatchanalüsaatorit. Erinevalt professionaalsetest analüsaatoritest nagu Coverity, Klocwork või PVS-Studio, võivad kompilaatori hoiatused osutada ainult väikesele probleemide spektrile.

Kui te ei tea kindlalt, mis on staatchanalüüs ja kuidas seda rakendada, seda artiklit, et soovite põhjalikumalt tutvuda selle metoodikaga.

Miks on vajalik staatiline analüüs?

Lühidalt: kiirus ja lihtsus.

Staatiline analüüs võimaldab leida mitmesuguseid probleemide koodis: alates keele konstruktsioonide vale kasutamisest kuni trükivigadeni. Näiteks, mitte

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

Te kirjutasite järgmise koodi:

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

Nagu näete, on viimasel real trükiviga. Näiteks, PVS-Studio annab järgmise hoiatuse:

V537 Kaaluda 'y' elementi kasutamise õigsuse üle.

Kui soovite seda viga ise uurida, proovige valmis näidet Compiler Exploreris: *klik*.

Ja nagu te aru saite, ei pruugi olla alati võimalik kohe sellistele koodilõikudele tähelepanu pöörata, mis võib muuta veaotsingu väga ajamahukaks, tehes endale liiga, et miks kõik töötab nii kummaliselt.

Kuid see on ilmne viga. Ja kui arendaja kirjutas mitteoptimaalse koodi, kuna unustas mõne keele nüansi? Või lasi hoopis koodi määratlemata käitumine? К сожалению, подобные случаи совершенно обыденны и львиная часть времени тратится на то, чтобы отладить специфично работающий код, который содержит опечатки, типичные ошибки или undefined behavior.

Just for such situations, static analysis came into existence. It is a developer's assistant that points out various issues in the code and explains in the documentation why certain practices should be avoided, what consequences they might lead to, and how to fix them. Here’s an example of how it may look: *klik*.

You can find more interesting errors that the analyzer can detect in the articles:

Now, having read this material and realized the benefits of static analysis, you might want to try it out. But where to start? How to integrate a new tool into the current project? And how to introduce it to the team? You will find answers to these questions below.

Märkus. Static analysis does not replace or cancel such a useful practice as code reviews. It complements this process by helping to notice and correct typos, inaccuracies, and dangerous constructs in advance. It’s much more productive to focus on algorithms and code clarity during code reviews, rather than searching for misplaced brackets or reading boring comparison functions.

0. Tutvumine tööriistaga

Kõik algab prooviversioonist. Tõepoolest, on raske otsustada, kas midagi arendusse inteerida, kui pole kunagi näinud tööriista reaalses elus. Seetõttu tasub kõigepealt alla laadida katseaega.

Mida te selle etapi jooksul saate:

Millised on suhtlemisviisid analüsaatoriga;
Kas analüsaator on kooskõlas teie arenduskeskkonnaga;
Millised probleemid on praegu teie projektides.

Pärast vajalike komponentide installimist tasub esimesena käivitada kogu projekti analüüs (Windows, Linux, macOS). PVS-Studio puhul Visual Studios näete sarnast pilti (klikkimiseks):

Asja on selles, et tavaliselt annavad suured koodibaasid staatilised analüsaatorid tohutult palju hoiatusteateid. Pole vajalik neid kõiki parandada, kuna teie projekt töötab juba, mistõttu need probleemid ei ole kriitilised. Kuid te võite vaadata kõige huvitavamaid hoiatusteateid ja vajadusel parandada. Selleks tuleb väljund filtreerida ja jätta alles ainult kõige usaldusväärsemad teated. PVS-Studio plugin Visual Studio jaoks võimaldab filtreerida veateateid tasemete ja kategooriate järgi. Täpsema väljundi saamiseks hoidke sisse lülitatuna ainult Kõrge ja General (ka klikkitav):

Tõepoolest, 178 hoiatust on kergem läbida kui paar tuhat…

Vahekaartidel Medium ja Madal esineb sageli häid hoiat ab, kuid need kategooriad sisaldavad diagnostikat, mille täpsus (usaldusväärsus) on madalam. Täiendav teave hoiatuste tasemete ja Windowsi all töötamise variantide kohta on saadaval siin: *klik*.

Kui olete edukalt üle vaadanud kõige huvitavamad vead (ja need edukalt parandanud), tuleks küsida ülejäänud hoiatused. See on vajalik, et uued hoiat ab ei kaoks vanade hulka. Lisaks on staatiline analüsaator programmist abimees, mitte viga nimekiri. 🙂

1. Automaatika

Pärast tutvumist tuleb ajakohastada pluginaid ja integreerida need CI-sse. See tuleb teha enne, kui arendajad hakkavad kasutama staatilist analüsaatorit. Asi on selles, et programmeerija võib unustada analüüsi sisselülitamise või ei soovi seda üldse teha. Selleks on vajalik teostada teatud lõppkontroll, et mitterakendatud kood ei satuks ühisesse arendusoktaavi.

Mida te sellel etapil õppite:

Milliseid automaatimisvõimalusi tööriist pakub;
Kas analüsaator on ühilduv teie ehitussüsteemiga.

Kuna ideaalset dokumentatsiooni ei eksisteeri, tuleb vahel kirjutada toele. See on täiesti normaalne ja me oleme valmis teid aitama. 🙂

Nüüd liikume edasi pideva integreerimise (CI) teenuste juurde. Iga analüsaatorit saab neisse rakendada ilma tõsiste probleemideta. Selle jaoks tuleb luua eraldi etapp pipeline'is, mis asub tavaliselt pärast ehitamist ja üksuskatsetusi. Seda teostatakse erinevate käsurea utiliidiga. Näiteks pakub PVS-Studio järgmisi utiliite:

PVS-Studio_Cmd.exe (lahenduste, C#, C++ projektide analüüs Windowsis)
CLMonitor.exe (kompileerimise jälgimine)
pvs-studio-analyzer (C++ projektide analüüs Linuxis / macOSis)
pvs-studio-dotnet (lahenduste analüüs, C# projektid Linux / macOS)
pvs-studio.jar (Java projektide analüüs)
PlogConverter (aruandefailide konverter)

CI analüüsi integreerimiseks on vajalik teha kolm asja:

Analüsaatori installimine;
Analüüsi käivitamine;
Tulemuste kohaletoimetamine.

Näiteks PVS-Studio installimiseks Linuxis (Debian-põhine) tuleks käivitada järgmised käsud:

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

Windowsi süsteemides puudub võimalus analüsaatorit paketihaldurist installida, kuid analüsaatori käivitamine käsurealt on võimalik:

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

PVS-Studio käivitamisest Windowsi süsteemides saab lugeda *siin*.

Pärast installimist tuleb analüüs otse käivitada. Kuid seda soovitatakse teha alles pärast kompileerimist ja teste. See on tingitud asjaolust, et staatilise analüüsi jaoks on tavaliselt vajalik kahekordselt rohkem aega kui kompileerimiseks.

Kuna käivitamisviis sõltub platvormist ja projekti omadustest, näitan C++ (Linux) jaoks varianti näitena:

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

Esimene käsk analüüsib, teine muudabaruande tekstiformaadiks, kuvab selle ekraanile ja tagastab mitte 0 väljakode koodid, kui hoiatuste olemasolu tuvastatakse. Seda mehhanismi on mugav kasutada, et blokeerida ülesehitust, kui vigu leidub. Siiski, võite alati eemaldada lipu -w ja mitte blokeerida ülesehitust, mis sisaldab hoiatusi.

Märkus. Tekstiformaat on ebamugav. See toodi lihtsalt näitena. Pöörake tähelepanu huvitavamale aruande vormingule – FullHtml. See võimaldab koodi järgi navigeerida.

Täpsemat teavet analüüsi seadistamise kohta CI-s saab lugeda artiklist "PVS-Studio ja Continuous Integration" (Windows) või "Kuidas seadistada PVS-Studio Travis CI-s" (Linux).

Olete hästi seadistatud analüsaatori töö ehitusserveris. Nüüd, kui keegi üles laadib kontrollimata koodi, siis katse etapp ebaõnnestub ja te suudate probleemi avastada, kuid see ei ole just mugav, kuna efektiivsem on projekt kontrollida enne, kui harude ühinemine toimub, pull request'i etapis.

Üldiselt ei erine pull request'i analüüsi seadistamine oluliselt tavapärasest CI analüüsist. Erandiks on vajadus saada muudetud failide nimekiri. Selle saab tavaliselt kätte, küsides harude vahelise erinevuse kaudu gitiga:

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

Nüüd tuleb edastada analüsaatorile see failide nimekiri. Näiteks PVS-Studio's on see teostatud lipu abil -S:

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

Rohkem teavet pull request'ide analüüsi kohta leiate *siin*. Isegi kui teie CI ei ole artiklis loetletud teenuste seas, on üldine jaotis, mis käsitleb selle analüüsitüübi teooriat, teile kindlasti kasulik.

Kui olete seadistanud pull request'ide analüüsi, saate blokeerida hoiatustega commit'e, luues seeläbi piiri, mida kontrollimata kood ei saa ületada.

Kuid oleks hea, kui saaks kõiki hoiatusi näha ühes kohas. Mitte ainult staatilisest analüsaatorist, vaid ka ühikutest testidest või dünaamilisest analüsaatorist. Selleks on olemas erinevad teenused ja pluginaid. Näiteks PVS-Studio'l on plugin SonarQube'iga integreerimiseks.

2. Integreerimine arendajate masinatesse

Nüüd on aeg seadistada analüsaator igapäevaselt kasutamiseks arenduses. Selleks ajaks olete juba tutvunud enamikuga töömeetoditest, seega võib seda pidada kõige lihtsamaks osaks.

Lihtsaim variant on see, et arendajad saavad ise vajalikud analüsaatorid installida. Kuid see võtab palju aega ja võib arendustööst kõrvale juhtida, seega saate selle protsessi automatiseerida, kasutades installijat ja vajalikke lippe. PVS-Studio jaoks on erinevad lipud automatiseeritud installimiseks. Kuid alati on olemas ka pakihaldurid, näiteks Chocolatey (Windows), Homebrew (macOS) või kümned variandid Linuxile.

Seejärel tuleb installida vajalikud pluginate, näiteks Visual Studio, IDEA, Rider jne.

3. Igapäevane kasutamine

Selles etapis on aeg rääkida mõningatest viisidest analüüsijate töö kiirendamiseks igapäevasel kasutamisel. Kogu projekti täielik analüüs võtab väga kaua aega, kuid kui sageli me muudame koodi korraga kogu projektis? Harva on olemas nii ulatuslik refaktor, mis kohe mõjutaks kogu koodibaasi. Muudetud failide arv korraga ületab harva tosinat, seega on mõtet analüüsida just neid. Sellises olukorras on olemas inkrementsaanalüüsi režiim. Ära muretse, see ei ole veel üks tööriist. See on eriline režiim, mis võimaldab analüüsida ainult muudetud faile ja nende sõltuvusi, ning see toimub automaatselt pärast kompileerimist, kui töötad IDE-s, milles on installitud plugin.

Kui analüsaator tuvastab hiljuti muudetud koodis probleeme, siis teavitab ta sellest ise. Näiteks PVS-Studio ütleb teile sellest teavitusega:

Lihtsalt ei piisa sellest, et arendajad kasutavad tööriista. Peame neile kuidagi selgitama, mis see on ja kuidas seda kasutada. Näiteks on olemas artiklid PVS-Studio kiireks alustamiseks, kuid sarnaseid juhendeid leiate iga soovitud tööriista jaoks:

Sarnased artiklid annavad kogu igapäevaseks kasutamiseks vajaliku teabe ega võta palju aega. 🙂

Tööriistaga tutvumise etapis summutasime palju hoiatusi ühe esialgse käivituse ajal. Kahjuks ei ole staatilised analüsaatorid ideaalsed ning seetõttu annavad nad aeg-ajalt valehäireid. Need on tavaliselt kergesti summutatavad, näiteks PVS-Studio plugina puhul Visual Studios piisab ühest nupuvajutusest:

Siiski saate nende üle mitte ainult vaiki olla. Näiteks võite probleemist toetust teavitada. Kui valehäireid on võimalik parandada, siis tulevastes uuendustes võite märgata, et teie koodibaasiga seotud valehäireid on iga korraga aina vähem.

Pärast integreerimist

Nii oleme läbinud kõik etapid staatilise analüüsi integreerimise protsessis arendusse. Kuigi sarnaste tööriistade seadistamine CI-s on oluline, on kõige tähtsam käivitamiskoht arendaja arvuti. Lõppude lõpuks ei ole staatiline analüsaator kohtunik, kes kaugel teist ütleb, et kood ei sobi. Vastupidi, see on abiline, kes annab märku, kui te olete väsinud ja meenutab, kui te millegi unustate.

Tõde on see, et regulaarne staatiline analüüs ei lihtsusta arendust tõenäoliselt oluliselt. Selle peamine kasu arendajale ei seisne sugugi ainult keeruliste ja vaieldavate koodilõikude leidmises, vaid probleemide varajases tuvastamises. Olge julged, mõelda, et probleemide välja selgitamine, kui muudatused on testimisse saadetud, on mitte ainult ebamugav, vaid ka aeganõudev. Regulaarne staatiline analüüs vaatab iga muudatust otse teie arvutis ja annab märku kahtlastest kohtadest koodi kirjutamise ajal.

Ja kui te või teie kolleegid ei ole ikka veel kindlad, kas analüsaatori rakendamine on vajalik, siis soovitan teil nüüd lugeda artiklit "Põhjused staatilise koodianalüsaatori PVS-Studio rakendamiseks arendusprotsessis". Artiklis käsitletakse arendajate tavapäraseid muresid, et staatiline analüüs võtaks nende aega ja nii edasi.

Kui soovite seda artiklit jagada ingliskeelse publikuga, palun kasutage tõlke linki: Maxim Zvyagintsev. Static Analysis: From Getting Started to Integration.

Allikas: habr.com