Ahnus pidevast koodiarvustusest või silumisest pane mõtlema, kuidas oma elu lihtsustada. Ja kui veidi otsida või juhuslikult sattuda, võib kohata maagilist väljendit: "Staatiline analüüs". Vaatame, mis see on ja kuidas see teie projektiga koostööd teha saab.
Tegelikult, kui kirjutate mõnes kaasaegses keeles, siis, isegi sellest teadmata, olete oma koodi läbi staatilise analüsaatori lasknud. Asi on selles, et iga kaasaegne kompilaator pakub ehk vaid väikest, kuid siiski hoiatuste kogumit potentsiaalsete 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 kuskil funktsioonis kasutatud. Nii et tegelikult olete peaaegu alati kasutanud lihtsat statilist koodi analüsaatorit. Kuid erinevalt professionaalsetest analüsaatoritest, nagu Coverity, Klocwork või PVS-Studio, saavad kompilaatori antud hoiatused näidata vaid väikest hulka probleeme.
Kui te ei tea täpselt, mis staatiline analüüs on ja kuidas seda rakendada, , et paremini tutvuda selle meetodiga.
Miks on staatiline analüüs vajalik?
Lühidalt: kiirus ja lihtsustamine.
Staatiline analüüs aitab leida mitmesuguseid probleeme koodis: alates vale keele konstruktsioonide kasutamisest kuni trükivigadeni. Näiteks, selle asemel, et
auto x = obj.x;
auto y = obj.y;
auto z = obj.z;olete kirjutanud 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 annab PVS-Studio järgmise hoiatuse:
Kaaluge 'y' elemendi kasutamise õigsuse üle vaatamist.
Kui soovite seda viga kätega uurida, proovige valmis näidet Compiler Exploreris: **.
Ja nagu näete, ei pruugi sellistele koodi osadele alati tähelepanu pöörata, mistõttu võib silumisega minna aega, mõeldes, miks kõik töötab nii kummaliselt.
Kuid see on selge viga. Ent kui arendaja on kirjutanud alamaktsentseeritud koodi, sest unustas mõne keele nüansi? Või on ta koodis isegi lubanud ? К сожалению, подобные случаи совершенно обыденны и львиная часть времени тратится на то, чтобы отладить специфично работающий код, который содержит опечатки, типичные ошибки или undefined behavior.
Just for these situations, static analysis has emerged. It is a tool for developers that points out various issues in the code and explains in the documentation why certain things should not be done, what consequences may arise, and how to fix them. Here is an example of how this might look: **.
You can find more interesting errors that the analyzer may discover in the articles:
Now, having read this material and being convinced of the benefits of static analysis, you might want to try it out in practice. 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 out the useful practice of code reviews. It complements this process by helping to spot and correct typos, inaccuracies, and dangerous constructs in advance. It is much more productive to focus on algorithms and code clarity during code reviews than on spotting misplaced brackets or .
0. Getting to Know the Tool
Everything begins with a trial version. Indeed, it is difficult to decide to implement anything into the development process if you have never seen the tool in action before. Therefore, the first thing to do is to download .
What you will learn at this stage:
- What ways there are to interact with the analyzer;
- Whether the analyzer is compatible with your development environment;
- What problems currently exist in your projects.
After you have installed everything you need, the first thing to do is to run an analysis of the entire project (, , ). In the case of PVS-Studio in Visual Studio, you will see a picture like this (clickable):
The thing is, usually, projects with a large codebase generate a huge number of warnings from static analyzers. There is no need to fix them all, as your project is already functioning, which means these problems are not critical. However, you ja ja vajadusel neid parandada. Selleks tuleb välja filtreerida ja jätta ainult kõige usaldusväärsemad teated. PVS-Studio pluginas Visual Studio jaoks toimub see vigade taseme ja kategooriate filtreerimise abil. Kõige täpsema väljundi saamiseks hoidke alles ainult High ja Üldine (samuti klikkitav):
Tõepoolest, 178 hoiatuse vaatamine on oluliselt lihtsam kui mitu tuhat…
Vahekaartidel Medium ja Madal tuleb sageli head hoiatused, kuid nendesse kategooriatesse on kantud need diagnostikad, millel on madalam täpsus (usaldusväärsus). Hoiatuste tasemete ja Windowsi all töötamise võimaluste kohta saate rohkem lugeda siit: **.
Pärast kõige huvitavamate vigade edukat vaatamist (ja nende edukat parandamist) on väärt . See on vajalik selleks, et uued hoiatused ei kaoks vanade seas. Lisaks on staatiline analüsaator programmeerija abiline, mitte vigade nimekiri. 🙂
1. Automatiseerimine
Pärast tutvumist tuleb aeg seadistada pluginaid ja integreerida need CI-sse. See tuleb teha enne, kui programmeerijad hakkavad staatilist analüüsi kasutama. Asi on selles, et programmeerija võib unustada analüüsi lubada või isegi mitte soovida. Sellega tuleb teha lõplik kontroll, et kontrollimata kood ei saaks sattuda ühisesse arendusharu.
Mida te saate selle etapi jooksul teada:
- Milliseid automatiseerimise võimalusi tööriist pakub;
- Kas analüsaator on teie koostamissüsteemiga ühilduv.
Kuna ideaalne dokumentatsioon ei eksisteeri, tuleb mõnikord kirjutada . See on normaalne ja me oleme valmis teid aitama. 🙂
Ja nüüd asume pideva integreerimise (CI) teenuste juurde. Iga analüsaatorit on võimalik nende seas rakendada ilma tõsiste probleemideta. Selleks on vajalik luua pipeline’is eraldi etapp, mis tavaliselt asub pärast ehitamist ja ühikteste. See toimub erinevate käsurea utiliitide abil. Näiteks pakub PVS-Studio järgmisi utiliite:
- (lahenduste analüüs, C#, C++ projektid Windowsis)
- (kompileerimise jälgimine)
- (C++ projektide analüüs Linuxis / macOS-is)
- (lahenduste analüüs, C# projektid Linuxis / macOS-is)
- (Java projektide analüüs)
- (aruande failide konverter)
CI-sse analüüsi integreerimiseks tuleb teha kolm asja:
- Installige analüsaator;
- Käitage analüüsi;
- Tulemuste edastamine.
Näiteks PVS-Studio paigaldamiseks Linuxis (Debian-põhine) tuleb täita 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-studioWindowsi süsteemides puudub võimalus analüsaatori paigaldamiseks paketihaldurist, kuid analüsaatorit saab kasutada käsurealt:
PVS-Studio_setup.exe /verysilent /suppressmsgboxes
/norestart /nocloseapplicationsPVS-Studio paigaldamise kohta Windowsi süsteemides saab rohkem lugeda **.
Pärast paigaldamist tuleb analüüs otse käivitada. Kuid seda soovitatakse teha alles pärast kompileerimist ja teste. See on tingitud sellest, et staatilise analüüsi läbiviimiseks vajalik aeg on tavaliselt kaks korda pikem kui kompileerimisel.
Kuna käivitamise meetod sõltub platvormist ja projekti eripäradest, näitan ma näitena C++ (Linux) varianti:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
plog-converter -t errorfile PVS-Studio.log --cerr -wEsimene käsk käivitab analüüsi ja teine aruande tekstiformaadisse, kuvab selle ekraanile ja tagastab mitte 0 väljakutse koodi, kui märgid on olemas. Seda mehhanismi on mugav kasutada kogumise blokeerimiseks, kui veateateid esineb. Kuid alati võite eemaldada lipu -w ja mitte blokeerida kogumist, mis sisaldab hoiatavaid sõnumeid.
Märkus. Tekstiformaat ei ole mugav. See on esitatud lihtsalt näitena. Pange tähele huvitavamat aruande vormingut — FullHtml. See võimaldab koodi kaudu navigeerida.
CI-s analüüsi seadistamise kohta saab rohkem lugeda artiklist "" (Windows) või "" (Linux).
Hästi, olete seadistanud analüsaatori töö build-serveris. Nüüd, kui keegi on üles laadinud kontrollimata koodi, langeb kontrolli etapp ja te suudate probleemi avastada, kuid see ei ole päris mugav, kuna efektiivsem on projekti kontrollida enne nagu toimub harude ühinemine, vaid enne, pull request'i etapis.
Üldiselt ei erine pull request'i analüüsi seadistamine oluliselt tavalisest analüüsi käivitamisest CI-s. Erandiks on vajadus saada muudetud failide nimekiri. Tavaliselt saab neid saada, küsides kahe haru vahelt erinevust git abil:
git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.listNüüd tuleb see failide loetelu edastada analüsaatorile. Näiteks PVS-Studios on see rakendatud lipuga -S:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
-S .pvs-pr.listLisainfot pull requestide analüüsi kohta leiate **. Isegi kui teie CI ei ole artiklis mainitud teenuste nimekirjas, võib teile olla kasu üldosast, mis käsitleb selle tüüpi analüüsi teooriat.
Konfigureerides pull requestide analüüsi, saate blokeerida hoiatusi sisaldavad committ'id, luues seega piiri, millest kontrollimata kood ei saa üle minna.
See on kindlasti hea, kuid oleks soovitav näha kõiki hoiatusi ühes kohas. Mitte ainult staatilisest analüsaatorist, vaid ka üksustestide või dünaamilise analüsaatori poolt. Selle jaoks on erinevad teenused ja pistikprogrammid. Näiteks PVS-Studio'l on .
2. Arendajate masinatesse integreerimine
Nüüd on aeg analüsaatori paigaldamiseks ja seadistamiseks igapäevaseks kasutamiseks arendamisel. Sellest hetkest olete tutvunud enamikuga tööviise, seega võib seda pidada kõige lihtsamaks osaks.
Lihtsama variandina võivad arendajad ise vajaliku analüsaatori paigaldada. Kuid see võtaks palju aega ja segaks neid arenduselt, seetõttu võite selle protsessi automatiseerida, kasutades installijat ja vajalikke lippe. PVS-Studio jaoks on erinevad . Siiski on alati paketihaldurid, näiteks Chocolatey (Windows), Homebrew (macOS) või kümneid variante Linuxile.
Seejärel tuleb paigaldada vajalikud pistikprogrammid, näiteks , , jne.
3. Igapäevane kasutamine
Selles etapis on aeg öelda paar sõna analüsaatori töö kiirendamise viiside kohta igapäevasel kasutamisel. Kogu projekti täielik analüüs võtab väga palju aega, kuid kas me muudame sageli koodi korraga kogu projektis? Harva leidub niivõrd ulatuslikku refaktoreerimist, mis hõlmab korraga kogu koodibaasi. Muudetud failide hulk harva ületab kümmet, seega on mõtet neid analüüsida. Sellises olukorras on olemas . Ärge kartke, see ei ole veel üks tööriist. See on spetsiaalne režiim, mis võimaldab analüüsida ainult muudetud faile ja nende sõltuvusi, ning see toimub automaatselt pärast kompileerimist, kui töötate IDE-s, kus on installitud pistikprogramm.
Kui analüsaator avastab hiljuti muudetud koodis probleeme, annab ta sellest ise teada. Näiteks PVS-Studio teavitab teid sellest teavitusega:
Ainult öelda arendajatele, et kasutada tööriista, ei ole piisav. Tuleb kuidagi rääkida neile, mis see on ja kuidas see töötab. Siin on näiteks artiklid PVS-Studio kiireks alustamiseks, kuid sarnaseid õpetusi leiate igasuguste teie valitud tööriistade kohta:
Sellised artiklid annavad kogu vajaliku teabe igapäevaseks kasutamiseks ja ei võta palju aega. 🙂
Juba tööriistaga tutvumise etapis surusime maha palju teateid ühe esialgse käivitamise ajal. Kahjuks ei ole staatilised analüsaatorid ideaalsed, seetõttu annavad nad aeg-ajalt valehäireid. Nende mahavõtmine on tavaliselt lihtne, näiteks PVS-Studio pistikprogrammis Visual Studios piisab ühe nupu vajutamisest:
Siiski ei saa te ainult neid maha suruda. Näiteks saate teatada toele problemaatika olemasolust. Kui valehäire on parandatav, võite tulevastes värskendustes märgata, et iga korraga on teie koodibaasi jaoks üha vähem ja vähem valehäireid.
Pärast integreerimist
Nüüd oleme läbinud kõik etapid staatilise analüüsi integreerimiseks arendusprotsessi. Hoolimata tööriistade sätete seadistamise olulisusest CI-s, on peamine koht nende tööks arendaja arvuti. Lõppude lõpuks on staatiline analüsaator mitte kohtunik, kes ütleb kaugelt, et kood ei sobi. Vastupidi, see on abiline, mis annab teada, kui olete väsinud, ja tuletab meelde, kui olete midagi unustanud.
Tõde on see, et regulaarse kasutamise puudumisel ei muuda staatiline analüüs arendust oluliselt lihtsamaks. Lõppude lõpuks seisneb selle peamine kasu arendajale mitte niivõrd keeruliste ja vaieldavate koodilõikude leidmises, vaid nende varajases tuvastamises. Olgem nõus, et probleemi avastamine, kui muudatused on juba testimiseks saadetud, on mitte ainult ebameeldiv, vaid ka väga aeganõudev. Regulaarne staatiline analüüs vaatab iga muudatuse läbi otse teie arvutis ja teavitab kahtlastest kohtadest koodi kirjutamise ajal.
Ja kui te või teie kolleegid pole endiselt kindlad, kas analüsaatori rakendamine on õigustatud, soovitan Teil nüüd minna lugema artiklit "". Selles käsitletakse arendajate tüüpilisi muresid selle üle, et staatiline analüüs röövib nende aega ja nii edasi.
Kui soovite seda artiklit jagada ingliskeelse publikuga, palun kasutage tõlke linki: Maxim Zvyagintsev. .
Allikas: habr.com
