Staatilise koodianalüsaatorit on lihtne proovida. Kuid selle elluviimine, eriti suure vana projekti väljatöötamisel, nõuab oskusi. Kui seda teha valesti, võib analüsaator lisada tööd, aeglustada arengut ja demotiveerida meeskonda. Räägime lühidalt sellest, kuidas õigesti läheneda staatilise analüüsi integreerimisele arendusprotsessi ja hakata seda kasutama CI/CD osana.
Sissejuhatus
Hiljuti juhtis minu tähelepanu väljaanne "". Ühest küljest on see hea artikkel, millega tasub tutvuda. Teisest küljest tundub mulle, et see ei anna siiski täielikku vastust, kuidas staatilist analüüsi valutult ellu viia projektis, kus on palju Artiklis öeldakse, et saate tehnilise võlaga vastu võtta ja töötada ainult uue koodi kallal, kuid pole vastust, mida selle tehnilise võlaga hiljem teha.
Meie PVS-Stuudio meeskond pakub sellel teemal oma vaadet. Vaatame, kuidas staatilise koodianalüsaatori juurutamise probleem üldse tekib, kuidas sellest probleemist üle saada ja kuidas tehnilist võlga valutult järk-järgult likvideerida.
Probleemid
Tavaliselt pole staatilise analüsaatori käivitamine ja töötamise vaatamine keeruline []. Võite koodis näha huvitavaid vigu või isegi hirmutavaid potentsiaalseid turvaauke. Võite isegi midagi parandada, kuid siis loobuvad paljud programmeerijad.
Kõik staatilised analüsaatorid annavad valepositiivseid tulemusi. See on staatilise koodi analüüsi metoodika omadus ja sellega ei saa midagi ette võtta. Üldjuhul on see lahendamatu probleem, nagu kinnitab Rice'i teoreem []. Ei aita ka masinõppe algoritmid []. Isegi kui inimene ei saa alati öelda, kas see või teine kood on vale, ei tohiks te seda programmilt oodata :).
Valepositiivsed tulemused ei ole probleem, kui staatiline analüsaator on juba konfigureeritud:
- Keelatud ebaolulised reeglikomplektid;
- Mõned ebaolulised diagnostikad on keelatud;
- Kui me räägime C-st või C++-st, siis märgitakse makrod, mis sisaldavad konkreetseid konstruktsioone, mis põhjustavad asjatute hoiatuste ilmumist igasse kohta, kus selliseid makrosid kasutatakse;
- Märgistatud on oma funktsioonid, mis täidavad süsteemi funktsioonidega sarnaseid toiminguid (oma analoog mäletatav või printf) [];
- Valepositiivsed on spetsiaalselt keelatud kommentaaride abil;
- Ja nii edasi.
Sel juhul võime oodata madalat valepositiivsuse määra, umbes 10–15% []. Teisisõnu, 9 analüsaatori hoiatust kümnest viitavad tõelisele probleemile koodis või vähemalt "tugevalt lõhnavale koodile". Nõus, see stsenaarium on äärmiselt meeldiv ja analüsaator on programmeerija tõeline sõber.
Tegelikkuses on suure projekti puhul esialgne pilt hoopis teine. Analüsaator annab pärandkoodi kohta sadu või tuhandeid hoiatusi. On võimatu kiiresti aru saada, millised neist hoiatustest on asjakohased ja millised mitte. On ebaratsionaalne istuda maha ja hakata kõigi nende hoiatustega tegelema, kuna põhitöö peatub sel juhul päevadeks või nädalateks. Tavaliselt ei saa meeskond endale sellist stsenaariumi lubada. Samuti tuleb tohutult palju erinevusi, mis rikuvad muutuste ajalugu. Ja nii paljude koodi fragmentide kiire massiline redigeerimine toob paratamatult kaasa uusi kirjavigu ja vigu.
Ja mis kõige tähtsam, sellisel vägitükil hoiatuste vastu võitlemisel on vähe mõtet. Nõustuge sellega, et kuna projekt on aastaid edukalt toiminud, on enamik kriitilisi vigu selles juba parandatud. Jah, need parandused olid väga kallid, neid tuli siluda, said vigade kohta negatiivset tagasisidet jne. Staatiline analüsaator aitaks paljusid neist vigadest kodeerimisetapis kiiresti ja odavalt parandada. Aga hetkel on nii või teisiti need vead parandatud ja analüsaator tuvastab peamiselt mittekriitilised vead vanas koodis. Seda koodi ei pruugita kasutada, seda võidakse kasutada väga harva ja selles sisalduv viga ei pruugi kaasa tuua märgatavaid tagajärgi. Võib-olla on kuskil nupu vari valet värvi, kuid see ei sega kellelgi toote kasutamist.
Muidugi on ka pisivead ikkagi vead. Ja mõnikord võib viga varjata tõelist haavatavust. Kõigest loobumine ja päevade/nädalate vaevu avalduvate defektidega tegelemine tundub aga kahtlase ideena.
Programmeerijad vaatavad, vaatavad, vaatavad kõiki neid hoiatusi vana töökoodi kohta... Ja mõtlevad: saame hakkama ka ilma staatilise analüüsita. Kirjutame mõned uued kasulikud funktsioonid.
Omal moel on neil õigus. Nad arvavad, et kõigepealt peavad nad kõigist hoiatustest kuidagi lahti saama. Alles siis saavad nad koodianalüsaatori regulaarsest kasutamisest kasu. Vastasel juhul upuvad uued hoiatused lihtsalt vanadesse ja keegi ei pööra neile tähelepanu.
See on sama analoogia mis kompilaatori hoiatustega. Mitte ilmaasjata ei soovita nad kompilaatori hoiatuste arvu hoida 0. Kui hoiatusi on 1000, siis kui neid on 1001, ei pööra sellele keegi tähelepanu ja pole selge, kust seda uusimat hoiatust otsida.
Kõige hullem selle loo juures on see, kui keegi ülaltpoolt antud hetkel sunnib kasutama staatilist koodianalüüsi. See ainult demotiveerib meeskonda, kuna nende seisukohast tekib täiendav bürokraatlik keerukus, mis ainult segab. Keegi ei vaata analüsaatori aruandeid ja kogu kasutus toimub ainult "paberil". Need. Formaalselt on analüüs DevOpsi protsessi sisse ehitatud, kuid praktikas ei too see kellelegi kasu. Kuulsime konverentsil osalejatelt kabiinides üksikasjalikke lugusid. Selline kogemus võib heidutada programmeerijaid staatilise analüüsi tööriistu kasutamast pikka aega, kui mitte igaveseks.
Tehnilise võla rakendamine ja kõrvaldamine
Tegelikult pole staatilise analüüsi sisseviimises isegi vanasse suurde projekti midagi rasket ega hirmutavat.
CI / CD
Lisaks saab analüsaatori koheselt osaks pidevast arendusprotsessist. Näiteks sisaldab PVS-Studio distributsioon utiliite aruande mugavaks vaatamiseks vajalikus vormingus ja teatisi arendajatele, kes kirjutasid koodi probleemseid jaotisi. Neil, kes on huvitatud PVS-Studio käivitamisest CI/CD süsteemidest, soovitan tutvuda vastavate dokumentatsioon ja rida artikleid:
Kuid pöördume tagasi suure arvu valepositiivsete tulemuste juurde koodianalüüsi tööriistade rakendamise esimestes etappides.
Olemasoleva tehnilise võla parandamine ja uute hoiatustega tegelemine
Kaasaegsed kaubanduslikud staatilised analüsaatorid võimaldavad teil uurida ainult uusi hoiatusi, mis ilmuvad uues või muudetud koodis. Selle mehhanismi rakendamine on erinev, kuid olemus on sama. PVS-Studio staatilises analüsaatoris on see funktsioon rakendatud järgmiselt.
Staatilise analüüsi kiireks alustamiseks soovitame PVS-Studio kasutajatel kasutada hoiatuste massilise mahasurumise mehhanismi []. Üldine idee on järgmine. Kasutaja käivitas analüsaatori ja sai palju hoiatusi. Kuna aastaid arenduses olnud projekt on elus, areneb ja raha teenib, siis suure tõenäosusega ei tule aruandesse palju kriitilistele defektidele viitavaid hoiatusi. Ehk siis kriitilised vead on nii või teisiti kallimate meetoditega või tänu klientide tagasisidele juba parandatud. Sellest tulenevalt võib kõike, mida analüsaator praegu leiab, pidada tehniliseks võlaks, mida pole otstarbekas kohe kõrvaldada.
Võite öelda, et PVS-Studio peab neid hoiatusi praegu ebaolulisteks (salvestage tehniline võlg hilisemaks ajaks) ja see ei näita neid enam. Analüsaator loob spetsiaalse faili, kuhu salvestab info vigade kohta, mis veel ei huvita. Ja nüüd annab PVS-Studio hoiatusi ainult uue või muudetud koodi puhul. Pealegi on see kõik nutikalt ellu viidud. Kui näiteks lähtekoodifaili algusesse lisada tühi rida, saab analüsaator aru, et tegelikult pole midagi muutunud ja vaikib edasi. Selle märgistusfaili saab panna versioonihaldussüsteemi. Fail on suur, kuid see pole probleem, kuna seda pole mõtet sageli salvestada.
Nüüd näevad kõik programmeerijad hoiatusi, mis on seotud ainult uue või muudetud koodiga. Seega saate analüsaatorit kasutama hakata, nagu öeldakse, järgmisest päevast. Ja hiljem saate naasta tehnilise võla juurde ning järk-järgult parandada vigu ja seadistada analüsaatorit.
Niisiis, esimene probleem analüsaatori rakendamisega suures vanas projektis on lahendatud. Nüüd mõtleme välja, mida teha tehnilise võlaga.
Veaparandused ja ümbertegemised
Kõige lihtsam ja loomulikum on varuda aega massiliselt alla surutud analüsaatori hoiatuste analüüsimiseks ja nendega järk-järgult tegeleda. Kusagil tuleks parandada vead koodis, kuskil tuleks refaktoreerida, et analüsaatorile öelda, et kood pole probleemne. Lihtne näide:
if (a = b)Enamik C++ kompilaatoreid ja analüsaatoreid kaebavad sellise koodi üle, kuna on suur tõenäosus, et nad tõesti tahtsid kirjutada (a == b). Kuid on olemas ütlemata kokkulepe ja see on tavaliselt dokumentatsioonis märgitud, et kui on täiendavaid sulgureid, siis arvatakse, et programmeerija kirjutas sellise koodi teadlikult ja pole vaja vanduda. Näiteks diagnostika PVS-studio dokumentatsioonis on selgelt kirjutatud, et järgmist rida peetakse õigeks ja ohutuks:
if ((a = b))Veel üks näide. Kas see on selles C++ koodis unustatud? murdma või mitte?
case A:
foo();
case B:
bar();
break;PVS-Studio analüsaator annab siin hoiatuse . See ei pruugi olla viga ja sel juhul peaksite parserile atribuudi lisamisega vihje andma või näiteks __atribuut__((läbiminek)):
case A:
foo();
[[fallthrough]];
case B:
bar();
break;Võib öelda, et sellised koodimuudatused viga ei paranda. Jah, see on tõsi, kuid see teeb kaks kasulikku asja. Esiteks vabaneb analüsaatori aruanne valepositiivsetest tulemustest. Teiseks muutub kood selle hooldamisega seotud inimestele arusaadavamaks. Ja see on väga oluline! Ainuüksi selle jaoks tasub teha väiksemaid ümbertöötlusi, et muuta kood selgemaks ja hõlpsamini hooldatavaks. Kuna analüsaator ei saa aru, kas "break" on vajalik või mitte, jääb see ka kaasprogrammeerijatele arusaamatuks.
Lisaks veaparandustele ja ümbertegemisele saate konkreetselt alla suruda ilmselgelt valed analüsaatori hoiatused. Mõned ebaolulised diagnostikad saab keelata. Näiteks keegi arvab, et hoiatused on mõttetud ujuv-/topeltväärtuste võrdlemise kohta. Ja mõned liigitavad need oluliseks ja uurimist väärivaks []. Milliseid hoiatusi peetakse asjakohaseks ja milliseid mitte, otsustab arendusmeeskond.
Valehoiatuste mahasurumiseks on ka teisi viise. Näiteks makromärgistust mainiti varem. Kõike seda kirjeldatakse üksikasjalikumalt dokumentatsioonis. Kõige tähtsam on mõista, et kui läheneda järk-järgult ja süstemaatiliselt valepositiividega töötamisele, pole neil midagi halba. Valdav enamus ebahuvitavatest hoiatustest kaob pärast seadistamist ja alles jäävad vaid need kohad, mis tõesti nõuavad hoolikat uurimist ja mõningaid muudatusi koodis.
Samuti aitame alati oma kliente PVS-Stuudio seadistamisel raskuste ilmnemisel. Pealegi oli juhtumeid, kui me ise kõrvaldasime valehoiatused ja parandasime vead []. Otsustasin igaks juhuks mainida, et ka see võimalus pikemaks koostööks on võimalik :).
Ratchet meetod
Koodi kvaliteedi järkjärguliseks parandamiseks on veel üks huvitav lähenemisviis, kõrvaldades staatilise analüsaatori hoiatuse. Põhimõte on see, et hoiatuste arv saab ainult väheneda.
Staatilise analüsaatori poolt antud hoiatuste arv registreeritakse. Kvaliteedivärav on konfigureeritud nii, et nüüd saab sisestada vaid koodi, mis ei suurenda toimingute arvu. Selle tulemusena algab häirete arvu järkjärgulise vähendamise protsess analüsaatori reguleerimisest ja vigade parandamisest.
Isegi kui inimene soovib veidi petta ja otsustab kvaliteediväravast läbida mitte oma uues koodis hoiatusi kaotades, vaid vana kolmanda osapoole koodi täiustades, pole see hirmutav. Siiski pöörleb põrk ühes suunas ja järk-järgult väheneb defektide arv. Isegi kui inimene ei taha ise oma uusi defekte parandada, peab ta ikkagi naaberkoodis midagi parandama. Ühel hetkel lõpevad lihtsad viisid hoiatuste arvu vähendamiseks ja saabub hetk, mil tõelised vead parandatakse.
Seda metoodikat kirjeldatakse üksikasjalikumalt Ivan Ponomarjovi väga huvitavas artiklis "", mida soovitan lugeda kõigil, kes on huvitatud koodikvaliteedi parandamisest.
Artikli autoril on sellel teemal ka aruanne: "".
Järeldus
Loodan, et pärast seda artiklit aktsepteerivad lugejad staatilise analüüsi tööriistu ja soovivad neid arendusprotsessis rakendada. Kui teil on küsimusi, oleme alati valmis meie staatilise analüsaatori PVS-Studio kasutajad ja abi selle juurutamisel.
On ka teisi tüüpilisi kahtlusi, kas staatiline analüüs võib tõesti olla mugav ja kasulik. Proovisin hajutada väljaandes enamiku neist kahtlustest „põhjused, miks tutvustada PVS-studio staatilist koodi analüsaatorit arendusprotsessi” [].
Tänan tähelepanu eest ja tule ja proovige PVS-Studio analüsaatorit.
Täiendavad lingid
- Andrei Karpov.
- Wikipedia. .
- Andrei Karpov, Victoria Khanieva. .
- PVS-Stuudio. Dokumentatsioon. .
- Andrei Karpov. .
- PVS-Stuudio. Dokumentatsioon. .
- Ivan Andrjašin. .
- Pavel Eremejev, Svjatoslav Razmõslov. .
- Andrei Karpov. .
Kui soovite seda artiklit inglise keelt kõneleva publikuga jagada, kasutage tõlkelinki: Andrey Karpov. .
Allikas: www.habr.com