Nesunku išbandyti statinio kodo analizatorių. Tačiau norint jį įgyvendinti, ypač kuriant didelį seną projektą, reikia įgūdžių. Jei atlikta neteisingai, analizatorius gali pridėti darbo, sulėtinti vystymąsi ir demotyvuoti komandą. Trumpai pakalbėkime apie tai, kaip tinkamai priartėti prie statinės analizės integravimo į kūrimo procesą ir pradėti ją naudoti kaip CI/CD dalį.
įvedimas
Neseniai mano dėmesį patraukė leidinys "". Viena vertus, tai geras straipsnis, su kuriuo verta susipažinti. Kita vertus, man atrodo, kad jis vis dar nepateikia išsamaus atsakymo, kaip neskausmingai įgyvendinti statinę analizę projekte, kuriame daug Straipsnyje rašoma, kad galite priimti techninę skolą ir dirbti tik su nauju kodu, tačiau nėra atsakymo, ką daryti su šia technine skola vėliau.
Mūsų PVS-Studio komanda siūlo savo nuomonę šia tema. Pažiūrėkime, kaip pirmiausia iškyla statinio kodo analizatoriaus diegimo problema, kaip šią problemą įveikti ir kaip neskausmingai palaipsniui panaikinti techninę skolą.
Problemos
Paprastai nėra sunku paleisti ir pamatyti, kaip veikia statinis analizatorius []. Kode galite pamatyti įdomių klaidų ar net baisių galimų spragų. Jūs netgi galite kažką pataisyti, bet tada daugelis programuotojų pasiduoda.
Visi statiniai analizatoriai pateikia klaidingus teigiamus rezultatus. Tai yra statinio kodo analizės metodologijos bruožas, ir nieko negalima padaryti. Bendruoju atveju tai yra neišsprendžiama problema, kaip patvirtina Rice'o teorema []. Mašininio mokymosi algoritmai taip pat nepadės []. Net jei žmogus ne visada gali pasakyti, ar tas ar kitas kodas yra neteisingas, neturėtumėte to tikėtis iš programos :).
Klaidingi teigiami rezultatai nėra problema, jei statinis analizatorius jau sukonfigūruotas:
- Išjungti nereikšmingi taisyklių rinkiniai;
- Kai kurios nereikšmingos diagnostikos buvo išjungtos;
- Jeigu mes kalbame apie C arba C++, tada yra pažymėtos makrokomandos, kuriose yra specifinių konstrukcijų, dėl kurių kiekvienoje vietoje, kur naudojamos tokios makrokomandos, atsiranda nenaudingi įspėjimai;
- Žymimos savo funkcijos, kurios atlieka veiksmus, panašius į sistemos funkcijas (savo analogas prisiminęs arba printf) [];
- Klaidingi teigiami duomenys yra specialiai išjungti naudojant komentarus;
- Ir taip toliau.
Tokiu atveju galime tikėtis mažo klaidingo teigiamo rodiklio, apie 10–15 % []. Kitaip tariant, 9 iš 10 analizatoriaus įspėjimų nurodys tikrą kodo problemą arba bent jau „stipriai kvepiantį kodą“. Sutikite, šis scenarijus yra nepaprastai malonus, o analizatorius yra tikras programuotojo draugas.
Realiai dideliame projekte pradinis vaizdas bus visiškai kitoks. Analizatorius pateikia šimtus ar tūkstančius įspėjimų dėl senojo kodo. Neįmanoma greitai suprasti, kurie iš šių įspėjimų yra svarbūs, o kurie ne. Neracionalu susėsti ir pradėti tvarkytis su visais šiais įspėjimais, nes pagrindinis darbas šiuo atveju sustos dienomis ar savaitėmis. Paprastai komanda negali sau leisti tokio scenarijaus. Taip pat bus daugybė skirtumų, kurie sugadins pokyčių istoriją. Ir greitai masiškai redaguojant tiek daug kodo fragmentų neišvengiamai atsiras naujų rašybos klaidų ir klaidų.
Ir, svarbiausia, toks žygdarbis kovojant su įspėjimais neturi prasmės. Sutikite, kad kadangi projektas sėkmingai vykdomas daug metų, dauguma kritinių klaidų jame jau ištaisytos. Taip, šie pataisymai buvo labai brangūs, teko derinti, gauti neigiamų vartotojų atsiliepimų apie klaidas ir pan. Statinis analizatorius padėtų greitai ir pigiai ištaisyti daugelį šių klaidų kodavimo etape. Tačiau šiuo metu vienaip ar kitaip šios klaidos yra ištaisytos, o analizatorius daugiausia aptinka nekritines senojo kodo klaidas. Šis kodas gali būti nenaudojamas, gali būti naudojamas labai retai, o jame esanti klaida gali nesukelti pastebimų pasekmių. Galbūt kažkur šešėlis nuo mygtuko yra netinkamos spalvos, tačiau tai niekam netrukdo naudoti gaminio.
Žinoma, net ir nedidelės klaidos išlieka klaidomis. O kartais klaida gali slėpti tikrą pažeidžiamumą. Tačiau visko mesti ir dienas/savaites leisti sprendžiant vos pasireiškiančius defektus atrodo abejotina idėja.
Programuotojai žiūri, žiūri, žiūri į visus šiuos perspėjimus apie seną veikiantį kodą... Ir galvoja: galime apsieiti be statinės analizės. Parašykime keletą naujų naudingų funkcijų.
Savaip jie teisūs. Jie mano, kad pirmiausia jie turi kažkaip atsikratyti visų šių įspėjimų. Tik tada jie galės gauti naudos iš reguliaraus kodų analizatoriaus naudojimo. Priešingu atveju nauji įspėjimai tiesiog paskęs senuose, ir niekas į juos nekreips dėmesio.
Tai ta pati analogija kaip ir su kompiliatoriaus įspėjimais. Ne be reikalo jie rekomenduoja kompiliatoriaus įspėjimų skaičių laikyti ties 0. Jei įspėjimų yra 1000, tai kai bus 1001, niekas į tai nekreips dėmesio, o kur ieškoti šio naujausio įspėjimo – neaišku.
Blogiausia šioje istorijoje, jei kas nors iš aukščiau šiuo metu privers jus naudoti statinę kodo analizę. Tai tik demotyvuos komandą, nes jų požiūriu atsiras papildomas biurokratinis sudėtingumas, kuris tik trukdys. Niekas nežiūrės į analizatoriaus ataskaitas, o visas naudojimas bus tik „popieriuje“. Tie. Formaliai analizė yra įtraukta į „DevOps“ procesą, tačiau praktiškai tai niekam neduoda naudos. Išsamias konferencijos dalyvių istorijas išgirdome stenduose. Tokia patirtis gali atgrasyti programuotojus nuo statinės analizės įrankių naudojimo ilgam, jei ne visam laikui.
Techninės skolos įgyvendinimas ir pašalinimas
Tiesą sakant, nėra nieko sudėtingo ar baisaus įdiegti statinę analizę net dideliame sename projekte.
CI / CD
Be to, analizatorius gali būti nedelsiant įtrauktas į nuolatinio tobulinimo procesą. Pavyzdžiui, PVS-Studio paskirstyme yra paslaugų, leidžiančių patogiai peržiūrėti ataskaitą reikiamu formatu, ir pranešimus kūrėjams, kurie parašė problemines kodo dalis. Tiems, kurie labiau domisi PVS-Studio paleidimu iš CI/CD sistemų, rekomenduoju susipažinti su atitinkama informacija. dokumentus ir straipsnių seriją:
Tačiau grįžkime prie daugelio klaidingų teigiamų rezultatų pirmuosiuose kodo analizės įrankių diegimo etapuose.
Esamos techninės skolos taisymas ir naujų įspėjimų sprendimas
Šiuolaikiniai komerciniai statiniai analizatoriai leidžia ištirti tik naujus įspėjimus, kurie atsiranda naujame arba pakeistame kode. Šio mechanizmo įgyvendinimas skiriasi, tačiau esmė ta pati. PVS-Studio statiniame analizatoriuje ši funkcija įgyvendinama taip.
Norėdami greitai pradėti naudoti statinę analizę, siūlome PVS-Studio vartotojams naudoti masinio įspėjimų slopinimo mechanizmą []. Bendra idėja yra tokia. Vartotojas paleido analizatorių ir gavo daug įspėjimų. Kadangi daug metų kuriamas projektas gyvuoja, vystosi ir uždirba pinigus, greičiausiai ataskaitoje nebus daug įspėjimų, nurodančių esminius defektus. Kitaip tariant, kritinės klaidos vienaip ar kitaip jau buvo ištaisytos brangesniais metodais arba klientų atsiliepimų dėka. Atitinkamai, viskas, ką šiuo metu randa analizatorius, gali būti laikoma technine skola, kurią nepraktiška bandyti nedelsiant pašalinti.
Galite nurodyti PVS-Studio, kad šiuo metu šie įspėjimai būtų nesvarbūs (išsaugokite techninę skolą vėliau), ir ji daugiau jų neberodys. Analizatorius sukuria specialų failą, kuriame išsaugo informaciją apie klaidas, kurios dar neįdomios. O dabar PVS-Studio įspės tik apie naują ar pakeistą kodą. Be to, visa tai įgyvendinama sumaniai. Jei, pavyzdžiui, prie šaltinio kodo failo pradžios pridedama tuščia eilutė, analizatorius supranta, kad iš tikrųjų niekas nepasikeitė, ir toliau tylės. Šis žymėjimo failas gali būti įtrauktas į versijos valdymo sistemą. Failas yra didelis, tačiau tai nėra problema, nes nėra prasmės jį dažnai saugoti.
Dabar visi programuotojai matys įspėjimus, susijusius tik su nauju arba pakeistu kodu. Taigi, kaip sakoma, galite pradėti naudoti analizatorių nuo kitos dienos. O vėliau galėsite grįžti prie techninės skolos, palaipsniui taisyti klaidas bei konfigūruoti analizatorių.
Taigi, pirmoji problema, susijusi su analizatoriaus diegimu dideliame sename projekte, buvo išspręsta. Dabar išsiaiškinkime, ką daryti su technine skola.
Klaidų pataisymai ir pertvarkymai
Paprasčiausias ir natūraliausias dalykas yra skirti šiek tiek laiko masiškai nuslopintų analizatoriaus įspėjimų analizei ir palaipsniui su jais susidoroti. Kai kur reikėtų pataisyti kode klaidas, kai kur reikėtų pakartotinai pasakyti analizatoriui, kad kodas nėra problemiškas. Paprastas pavyzdys:
if (a = b)Dauguma C++ kompiliatorių ir analizatorių skundžiasi tokiu kodu, nes yra didelė tikimybė, kad jie iš tikrųjų norėjo parašyti (a == b). Bet yra neišsakytas susitarimas, ir tai dažniausiai pažymima dokumentacijoje, kad jei yra papildomų skliaustų, tada laikoma, kad programuotojas sąmoningai parašė tokį kodą, ir nereikia keiktis. Pavyzdžiui, PVS-Studio diagnostikos dokumentacijoje aiškiai parašyta, kad ši eilutė bus laikoma teisinga ir saugia:
if ((a = b))Kitas pavyzdys. Ar tai pamiršta šiame C++ kode? pertrauka ar ne?
case A:
foo();
case B:
bar();
break;PVS-Studio analizatorius čia paskelbs įspėjimą . Tai gali būti ne klaida. Tokiu atveju turėtumėte pateikti užuominą analizatoriui pridėdami atributą arba pvz __atributas__((kritimas)):
case A:
foo();
[[fallthrough]];
case B:
bar();
break;Galima sakyti, kad tokie kodo pakeitimai klaidos nepataiso. Taip, tai tiesa, bet tai daro du naudingus dalykus. Pirma, analizatoriaus ataskaita pašalina klaidingus teigiamus rezultatus. Antra, kodas tampa suprantamesnis žmonėms, dalyvaujantiems jį prižiūrint. Ir tai labai svarbu! Vien dėl to verta atlikti nedidelius pertvarkymus, kad kodas būtų aiškesnis ir lengviau prižiūrimas. Kadangi analizatorius nesupranta, reikia „pertraukos“, ar ne, tai bus neaišku ir kitiems programuotojams.
Be klaidų pataisymų ir pertvarkymų, galite specialiai nuslopinti akivaizdžiai klaidingus analizatoriaus įspėjimus. Kai kurios nereikšmingos diagnostikos funkcijos gali būti išjungtos. Pavyzdžiui, kažkas mano, kad įspėjimai yra beprasmiški apie plūduriuojančių / dvigubų verčių palyginimą. Ir kai kurie juos priskiria prie svarbių ir vertų tyrimo []. Kurie įspėjimai laikomi tinkamais, o kurie ne, sprendžia kūrėjų komanda.
Yra ir kitų būdų, kaip nuslopinti klaidingus įspėjimus. Pavyzdžiui, makrokomandos žymėjimas buvo paminėtas anksčiau. Visa tai išsamiau aprašyta dokumentacijoje. Svarbiausia suprasti, kad jei palaipsniui ir sistemingai dirbate su klaidingais teigiamais rezultatais, tai nieko blogo. Didžioji dauguma neįdomių įspėjimų po konfigūravimo išnyksta ir lieka tik tos vietos, kurias tikrai reikia atidžiai išstudijuoti ir kai kuriuos kodo pakeitimus.
Taip pat visada padedame savo klientams susikurti PVS-Studio iškilus sunkumams. Be to, buvo atvejų, kai mes patys pašalinome klaidingus įspėjimus ir ištaisėme klaidas []. Tik tuo atveju nusprendžiau paminėti, kad galimas ir toks pratęsto bendradarbiavimo variantas :).
Ratchet metodas
Yra dar vienas įdomus būdas palaipsniui gerinti kodo kokybę pašalinant statinį analizatoriaus įspėjimą. Esmė ta, kad įspėjimų skaičius gali tik mažėti.
Registruojamas statinio analizatoriaus įspėjimų skaičius. Kokybės vartai sukonfigūruoti taip, kad dabar galima įvesti tik kodą, kuris nepadidina operacijų skaičiaus. Dėl to aliarmų skaičiaus laipsniško mažinimo procesas prasideda nuo analizatoriaus reguliavimo ir klaidų taisymo.
Net jei žmogus nori šiek tiek apgauti ir nusprendžia peržengti kokybės vartus ne panaikindamas įspėjimus naujajame kode, o tobulindamas senąjį trečiosios šalies kodą, tai nėra baisu. Vis dėlto reketas sukasi viena kryptimi ir palaipsniui mažės defektų skaičius. Net jei žmogus nenori taisyti savo naujų defektų, jis vis tiek turės ką nors patobulinti kaimyniniame kode. Tam tikru momentu paprasti būdai sumažinti įspėjimų skaičių baigiasi ir ateina laikas, kai bus ištaisytos tikros klaidos.
Ši metodika išsamiau aprašyta labai įdomiame Ivano Ponomarevo straipsnyje "“, kurį rekomenduoju perskaityti visiems, besidomintiems kodo kokybės gerinimu.
Straipsnio autorius taip pat turi pranešimą šia tema: "".
išvada
Tikiuosi, kad po šio straipsnio skaitytojai labiau priims statinės analizės įrankius ir norės jas pritaikyti kūrimo procese. Jei turite klausimų, mes visada pasiruošę mūsų statinio analizatoriaus PVS-Studio naudotojai ir padėti jį įdiegti.
Yra ir kitų tipiškų abejonių, ar statinė analizė tikrai gali būti patogi ir naudinga. Daugumą šių abejonių pabandžiau išsklaidyti publikacijoje „Priežastys, dėl kurių PVS-Studio statinio kodo analizatoriaus įvedimas į kūrimo procesą“ [].
Ačiū už dėmesį ir ateik ir išbandykite PVS-Studio analizatorių.
Papildomos nuorodos
- Andrejus Karpovas.
- Vikipedija. .
- Andrejus Karpovas, Viktorija Khanieva. .
- PVS-studija. Dokumentacija. .
- Andrejus Karpovas. .
- PVS-studija. Dokumentacija. .
- Ivanas Andriašinas. .
- Pavelas Eremejevas, Svjatoslavas Razmyslovas. .
- Andrejus Karpovas. .
Jei norite pasidalinti šiuo straipsniu su angliškai kalbančia auditorija, naudokite vertimo nuorodą: Andrejus Karpovas. .
Šaltinis: www.habr.com