Erraza da kode analizatzaile estatiko bat probatzea. Baina gauzatzeko, batez ere proiektu zahar handi baten garapenean, trebetasuna behar da. Gaizki egiten bada, analizatzaileak lana gehi dezake, garapena moteldu eta taldea desmotibatu. Hitz egin dezagun laburki analisi estatikoa garapen-prozesuan txertatzeari eta nola hasi CI/CD-ren zati gisa erabiltzen.
Sarrera
Duela gutxi nire arreta argitalpenak erakarri zidan "". Alde batetik, ezagutzea merezi duen artikulu ona da. Bestetik, iruditzen zait oraindik ez duela erantzun osorik ematen analisi estatikoa min gabe inplementatu asko duen proiektu batean. artikuluak dio zor teknikoa onartu eta kode berriarekin bakarrik lan egin dezakezula, baina ez dago erantzunik gero zor tekniko honekin zer egin.
Gure PVS-Studio taldeak gai honi buruzko bere ikuspegia eskaintzen du. Ikus dezagun lehenik eta behin nola sortzen den kode-analizatzaile estatiko bat ezartzeko arazoa, nola gainditu arazo hori eta nola minik gabe zor teknikoa pixkanaka kentzen.
Gaiak
Normalean ez da zaila abiarazi eta aztertzaile estatiko bat nola funtzionatzen duen ikustea []. Akats interesgarriak edo ahultasun potentzial beldurgarriak ere ikus ditzakezu kodean. Zerbait konpondu ere egin dezakezu, baina gero programatzaile askok amore ematen dute.
Analizatzaile estatiko guztiek positibo faltsuak sortzen dituzte. Kode estatikoa aztertzeko metodologiaren ezaugarri bat da, eta ezin da horri buruz ezer egin. Kasu orokorrean, hau konpondu ezinezko problema da, Rice-ren teorema [XNUMX] berretsi duen bezala.]. Ikaskuntza automatikoko algoritmoek ere ez dute lagunduko []. Nahiz eta pertsona batek beti ezin esan kode hau edo hori gaizki dagoen ala ez, orduan ez zenuke hau programatik espero :).
Positibo faltsuak ez dira arazorik analizatzaile estatikoa dagoeneko konfiguratuta badago:
- Garrantzirik gabeko arau multzo desgaituta;
- Garrantzirik gabeko diagnostiko batzuk desgaitu egin dira;
- C edo C++-i buruz ari bagara, makroak erabiltzen diren leku guztietan alferrikako abisuak agertzea eragiten duten eraikuntza zehatzak dituzten makroak markatzen dira;
- Sistemaren funtzioen antzeko ekintzak egiten dituzten funtzio propioak markatzen dira (bere analogoa memcpy edo printf) [];
- Positibo faltsuak berariaz desgaitzen dira iruzkinak erabiliz;
- Eta abar.
Kasu honetan, % 10-15 inguruko positibo faltsu baxua espero dezakegu []. Beste era batera esanda, analizatzaileen 9etik 10 abisuek kodean benetako arazo bat adieraziko dute, edo gutxienez "usain handiko kodea". Ados, eszenatoki hau oso atsegina da, eta analizatzailea programatzailearen benetako laguna da.
Egia esan, proiektu handi batean, hasierako argazkia guztiz ezberdina izango da. Analizatzaileak ehunka edo milaka abisu ematen ditu ondare-koderako. Ezinezkoa da azkar ulertzea abisu hauetako zeintzuk diren garrantzitsuak eta zeintzuk ez. Irrazionala da eseri eta ohartarazpen horiei guztiei aurre egiten hastea, kasu honetan lan nagusia egun edo astez geldituko baita. Normalean, talde batek ezin du horrelako eszenatoki bat ordaindu. Aldaketen historia hondatzen duten desberdintasun ugari ere egongo dira. Eta kodearen hainbeste zatiren edizio masibo azkarrak akats eta akats berriak sortuko ditu ezinbestean.
Eta garrantzitsuena, abisuen aurkako borrokan halako balentriak zentzu gutxi dauka. Onartu proiektua urte askotan arrakastaz exekutatzen ari denez, bertan dauden akats larri gehienak zuzenduta daudela jada. Bai, konponketa hauek oso garestiak ziren, arazketa egin behar zuten, erabiltzaileen iritzi negatiboak jasotzen zituzten akatsei buruz, etab. Analizatzaile estatiko batek kodetze fasean akats horietako asko konpontzen lagunduko luke, azkar eta merke. Baina momentuz, nola edo hala, akats horiek konpondu dira, eta analizatzaileak, batez ere, akats ez-kritikoak detektatzen ditu kode zaharrean. Baliteke kode hau ez erabiltzea, oso gutxitan erabiltzea eta bertan akatsak ondorio nabarmenak ez ekartzea. Beharbada, nonbait botoiaren itzala kolore okerrekoa da, baina horrek ez du oztopatzen produktuaren erabileran.
Jakina, akats txikiak ere akatsak dira oraindik. Eta batzuetan akats batek benetako ahultasun bat ezkutatu dezake. Hala ere, dena uztea eta ia ageri ez diren akatsei aurre egiten egun/asteak ematea zalantzazko ideia dirudi.
Programatzaileek begiratu, begiratu, begiratu lan-kode zaharrari buruzko abisu horiek guztiak... Eta pentsatzen dute: azterketa estatikorik gabe egin dezakegu. Goazen funtzionalitate erabilgarri berri batzuk idaztera.
Euren erara, arrazoi dute. Lehenik eta behin abisu horiek guztiak nolabait kendu behar dituztela uste dute. Orduan bakarrik kode analizatzailearen ohiko erabileraz baliatu ahal izango dira. Bestela, abisu berriak zaharretan itoko dira, eta inork ez die kasurik egingo.
Hau konpiladoreen abisuekin duen analogia bera da. Ez da arrazoirik gabe konpiladoreen abisu kopurua 0-n mantentzea gomendatzen dutela. 1000 abisu badira, 1001 daudenean, inork ez dio kasurik egingo, eta ez dago argi non bilatu abisu berriena.
Istorio honetako gauzarik okerrena da une honetan goitik datorren norbait kode estatikoko analisia erabiltzera behartzen bazaitu. Horrek taldea desmotibatu besterik ez du egingo, bere ikuspuntutik oztopo besterik ez duen konplexutasun burokratiko gehigarria egongo baita. Inork ez ditu aztertuko analizatzailearen txostenak, eta erabilera guztiak "paperean" baino ez dira izango. Horiek. Formalki, analisia DevOps prozesuan sartzen da, baina praktikan horrek ez du inori mesede egiten. Istorio zehatzak entzun genituen txosnetan kongresuetako parte-hartzaileen eskutik. Esperientzia horrek analisi estatikoko tresnak denbora luzez erabil ditzaten programatzaileak desanimatu ditzake, betirako ez bada.
Zor teknikoa ezartzea eta kentzea
Izan ere, proiektu zahar handi batean ere analisi estatikoa sartzeak ez du ezer zaila edo beldurgarririk.
CI/CD
Gainera, analizatzailea berehala egin daiteke etengabeko garapen-prozesuaren parte. Adibidez, PVS-Studio banaketak txostena behar duzun formatuan eroso ikusteko utilitateak ditu eta kodearen atal problematikoak idatzi dituzten garatzaileentzako jakinarazpenak ditu. CI/CD sistemetatik PVS-Studio abiarazteko interesa gehiago dutenentzat, dagozkionekin ezagutzea gomendatzen dut. dokumentazioa eta artikulu sorta bat:
Baina itzul gaitezen positibo faltsu askoren gaira kodea aztertzeko tresnak ezartzeko lehen faseetan.
Lehendik dagoen zor teknikoa konpontzea eta abisu berriei aurre egitea
Analizatzaile estatiko komertzial modernoek kode berrietan edo aldatutakoan agertzen diren abisu berriak soilik aztertzeko aukera ematen dute. Mekanismo honen ezarpena aldatu egiten da, baina funtsa berdina da. PVS-Studio analizatzaile estatikoan, funtzionalitate hau honela ezartzen da.
Azkar analisi estatikoa erabiltzen hasteko, PVS-Studioko erabiltzaileei abisuak masiboki kentzeko mekanismoa erabiltzea gomendatzen diegu []. Ideia orokorra honakoa da. Erabiltzaileak analizatzailea abiarazi zuen eta abisu ugari jaso zituen. Urte askotan garatzen ari den proiektu bat bizirik dagoenez, garatzen eta dirua irabazten ari denez, ziurrenik txostenean ez da abisu asko egongo akats larriak adieraziz. Beste era batera esanda, akats kritikoak modu batean edo bestean konpondu dira metodo garestiagoak erabiliz edo bezeroen iritziei esker. Horren arabera, gaur egun analizatzaileak aurkitzen duen guztia zor teknikotzat har daiteke, eta hori ez da praktikoa berehala kentzen saiatzea.
PVS-Studio-ri esan diezaiokezu abisu hauek oraingoz garrantzirik ez izateko (gorde zor teknikoa gerorako), eta ez ditu gehiago erakutsiko. Analizatzaileak fitxategi berezi bat sortzen du eta bertan oraindik interesgarriak ez diren erroreei buruzko informazioa gordetzen du. Eta orain PVS-Studio-k abisuak emango ditu kode berri edo aldatutako soilik. Gainera, hori guztia modu egokian gauzatzen da. Esaterako, iturburu-kodearen fitxategiaren hasieran lerro huts bat gehitzen bada, analizatzaileak ulertzen du, egia esan, ezer ez dela aldatu, eta isilik jarraituko duela. Markatze-fitxategi hau bertsio-kontrol sistema batean jar daiteke. Fitxategia handia da, baina hori ez da arazo bat, ez baita maiz gordetzea baliorik.
Orain programatzaile guztiek kode berri edo aldatuarekin soilik lotutako abisuak ikusiko dituzte. Hala, analizatzailea erabiltzen has zaitezke, esan bezala, hurrengo egunetik aurrera. Eta zor teknikora itzuli zaitezke geroago, eta pixkanaka akatsak zuzendu eta analizatzailea konfiguratu.
Beraz, proiektu zahar handi batean analizatzailea ezartzearen lehen arazoa konpondu da. Orain asma dezagun zer egin zor teknikoarekin.
Akatsen konponketa eta birfactorizazioa
Errazena eta naturalena da denbora pixka bat alboratzea masiboki kendutako analizatzaileen abisuak aztertzeko eta pixkanaka horiei aurre egiteko. Nonbait kodean akatsak konpondu behar dituzu, nonbait birfaktorizatu beharko zenuke analizatzaileari kodea ez dela problematikoa esateko. Adibide sinplea:
if (a = b)C++-ko konpilatzaile eta analizatzaile gehienek kode hori kexatzen dute, benetan idatzi nahi izateko probabilitate handia baitago. (a == b). Baina hitzik gabeko akordio bat dago, eta hori normalean dokumentazioan adierazi ohi da, parentesi gehigarriak badaude, programatzaileak nahita idatzi zuela kode hori, eta ez dagoela zin egin beharrik. Adibidez, diagnostikoetarako PVS-Studio dokumentazioan argi eta garbi idatzita dago lerro hau zuzen eta segurutzat hartuko dela:
if ((a = b))Beste adibide bat. C++ kode honetan ahaztuta al dago? apurtu ala ez?
case A:
foo();
case B:
bar();
break;PVS-Studio analizatzaileak abisu bat emango du hemen . Baliteke hau ez izatea errore bat, kasu horretan analizatzaileari iradokizun bat eman behar diozu atributua gehituz edo adibidez __atributua__((erorketa)):
case A:
foo();
[[fallthrough]];
case B:
bar();
break;Esan daiteke kode aldaketak ez dutela akatsa konpontzen. Bai, hau egia da, baina bi gauza baliagarri egiten ditu. Lehenik eta behin, analizatzailearen txostenak positibo faltsuak kentzen ditu. Bigarrenik, kodea ulergarriagoa bihurtzen da bere mantentzen parte hartzen duten pertsonentzat. Eta hau oso garrantzitsua da! Horregatik bakarrik, komeni da birfaktorizazio txikiak egitea, kodea argiagoa eta mantentzea errazagoa izan dadin. Analizatzaileak ez duenez ulertzen "haustura" behar den ala ez, programatzaileei ere ez zaie argi geratuko.
Akatsen konponketez eta birfaktorizazioaz gain, analizatzaileen abisu faltsuak ezabatu ditzakezu bereziki. Garrantzirik gabeko diagnostiko batzuk desgaitu daitezke. Adibidez, norbaitek uste du abisuak alferrikakoak direla float/bikoitzaren balioak alderatzeari buruz. Eta batzuek garrantzitsutzat eta aztertzeko merezi duten moduan sailkatzen dituzte []. Zein abisu garrantzitsutzat jotzen diren eta zein ez, garapen-taldearen esku dago.
Alerta faltsuak ezabatzeko beste modu batzuk daude. Adibidez, makro markaketa aipatu zen lehenago. Hori guztia zehatzago azaltzen da dokumentazioan. Garrantzitsuena ulertzea da pixkanaka eta sistematikoki positibo faltsuekin lanera hurbiltzen bazara, ez dagoela gaizki. Konfigurazio ondoren interesik gabeko abisu gehienak desagertzen dira eta benetan azterketa zehatza eta kodean aldaketa batzuk behar dituzten lekuak baino ez dira geratzen.
Gainera, beti laguntzen diegu gure bezeroei PVS-Studio konfiguratzen zailtasunak sortzen badira. Gainera, izan ziren guk geuk abisu faltsuak ezabatu eta akatsak zuzendu genituen kasuak []. Badaezpada, lankidetza hedatuaren aukera hau ere posible dela aipatzea erabaki nuen :).
Trinketa metodoa
Badago beste ikuspegi interesgarri bat pixkanaka kodearen kalitatea hobetzeko analizatzaile estatikoko abisua ezabatuz. Beheko kontua da abisu kopurua gutxitu baino ezin dela egin.
Analizatzaile estatikoak igorritako abisu kopurua erregistratzen da. Kalitate atea konfiguratuta dago, orain eragiketa kopurua handitzen ez duen kode bat bakarrik sar dezakezu. Ondorioz, alarma-kopurua apurka-apurka murrizteko prozesua hasten da analizatzailea egokituz eta akatsak zuzenduz.
Nahiz eta pertsona batek apur bat iruzur egin eta kalitatearen atea gainditzea erabakitzen badu ez bere kode berrian abisuak ezabatuz, hirugarrenen kode zaharra hobetuz baizik, hau ez da beldurgarria. Dena den, trinketa noranzko batean biratzen da, eta pixkanaka akatsen kopurua murriztuko da. Pertsona batek bere akats berriak konpondu nahi ez baditu ere, aldameneko kodean zerbait hobetu beharko du. Noizbait, abisu kopurua murrizteko modu errazak amaitzen dira, eta benetako akatsak konponduko diren une bat iristen da.
Metodologia hau zehatzago deskribatzen da Ivan Ponomarev-en artikulu oso interesgarri batean "", kodearen kalitatea hobetzeko interesa duen edonori irakurtzea gomendatzen diot.
Artikuluaren egileak gai honi buruzko erreportaje bat ere badu: "".
Ondorioa
Espero dut artikulu honen ondoren irakurleek analisi estatikoko tresnak gehiago onartzea eta garapen prozesuan ezarri nahi izatea. Galderarik baduzu, beti prest gaude PVS-Studio gure analizatzaile estatikoko erabiltzaileei eta inplementazioan lagundu.
Badira beste zalantza tipiko batzuk analisi estatikoa benetan erosoa eta erabilgarria izan daitekeen ala ez. Zalantza horietako gehienak uxatzen saiatu nintzen "PVS-Studio kode estatikoko analizatzailea garapen-prozesuan sartzeko arrazoiak" argitalpenean [].
Eskerrik asko zure arretagatik eta zatoz eta probatu PVS-Studio analizatzailea.
Esteka osagarriak
- Andrei Karpov.
- Wikipedia. .
- Andrey Karpov, Victoria Khanieva. .
- PVS-Studioa. Dokumentazioa. .
- Andrei Karpov. .
- PVS-Studioa. Dokumentazioa. .
- Ivan Andryashin. .
- Pavel Eremeev, Svyatoslav Razmyslov. .
- Andrei Karpov. .
Artikulu hau ingelesez hitz egiten duen publiko batekin partekatu nahi baduzu, mesedez, erabili itzulpen esteka: Andrey Karpov. .
Iturria: www.habr.com