Väsinud lõputust koodide ülevaatamisest või silumisest, mõtlete mõnikord, kuidas oma elu lihtsustada. Ja pärast väikest otsimist või kogemata sattudes näete võlufraasi: "Staatiline analüüs". Vaatame, mis see on ja kuidas see teie projektiga suhelda saab.
Tegelikult, kui sa kirjutad mis tahes tänapäevases keeles, siis ilma isegi aru saamata lasid selle läbi staatilise analüsaatori. Fakt on see, et iga kaasaegne kompilaator annab, ehkki väikese hulga hoiatusi koodi võimalike probleemide kohta. Näiteks Visual Studios C++ koodi kompileerimisel võite näha järgmist.
Selles väljundis näeme, et muutuja oli seda funktsioonis pole kunagi kasutatud. Nii et tegelikkuses kasutasite peaaegu alati lihtsat staatilise koodianalüsaatorit. Kuid erinevalt professionaalsetest analüsaatoritest, nagu Coverity, Klocwork või PVS-Studio, võivad kompilaatori hoiatused osutada vaid väikesele hulgale probleemidele.
Kui te ei tea kindlalt, mis on staatiline analüüs ja kuidas seda rakendada, selle metoodika kohta lisateabe saamiseks.
Miks vajate staatilist analüüsi?
Lühidalt: kiirendamine ja lihtsustamine.
Staatiline analüüs võimaldab koodist leida palju erinevaid probleeme: keelekonstruktsioonide ebaõigest kasutamisest kirjavigadeni. Näiteks selle asemel
auto x = obj.x;
auto y = obj.y;
auto z = obj.z;Kirjutasite järgmise koodi:
auto x = obj.x;
auto y = obj.y;
auto z = obj.x;Nagu näete, on viimasel real kirjaviga. Näiteks PVS-Studio annab järgmise hoiatuse:
Kaaluge y-üksuse kasutamise õigsuse ülevaatamist.
Kui soovite selle veaga oma käed lüüa, proovige Compiler Exploreris valmis näidet: **.
Ja nagu aru saate, pole alati võimalik sellistele koodilõikudele kohe tähelepanu pöörata ja seetõttu võite tund aega istuda siludes ja mõelda, miks kõik nii imelikult töötab.
See on aga selgelt viga. Mis siis, kui arendaja kirjutas ebaoptimaalse koodi, kuna ta unustas keele mõningaid peensusi? Või isegi lubas seda koodis ? Kahjuks on sellised juhtumid täiesti tavalised ja lõviosa ajast kulub spetsiaalselt töötava koodi silumisele, mis sisaldab kirjavigu, tüüpilisi vigu või määratlemata käitumist.
Just nende olukordade jaoks ilmus staatiline analüüs. See on abiline arendajale, kes juhib tähelepanu erinevatele probleemidele koodis ja selgitab dokumentatsioonis, miks nii ei ole vaja kirjutada, milleni see võib viia ja kuidas seda parandada. Siin on näide selle kohta, kuidas see välja näeb: **.
Huvitavamaid vigu, mida analüsaator suudab tuvastada, leiate artiklitest:
Nüüd, kui olete seda materjali lugenud ja veendunud staatilise analüüsi eelistes, võiksite seda proovida. Aga kust alustada? Kuidas integreerida uus tööriist oma praegusesse projekti? Ja kuidas talle meeskonda tutvustada? Nendele küsimustele leiate vastused allpool.
Märkus. Staatiline analüüs ei asenda ega tühista sellist kasulikku asja nagu koodiülevaatused. See täiendab seda protsessi, aidates eelnevalt märgata ja parandada kirjavigu, ebatäpsusi ja ohtlikke kujundusi. Palju produktiivsem on keskenduda algoritmide ja koodi selguse koodiülevaatele, selle asemel, et otsida valesti paigutatud sulgu või .
0. Tööriistaga tutvumine
Kõik algab prooviversioonist. Tõepoolest, on raske otsustada midagi arendusprotsessi tutvustada, kui te pole tööriista varem elus näinud. Seetõttu peaksite esimese asjana alla laadima .
Mida saate selles etapis õppida:
- Millised on analüsaatoriga suhtlemise viisid;
- Kas analüsaator ühildub teie arenduskeskkonnaga?
- Milliseid probleeme teie projektides praegu esineb?
Kui olete kõik vajaliku installinud, peaksite esimese asjana käivitama kogu projekti analüüsi (, , ). Visual Studio PVS-Studio puhul näete sarnast pilti (klõpsatav):
Fakt on see, et staatilised analüsaatorid annavad tavaliselt suure koodibaasiga projektide jaoks tohutul hulgal hoiatusi. Neid kõiki pole vaja parandada, kuna teie projekt juba töötab, mis tähendab, et need probleemid pole kriitilised. Siiski, teie ja vajadusel parandage neid. Selleks peate väljundit filtreerima ja jätma ainult kõige usaldusväärsemad sõnumid. Visual Studio PVS-Studio pistikprogrammis tehakse seda veatasemete ja kategooriate järgi filtreerides. Kõige täpsema väljundi saamiseks jätke ainult Suur и Üldine (ka klõpsatav):
Tõepoolest, 178 hoiatust on palju lihtsam vaadata kui mitu tuhat...
Vahelehtedel Keskmine и Madal Sageli on häid hoiatusi, kuid nendesse kategooriatesse kuuluvad need diagnostikad, mille täpsus (usaldusväärsus) on väiksem. Lisateavet hoiatustasemete ja Windowsi all töötamise võimaluste kohta leiate siit: **.
Kõige huvitavamad vead edukalt läbi vaadanud (ja need edukalt parandanud) tasub . See on vajalik selleks, et uued hoiatused vanade sekka ei kaoks. Lisaks on staatiline analüsaator programmeerija abiline, mitte vigade loend. 🙂
1. Automatiseerimine
Pärast tutvumist on aeg pistikprogrammid konfigureerida ja CI-sse integreerida. Seda tuleb teha enne, kui programmeerijad hakkavad staatilist analüsaatorit kasutama. Fakt on see, et programmeerija võib unustada analüüsi lubada või ei taha seda üldse teha. Selleks on vaja kõik lõplikult kontrollida, et testimata kood ei pääseks üldisesse arendusharusse.
Mida saate selles etapis õppida:
- Milliseid automatiseerimisvõimalusi tööriist pakub;
- Kas analüsaator ühildub teie koostesüsteemiga?
Kuna täiuslikku dokumentatsiooni pole olemas, peate mõnikord ka sisse kirjutama . See on normaalne ja aitame teid hea meelega. 🙂
Liigume nüüd edasi pideva integratsiooni (CI) teenuste juurde. Neisse saab ilma tõsiste probleemideta rakendada mis tahes analüsaatorit. Selleks peate torujuhtmesse looma eraldi etapi, mis tavaliselt asub pärast ehitus- ja sõlmekatsetusi. Seda tehakse erinevate konsooli utiliitide abil. Näiteks pakub PVS-Studio järgmisi utiliite:
- (lahenduste analüüs, C#, C++ projektid Windowsis)
- (koostamise jälgimine)
- (C++ projektide analüüs Linuxis / macOS-is)
- (lahenduse analüüs, C# projektid Linuxis / macOS-is)
- (Java projektide analüüs)
- (aruandefaili teisendaja)
Analüüsi integreerimiseks CI-sse peate tegema kolme asja.
- Paigaldage analüsaator;
- Käivitage analüüs;
- Esitage tulemusi.
Näiteks PVS-Studio installimiseks Linuxile (Debian-base), peate käivitama 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-studioWindowsiga süsteemides ei saa analüsaatorit paketihaldurist installida, kuid analüsaatorit on võimalik juurutada käsurealt:
PVS-Studio_setup.exe /verysilent /suppressmsgboxes
/norestart /nocloseapplicationsLisateavet PVS-Studio juurutamise kohta Windowsi kasutavates süsteemides saate lugeda **.
Pärast installimist peate analüüsi otse käivitama. Siiski on soovitatav seda teha alles pärast koostamise ja testide läbimist. Seda seetõttu, et staatiline analüüs võtab tavaliselt kaks korda kauem aega kui kompileerimine.
Kuna käivitamismeetod sõltub platvormist ja projekti funktsioonidest, näitan näitena C++ (Linux) valikut:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
plog-converter -t errorfile PVS-Studio.log --cerr -wEsimene käsk teostab analüüsi ja teine teisendab aruande tekstivormingusse, kuvab selle ekraanil ja tagastab hoiatuste korral muu tagastuskoodi kui 0. Sellist mehhanismi saab veateadete korral mugavalt kasutada ehituse blokeerimiseks. Kuid võite alati lipu eemaldada -w ja ärge blokeerige koostu, mis sisaldab hoiatusi.
Märkus. Tekstivorming on ebamugav. See on esitatud lihtsalt näitena. Pöörake tähelepanu huvitavamale aruandevormingule - FullHtml. See võimaldab teil koodis navigeerida.
Lisateavet CI analüüsi seadistamise kohta saate lugeda artiklist "" (Windows) või "" (Linux).
Olgu, olete koostamisserveris analüsaatori konfigureerinud. Nüüd, kui keegi laadis üles testimata koodi, siis kinnitusetapp nurjub ja saate probleemi tuvastada, kuid see pole päris mugav, kuna projekti on tõhusam kontrollida mitte pärast filiaalide ühendamist, vaid enne seda, tõmbamistaotluse etapis. A.
Üldiselt ei erine tõmbamispäringu analüüsi seadistamine palju tavapärasest CI analüüsi käivitamisest. Välja arvatud vajadus saada muudetud failide loend. Neid saab tavaliselt saada, kui küsite git abil filiaalide erinevusi:
git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.listNüüd peate selle failide loendi analüsaatorile sisendiks edastama. Näiteks PVS-Studio's rakendatakse seda lipu abil -S:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
-S .pvs-pr.listLisateavet tõmbetaotluste analüüsimise kohta leiate **. Isegi kui teie CI ei ole artiklis mainitud teenuste loendis, on seda tüüpi analüüsi teooriale pühendatud üldosa kasulik.
Tõmbepäringute analüüsi seadistamisega saate blokeerida hoiatusi sisaldavad sissekanded, luues seeläbi piiri, mida testimata kood ei ületa.
See kõik on kindlasti hea, kuid ma tahaksin näha kõiki hoiatusi ühes kohas. Mitte ainult staatilisest analüsaatorist, vaid ka ühiktestidest või dünaamilisest analüsaatorist. Selleks on erinevaid teenuseid ja pistikprogramme. Näiteks PVS-Stuudios on .
2. Integreerimine arendaja masinatel
Nüüd on aeg paigaldada ja seadistada analüsaator igapäevaseks arenduskasutuseks. Selleks hetkeks olete enamiku tööviisidega juba tuttavaks saanud, nii et seda võib nimetada kõige lihtsamaks osaks.
Lihtsaima võimalusena saavad arendajad vajaliku analüsaatori ise installida. See võtab aga palju aega ja tõmbab nende tähelepanu arendusest kõrvale, nii et saate selle protsessi automatiseerida, kasutades installerit ja vajalikke lippe. PVS-Stuudio jaoks on erinevaid . Siiski on alati olemas paketihaldurid, näiteks Chocolatey (Windows), Homebrew (macOS) või kümned valikud Linuxi jaoks.
Seejärel peate installima vajalikud pistikprogrammid, näiteks jaoks , , ja nii edasi
3. Igapäevane kasutamine
Selles etapis on aeg öelda paar sõna selle kohta, kuidas analüsaatorit igapäevasel kasutamisel kiirendada. Kogu projekti täielik analüüs võtab palju aega, kuid kui sageli muudame korraga kogu projekti koodi? Vaevalt leidub nii suurt ümbertegemist, et see mõjutaks kohe kogu koodibaasi. Korraga muudetavate failide arv ületab harva tosinat, seega on mõttekas neid analüüsida. Sellise olukorra jaoks on olemas . Ärge kartke, see pole veel üks tööriist. See on erirežiim, mis võimaldab analüüsida ainult muudetud faile ja nende sõltuvusi ning see juhtub automaatselt pärast ehitamist, kui töötate IDE-s, mille pistikprogramm on installitud.
Kui analüsaator tuvastab hiljuti muudetud koodis probleeme, teatab ta sellest iseseisvalt. Näiteks PVS-Studio räägib teile sellest hoiatuse abil:
Loomulikult ei piisa sellest, kui öelda arendajatele tööriista kasutada. Peame neile kuidagi ütlema, mis see on ja kuidas see on. Siin on näiteks artikleid PVS-Studio kiire käivitamise kohta, kuid sarnaseid õpetusi leiate iga teie eelistatud tööriista jaoks.
Sellised artiklid annavad kogu igapäevaseks kasutamiseks vajaliku teabe ega võta palju aega. 🙂
Isegi tööriista tundmaõppimise etapis tõrjusime ühe esimese käivitamise ajal palju hoiatusi. Kahjuks pole staatilised analüsaatorid täiuslikud, nii et aeg-ajalt annavad nad valepositiivseid tulemusi. Tavaliselt on neid lihtne maha suruda; näiteks Visual Studio PVS-Studio pistikprogrammis peate lihtsalt klõpsama ühte nuppu:
Siiski saate teha rohkem kui lihtsalt neid maha suruda. Näiteks saate tugiteenusele teatada probleemist. Kui valepositiivsust saab parandada, võite tulevastes värskendustes märgata, et iga kord jääb teie koodibaasi spetsiifilisi valepositiivseid tulemusi aina vähem.
Pärast integreerimist
Seega oleme läbinud kõik staatilise analüüsi arendusprotsessi integreerimise etapid. Hoolimata selliste tööriistade seadistamise tähtsusest CI-s, on nende käitamiseks kõige olulisem koht arendaja arvutis. Staatiline analüsaator ei ole ju kohtunik, kes kuskil sinust eemal ütleb, et kood ei ole hea. Vastupidi, see on assistent, kes ütleb teile, kui olete väsinud, ja tuletab meelde, kui olete midagi unustanud.
Tõsi, ilma regulaarse kasutamiseta staatiline analüüs tõenäoliselt arendust oluliselt ei lihtsusta. Lõppude lõpuks ei seisne selle peamine eelis arendaja jaoks mitte niivõrd keerukate ja vastuoluliste koodiosade otsimises, vaid nende varajases tuvastamises. Nõus, et probleemi avastamine pärast toimetuste testimiseks saatmist pole mitte ainult ebameeldiv, vaid ka väga aeganõudev. Regulaarsel kasutamisel vaatab staatiline analüüs iga muudatust otse teie arvutis ja annab koodi kallal töötades teada kahtlastest kohtadest.
Ja kui teie või teie kolleegid pole ikka veel kindlad, kas analüsaatorit tasub rakendada, soovitan teil nüüd artiklit lugema hakata "See käsitleb arendajate tüüpilisi muresid, et staatiline analüüs võtab neil aega ja nii edasi.
Kui soovite seda artiklit inglise keelt kõneleva publikuga jagada, kasutage tõlkelinki: Maxim Zvjagintsev. .
Allikas: www.habr.com