It is maklik om in statyske koadeanalysator te besykjen. Mar om it út te fieren, benammen yn 'e ûntwikkeling fan in grut âld projekt, fereasket feardigens. As ferkeard dien, kin de analysator wurk tafoegje, ûntwikkeling fertrage en it team demotivearje. Litte wy koart prate oer hoe't jo de yntegraasje fan statyske analyse goed kinne benaderje yn it ûntwikkelingsproses en it begjinne te brûken as ûnderdiel fan CI / CD.
Ynlieding
Koartlyn waard myn oandacht lutsen op de publikaasje "". Oan 'e iene kant is dit in goed artikel dat it wurdich is om yn 'e kunde te kommen. Oan 'e oare kant liket it my dat it noch altyd gjin folslein antwurd jout oer hoe't jo statyske analyze pynlik útfiere kinne yn in projekt mei in protte fan legacy koade It artikel seit dat Jo kinne akseptearje technyske skulden en wurkje allinnich op nije koade, mar der is gjin antwurd op wat te dwaan mei dizze technyske skuld letter.
Us PVS-Studio-team biedt syn sicht op dit ûnderwerp. Litte wy sjen hoe't it probleem fan 'e ymplemintaasje fan in statyske koade-analyzer op it earste plak ûntstiet, hoe't dit probleem te oerwinnen, en hoe't jo technyske skuld stadichoan kinne eliminearje.
Issues
It is normaal net lestich om te lansearjen en te sjen hoe't in statyske analysator wurket []. Jo kinne miskien nijsgjirrige flaters sjen as sels skriklike potensjele kwetsberens yn 'e koade. Jo kinne sels wat reparearje, mar dan jouwe in protte programmeurs op.
Alle statyske analysatoren produsearje falske positiven. Dit is in skaaimerk fan 'e metodyk foar statyske koade-analyse, en der kin neat oan dien wurde. Yn it algemiene gefal is dit in ûnoplosber probleem, lykas befêstige troch Rice's stelling []. Masine-learalgoritmen sille ek net helpe []. Sels as in persoan net altyd kin fertelle oft dizze of dy koade ferkeard is, dan moatte jo dit net ferwachtsje fan it programma :).
Falske positiven binne gjin probleem as de statyske analysator al konfigureare is:
- Utskeakele irrelevante regel sets;
- Guon irrelevante diagnoaze binne útskeakele;
- As wy it oer C of C++ hawwe, dan wurde makro's markearre dy't spesifike konstruksjes befetsje dy't feroarsaakje dat nutteleaze warskôgings ferskine op elk plak dêr't sokke makro's brûkt wurde;
- Eigen funksjes wurde markearre dy't aksjes útfiere dy't fergelykber binne mei systeemfunksjes (syn eigen analoog memcpy of printf) [];
- False positives wurde spesifyk útskeakele mei help fan opmerkingen;
- En sa op.
Yn dit gefal kinne wy in leech falsk positive taryf ferwachtsje fan sawat 10-15% []. Mei oare wurden, 9 fan 'e 10 warskôgings foar analysator sille in wirklik probleem yn' e koade oanjaan, of op syn minst "sterk-ruikende koade." Iens, dit senario is ekstreem noflik, en de analysator is in echte freon fan 'e programmeur.
Yn 'e realiteit, yn in grut projekt, sil it earste byld folslein oars wêze. De analysator jout hûnderten as tûzenen warskôgingen foar legacy koade. It is ûnmooglik om fluch te begripen hokker fan dizze warskôgings relevant binne en hokker net. It is irrational om te sitten en te begjinnen mei al dizze warskôgingen, om't it wichtichste wurk yn dit gefal dagen of wiken sil stopje. Typysk kin in team sa'n senario net betelje. D'r sille ek in enoarm oantal ferskillen wêze dy't de feroaringsskiednis bedjerre. En rappe massabewurking fan safolle fragminten yn 'e koade sil ûnûntkomber resultearje yn nije typfouten en flaters.
En it wichtichste is dat sa'n prestaasje yn 'e striid tsjin warskôgings net folle sin hat. It iens dat sûnt it projekt in protte jierren mei súkses rint, de measte fan 'e krityske flaters dêryn al korrizjearre binne. Ja, dizze reparaasjes wiene heul djoer, moasten debuggen wurde, krigen negative brûkersfeedback oer bugs, ensfh. In statyske analysator soe helpe om in protte fan dizze flaters te reparearjen by it kodearjen, fluch en goedkeap. Mar op it stuit, op ien of oare manier, binne dizze flaters reparearre, en de analyzer fynt benammen net-krityske flaters yn 'e âlde koade. Dizze koade kin net brûkt wurde, it kin heul selden brûkt wurde, en in flater dêryn kin net liede ta merkbere gefolgen. Miskien earne is it skaad fan 'e knop de ferkearde kleur, mar dit bemuoit gjinien mei it gebrûk fan it produkt.
Fansels binne sels lytse flaters noch flaters. En soms kin in flater in echte kwetsberens ferbergje. Alles opjaan en dagen/wiken omgean mei gebreken dy't har amper manifestearje, liket lykwols in dubieuze idee.
Programmeurs sjogge, sjoch, sjoch nei al dizze warskôgingen oer de âlde wurkkoade... En se tinke: wy kinne sûnder statyske analyze. Litte wy wat nije nuttige funksjonaliteit skriuwe.
Op har eigen wize hawwe se gelyk. Se betinke dat se earst al dizze warskôgings op ien of oare manier kwyt moatte. Allinnich dan kinne se profitearje fan regelmjittich gebrûk fan 'e koadeanalysator. Oars, nije warskôgings sille gewoan ferdrinke yn âlde, en gjinien sil betelje omtinken oan harren.
Dit is deselde analogy as mei kompilator warskôgingen. It is net sûnder reden dat se riede it oantal kompilator warskôgingen op 0. As der 1000 warskôgings binne, dan as d'r 1001 binne, sil gjinien omtinken jaan oan it, en it is net dúdlik wêr't jo moatte sykje nei dizze nijste warskôging.
It slimste yn dit ferhaal is as immen fan boppen jo op dit stuit twingt om statyske koade-analyze te brûken. Dit sil it team allinich demotivearje, om't d'r út har eachpunt ekstra burokratyske kompleksiteit sil wêze dy't allinich yn 'e wei stiet. Nimmen sil nei de rapporten fan 'e analysator sjen, en alle gebrûk sil allinich "op papier" wêze. Dy. Formeel is analyze ynboud yn it DevOps-proses, mar yn 'e praktyk komt dit gjinien foar. Wy hearden detaillearre ferhalen by stands fan konferinsje dielnimmers. Sa'n ûnderfining kin programmeurs ûntmoedigje fan it brûken fan statyske analyse-ark foar in lange tiid, as net foar altyd.
It útfieren en eliminearjen fan technyske skuld
Yn feite is d'r neat dreech of skriklik oer it yntrodusearjen fan statyske analyse sels yn in grut âld projekt.
CI / CD
Boppedat kin de analysator fuortendaliks diel wurde makke fan it trochgeande ûntwikkelingsproses. Bygelyks, de PVS-Studio-distribúsje befettet nutsbedriuwen foar it maklik besjen fan it rapport yn it formaat dat jo nedich binne, en notifikaasjes foar ûntwikkelders dy't problematyske seksjes fan 'e koade skreaun hawwe. Foar dyjingen dy't mear ynteressearre binne yn it lansearjen fan PVS-Studio fan CI / CD-systemen, ried ik oan dat jo josels fertroud meitsje mei de oerienkommende dokumintaasje en in searje artikels:
Mar litte wy weromgean nei it probleem fan in grut oantal falske positiven yn 'e earste stadia fan it útfieren fan ark foar koade-analyze.
It reparearjen fan besteande technyske skuld en omgean mei nije warskôgings
Moderne kommersjele statyske analysatoren kinne jo allinich nije warskôgings studearje dy't ferskine yn nije as feroare koade. De útfiering fan dit meganisme ferskilt, mar de essinsje is itselde. Yn 'e statyske analysator PVS-Studio wurdt dizze funksjonaliteit as folget ymplementearre.
Om fluch te begjinnen mei it brûken fan statyske analyse, suggerearje wy dat PVS-Studio-brûkers it meganisme brûke foar massa-ûnderdrukking fan warskôgingen []. It algemiene idee is it folgjende. De brûker lansearre de analysator en krige in protte warskôgings. Sûnt in projekt dat al in protte jierren yn ûntwikkeling is libbet, ûntwikkelet en jild makket, dan sille d'r wierskynlik net in protte warskôgingen yn it rapport wêze dy't krityske defekten oanjaan. Mei oare wurden, krityske bugs binne al op ien of oare manier repareare mei djoerdere metoaden of troch feedback fan klanten. Dêrtroch kin alles wat de analysator op it stuit fynt, wurde beskôge as technyske skuld, wat ûnpraktysk is om te besykjen fuortendaliks te eliminearjen.
Jo kinne fertelle PVS-Studio in beskôgje dizze warskôgings irrelevant foar no (bewarje technyske skulden foar letter), en it sil net mear sjen litte se. De analysator makket in spesjale triem wêryn it ynformaasje opslaat oer flaters dy't noch net ynteressant binne. En no sil PVS-Studio warskôgingen allinich útjaan foar nije as feroare koade. Boppedat wurdt dit alles tûk útfierd. As bygelyks in lege rigel wurdt tafoege oan it begjin fan 'e boarnekoade-bestân, dan begrypt de analysator dat, yn feite, neat feroare is en sil bliuwe stil. Dit opmaakbestân kin yn in ferzjekontrôlesysteem pleatst wurde. It bestân is grut, mar dit is gjin probleem, om't it gjin punt hat om it faak te bewarjen.
No sille alle programmeurs warskôgings sjen dy't allinich relatearre binne oan nije of feroare koade. Sa kinne jo begjinne mei it brûken fan de analyzer, sa't se sizze, fan 'e oare deis. En jo kinne letter weromgean nei technyske skuld, en stadichoan korrigearje flaters en konfigurearje de analyzer.
Dat, it earste probleem mei de ymplemintaasje fan 'e analysator yn in grut âld projekt is oplost. No litte wy útfine wat te dwaan mei technyske skuld.
Bug fixes en refactorings
It ienfâldichste en meast natuerlike ding is om wat tiid ôf te setten om massaal ûnderdrukte warskôgings foar analysatoren te analysearjen en stadichoan mei har om te gean. Earne moatte jo flaters yn 'e koade reparearje, earne moatte jo refaktorearje om de analysator te fertellen dat de koade net problematysk is. Ienfâldich foarbyld:
if (a = b)De measte C++-kompilators en analysators kleie oer sa'n koade, om't d'r in hege kâns is dat se eins skriuwe woene (a == b). Mar d'r is in ûnútsprutsen oerienkomst, en dit wurdt normaal opmurken yn 'e dokumintaasje, dat as d'r ekstra heakjes binne, dan wurdt beskôge dat de programmeur sa'n koade mei opsetsin skreau, en d'r is net nedich om te swarjen. Bygelyks, yn de PVS-Studio dokumintaasje foar diagnostyk it is dúdlik skreaun dat de folgjende rigel as korrekt en feilich beskôge wurdt:
if ((a = b))In oar foarbyld. Is it fergetten yn dizze C ++ koade? brekke of net?
case A:
foo();
case B:
bar();
break;De PVS-Studio-analyzer sil hjir in warskôging jaan . Dit kin gjin flater wêze, yn dat gefal moatte jo de parser in hint jaan troch it attribút ta te foegjen of bygelyks __attribút__((fallthrough)):
case A:
foo();
[[fallthrough]];
case B:
bar();
break;It kin sein wurde dat sokke koade feroarings net reparearje de brek. Ja, dit is wier, mar it docht twa nuttige dingen. As earste, it analysatorrapport makket falske positiven kwyt. Twadder wurdt de koade mear begryplik foar de minsken dy't belutsen binne by it ûnderhâld. En dit is tige wichtich! Hjirfoar allinich is it de muoite wurdich om lytse refactorings út te fieren om de koade dúdliker en makliker te ûnderhâlden te meitsjen. Sûnt de analysator net begrypt oft "brekke" nedich is of net, sil it ek ûndúdlik wêze foar kollega-programmeurs.
Neist bugfixes en refactorings, kinne jo spesifyk dúdlik falske analysator warskôgings ûnderdrukke. Guon irrelevante diagnoaze kinne wurde útskeakele. Bygelyks, immen tinkt warskôgings binne sinleas oer it fergelykjen fan float / dûbele wearden. En guon klassifisearje se as wichtich en weardich fan stúdzje []. Hokker warskôgings wurde beskôge as relevant en hokker net, is oan it ûntwikkelteam om te besluten.
D'r binne oare manieren om falske warskôgings te ûnderdrukken. Bygelyks, makro markup waard neamd earder. Dit alles wurdt beskreaun yn mear detail yn de dokumintaasje. It wichtichste is om te begripen dat as jo stadichoan en systematysk benaderje wurkjen mei falske positiven, d'r is neat mis mei har. De grutte mearderheid fan uninteressante warskôgings ferdwine nei konfiguraasje, en allinnich plakken dy't echt fereaskje soarchfâldige stúdzje en guon feroarings yn de koade bliuwe.
Ek helpe wy ús kliïnten altyd by it opsetten fan PVS-Studio as der swierrichheden ûntsteane. Boppedat wiene d'r gefallen dat wy sels falske warskôgings elimineare en flaters korrizjeare []. Foar it gefal, ik besleat om te neamen dat dizze opsje foar útwreide gearwurking ek mooglik is :).
Ratchet metoade
D'r is in oare nijsgjirrige oanpak om de koadekwaliteit stadichoan te ferbetterjen troch de warskôging foar statyske analysator te eliminearjen. De konklúzje is dat it tal warskôgings allinnich mar ôfnimme kin.
It oantal warskôgingen útjûn troch de statyske analysator wurdt opnommen. Kwaliteitspoarte is sa ynsteld dat jo no allinich in koade kinne ynfiere dy't it oantal operaasjes net ferheegje. As resultaat begjint it proses fan it stadichoan ferminderjen fan it oantal alaarms troch it oanpassen fan de analysator en it korrizjearjen fan flaters.
Sels as in persoan in bytsje cheat wol en beslút om de kwaliteitspoarte troch te jaan net troch warskôgingen yn syn nije koade te eliminearjen, mar troch de âlde koade fan tredden te ferbetterjen, is dit net eng. Dochs draait de ratchet yn ien rjochting, en stadichoan sil it oantal defekten ôfnimme. Sels as in persoan syn eigen nije gebreken net reparearje wol, sil hy noch wat ferbetterje moatte yn 'e oanbuorjende koade. Op in stuit einigje de maklike manieren om it oantal warskôgingen te ferminderjen, en d'r komt in punt dat echte bugs wurde reparearre.
Dizze metodyk wurdt yn mear detail beskreaun yn in tige nijsgjirrich artikel fan Ivan Ponomarev "", dy't ik advisearje te lêzen oan elkenien dy't ynteressearre is yn it ferbetterjen fan koadekwaliteit.
De skriuwer fan it artikel hat ek in rapport oer dit ûnderwerp: "".
konklúzje
Ik hoopje dat lêzers nei dit artikel mear akseptearje fan ark foar statyske analyse en se wolle ymplementearje yn it ûntwikkelingsproses. As jo fragen hawwe, binne wy altyd klear brûkers fan ús statyske analysator PVS-Studio en helpe by de ymplemintaasje dêrfan.
D'r binne oare typyske twifels oer de fraach oft statyske analyse echt handich en nuttich kin wêze. Ik besocht de measte fan dizze twifels te ferwiderjen yn 'e publikaasje "Redenen om de PVS-Studio statyske koadeanalysator yn te fieren yn it ûntwikkelingsproses" [].
Tank foar jo oandacht en kom en besykje de PVS-Studio analyzer.
Oanfoljende keppelings
- Andrey Karpov.
- Wikipedia. .
- Andrey Karpov, Victoria Khanieva. .
- PVS-Studio. Dokumintaasje. .
- Andrey Karpov. .
- PVS-Studio. Dokumintaasje. .
- Ivan Andryashin. .
- Pavel Eremeev, Svyatoslav Razmyslov. .
- Andrey Karpov. .
As jo dit artikel wolle diele mei in Ingelsktalig publyk, brûk dan de oersettingskeppeling: Andrey Karpov. .
Boarne: www.habr.com