Það er auðvelt að prófa kyrrstöðugreiningartæki. En til að hrinda því í framkvæmd, sérstaklega í þróun stórs gamals verkefnis, þarf kunnáttu. Ef það er gert rangt getur greiningartækið bætt við vinnu, hægt á þróun og dregið úr hreyfingu í liðinu. Við skulum tala stuttlega um hvernig á að nálgast rétt samþættingu truflanagreiningar í þróunarferlinu og byrja að nota það sem hluta af CI/CD.
Inngangur
Nýlega var athygli mína vakin á útgáfunni "". Annars vegar er þetta góð grein sem vert er að kynna sér. Hins vegar sýnist mér hún ekki gefa fullkomið svar um hvernig á sársaukalaust að innleiða kyrrstöðugreiningu í verkefni með miklu. af eldri kóða. Í greininni segir að Þú getur samþykkt tækniskuldir og unnið aðeins á nýjum kóða, en það er ekkert svar við því hvað á að gera við þessa tæknilegu skuld síðar.
PVS-Studio teymið okkar býður upp á sína skoðun á þessu efni. Við skulum skoða hvernig vandamálið við að innleiða kyrrstæða kóðagreiningartæki kemur upp í fyrsta lagi, hvernig á að sigrast á þessu vandamáli og hvernig á að útrýma tæknilegum skuldum smám saman sársaukalaust.
Vandamál
Það er venjulega ekki erfitt að ræsa og sjá hvernig kyrrstöðugreiningartæki virkar []. Þú gætir séð áhugaverðar villur eða jafnvel ógnvekjandi hugsanlega veikleika í kóðanum. Það er meira að segja hægt að laga eitthvað en þá gefast margir forritarar upp.
Allir kyrrstöðugreiningartæki gefa rangar jákvæðar niðurstöður. Þetta er eiginleiki kyrrstöðugreiningaraðferðarinnar og ekkert hægt að gera í því. Í almennu tilvikinu er þetta óleysanlegt vandamál, eins og staðfest er með setningu Rice []. Vélræn reiknirit munu ekki hjálpa heldur []. Jafnvel þó maður geti ekki alltaf sagt hvort þessi eða hinn kóðinn sé rangur, þá ættirðu ekki að búast við þessu frá forritinu :).
Rangar jákvæðar eru ekki vandamál ef stöðugreiningartækið er þegar stillt:
- Óvirkt óviðkomandi reglusett;
- Sumar óviðkomandi greiningar hafa verið óvirkar;
- Ef við erum að tala um C eða C++, þá eru fjölva merkt upp sem innihalda ákveðnar smíðar sem valda því að gagnslausar viðvaranir birtast á hverjum stað þar sem slík fjölva eru notuð;
- Eigin aðgerðir eru merktar sem framkvæma aðgerðir svipaðar kerfisaðgerðum (eigin hliðstæða memcpy eða prentf) [];
- Rangar jákvæðar eru sérstaklega óvirkar með því að nota athugasemdir;
- Og svo framvegis.
Í þessu tilviki getum við búist við lágu fölsku jákvæðu hlutfalli um 10-15% []. Með öðrum orðum, 9 af hverjum 10 greiningarviðvaranir gefa til kynna raunverulegt vandamál í kóðanum, eða að minnsta kosti "lyktandi kóða." Sammála, þessi atburðarás er mjög skemmtileg og greiningartækið er raunverulegur vinur forritarans.
Í raun og veru, í stóru verkefni, verður upphafsmyndin allt önnur. Greiningartækið gefur út hundruð eða þúsundir viðvarana fyrir eldri kóða. Það er ómögulegt að skilja fljótt hver þessara viðvarana eiga við og hver ekki. Það er óskynsamlegt að setjast niður og fara að takast á við allar þessar viðvaranir, þar sem aðalvinnan í þessu máli mun stöðvast í marga daga eða vikur. Venjulega hefur lið ekki efni á slíkri atburðarás. Það verður líka gríðarlegur fjöldi mismuna sem spilla breytingasögunni. Og hröð fjöldabreyting á svo mörgum brotum í kóðanum mun óhjákvæmilega leiða til nýrra innsláttarvillna og villna.
Og síðast en ekki síst, slíkur árangur í baráttunni við viðvaranir er lítill sens. Sammála því að þar sem verkefnið hefur gengið vel í mörg ár hafa flestar mikilvægu villurnar í því þegar verið leiðréttar. Já, þessar lagfæringar voru mjög dýrar, þurfti að kemba, fengu neikvæð viðbrögð frá notendum um villur og svo framvegis. Stöðug greiningartæki myndi hjálpa til við að laga margar af þessum villum á kóðunarstigi, fljótt og ódýrt. En í augnablikinu, með einum eða öðrum hætti, hafa þessar villur verið lagfærðar og greiningartækið skynjar aðallega ekki mikilvægar villur í gamla kóðanum. Ekki er víst að þennan kóða sé notaður, hann gæti verið notaður mjög sjaldan og villa í honum gæti ekki leitt til merkjanlegra afleiðinga. Kannski einhvers staðar er skugginn frá hnappinum rangur litur, en þetta truflar ekki notkun neins á vörunni.
Auðvitað eru jafnvel minniháttar mistök enn mistök. Og stundum geta mistök falið raunverulegan varnarleysi. Hins vegar að gefast upp á öllu og eyða dögum/vikum í að takast á við galla sem varla gera vart við sig lítur út fyrir að vera vafasöm hugmynd.
Forritarar skoða, skoða, skoða allar þessar viðvaranir um gamla vinnukóðann... Og þeir hugsa: við getum verið án kyrrstöðugreiningar. Við skulum fara að skrifa nýja gagnlega virkni.
Á sinn hátt hafa þeir rétt fyrir sér. Þeir telja að fyrst verði þeir einhvern veginn að losna við allar þessar viðvaranir. Aðeins þá munu þeir geta notið góðs af reglulegri notkun kóðagreiningartækisins. Að öðrum kosti munu nýjar viðvaranir einfaldlega drukkna í gömlum og enginn veitir þeim gaum.
Þetta er sama líking og með þýðandaviðvaranir. Það er ekki að ástæðulausu sem þeir mæla með því að halda fjölda þýðandaviðvarana við 0. Ef það eru 1000 viðvaranir, þá þegar þær eru 1001, mun enginn taka eftir því og ekki er ljóst hvar á að leita að þessari nýjustu viðvörun.
Það versta í þessari sögu er ef einhver að ofan á þessari stundu neyðir þig til að nota kyrrstöðugreiningu. Þetta mun aðeins draga úr hreyfingu á liðinu, þar sem frá sjónarhóli þeirra verður auka skrifræðisflækjustig sem kemur aðeins í veg fyrir. Enginn mun skoða skýrslur greiningartækisins og öll notkun verður aðeins „á pappír“. Þeir. Formlega er greining innbyggð í DevOps ferlið, en í reynd er það engum til góðs. Við heyrðum ítarlegar sögur frá ráðstefnugestum á básum. Slík reynsla getur dregið úr forritara frá því að nota truflanir greiningartæki í langan tíma, ef ekki að eilífu.
Innleiðing og útrýming tæknilegra skulda
Reyndar er ekkert erfitt eða skelfilegt við að innleiða kyrrstöðugreiningu jafnvel inn í stórt gamalt verkefni.
CI / CD
Þar að auki getur greiningartækið strax verið hluti af stöðugu þróunarferlinu. Til dæmis inniheldur PVS-Studio dreifingin tól til að skoða skýrsluna á þægilegan hátt á því sniði sem þú þarft og tilkynningar til forritara sem skrifuðu erfiða hluta kóðans. Fyrir þá sem hafa meiri áhuga á að koma PVS-Stúdíó af stað úr CI/CD kerfum mæli ég með að þú kynnir þér tilheyrandi skjöl og röð greina:
En við skulum snúa okkur aftur að spurningunni um fjölda rangra jákvæðra á fyrstu stigum innleiðingar á kóðagreiningartækjum.
Lagfæra núverandi tækniskuldir og takast á við nýjar viðvaranir
Nútíma truflanir í atvinnuskyni gera þér kleift að rannsaka aðeins nýjar viðvaranir sem birtast í nýjum eða breyttum kóða. Framkvæmd þessa kerfis er mismunandi, en kjarninn er sá sami. Í PVS-Studio kyrrstöðugreiningartækinu er þessi virkni útfærð sem hér segir.
Til að byrja fljótt að nota kyrrstöðugreiningu, mælum við með því að notendur PVS-Studio noti vélbúnaðinn fyrir fjöldabælingu viðvarana []. Almenn hugmynd er eftirfarandi. Notandinn ræsti greiningartækið og fékk margar viðvaranir. Þar sem verkefni sem hefur verið í þróun í mörg ár er lifandi, þróast og græða peninga, þá munu líklega ekki vera margar viðvaranir í skýrslunni sem benda til mikilvægra galla. Með öðrum orðum, mikilvægar villur hafa þegar verið lagaðar á einn eða annan hátt með dýrari aðferðum eða þökk sé endurgjöf frá viðskiptavinum. Samkvæmt því getur allt sem greiningartækið finnur núna talist tæknilega skuld, sem er óframkvæmanlegt að reyna að útrýma strax.
Þú getur sagt PVS-Studio að telja þessar viðvaranir óviðkomandi í bili (vistaðu tæknilegar skuldir til síðar) og það mun ekki lengur sýna þær. Greiningartækið býr til sérstaka skrá þar sem það vistar upplýsingar um villur sem eru ekki enn áhugaverðar. Og nú mun PVS-Studio aðeins gefa út viðvaranir fyrir nýjan eða breyttan kóða. Þar að auki er allt þetta útfært á snjallan hátt. Ef til dæmis tómri línu er bætt við upphaf frumkóðaskrárinnar, þá skilur greiningartækið að í rauninni hefur ekkert breyst og mun halda áfram að þegja. Þessa merkingarskrá er hægt að setja í útgáfustýringarkerfi. Skráin er stór en þetta er ekki vandamál þar sem það þýðir ekkert að geyma hana oft.
Nú munu allir forritarar sjá viðvaranir sem tengjast eingöngu nýjum eða breyttum kóða. Þannig geturðu byrjað að nota greiningartækið, eins og sagt er, frá næsta degi. Og þú getur snúið aftur til tæknilegra skulda síðar, og smám saman lagað villur og stillt greiningartækið.
Þannig að fyrsta vandamálið við innleiðingu greiningartækisins í stóru gömlu verkefni hefur verið leyst. Nú skulum við reikna út hvað á að gera við tæknilegar skuldir.
Villuleiðréttingar og endurstillingar
Einfaldast og eðlilegast er að taka tíma til að greina gríðarlega bældar viðvaranir greiningartækja og bregðast smám saman við þær. Einhvers staðar ættir þú að laga villur í kóðanum, einhvers staðar ættir þú að endurskoða til að segja greiningartækinu að kóðinn sé ekki vandamál. Einfalt dæmi:
if (a = b)Flestir C++ þýðendur og greiningartæki kvarta undan slíkum kóða, þar sem miklar líkur eru á að þeir hafi í raun og veru viljað skrifa (a == b). En það er ósagt samkomulag, og það er venjulega tekið fram í skjölunum, að ef það eru fleiri sviga, þá er talið að forritarinn hafi vísvitandi skrifað slíkan kóða, og það er engin þörf á að blóta. Til dæmis, í PVS-Studio skjölum fyrir greiningu það er skýrt skrifað að eftirfarandi lína verði talin rétt og örugg:
if ((a = b))Annað dæmi. Er það gleymt í þessum C++ kóða? brjóta eða ekki?
case A:
foo();
case B:
bar();
break;PVS-Studio greiningartækið mun gefa út viðvörun hér . Þetta gæti ekki verið villa, í því tilviki ættir þú að gefa þáttaranum vísbendingu með því að bæta við eigindinni eða til dæmis __eiginleiki__((fallthrough)):
case A:
foo();
[[fallthrough]];
case B:
bar();
break;Það má segja að slíkar kóðabreytingar lagi ekki villuna. Já, þetta er satt, en það gerir tvennt gagnlegt. Í fyrsta lagi losnar greiningarskýrslan við rangar jákvæðar niðurstöður. Í öðru lagi verður kóðinn skiljanlegri fyrir fólkið sem tekur þátt í viðhaldi hans. Og þetta er mjög mikilvægt! Fyrir þetta eitt og sér er það þess virði að framkvæma minniháttar endurstillingar til að gera kóðann skýrari og auðveldari í viðhaldi. Þar sem greiningartækið skilur ekki hvort „brot“ sé þörf eða ekki, mun það líka vera óljóst fyrir aðra forritara.
Til viðbótar við villuleiðréttingar og endurstillingar geturðu sérstaklega bæla niður augljóslega rangar greiningarviðvaranir. Sumar óviðkomandi greiningar geta verið óvirkar. Til dæmis finnst einhverjum viðvaranir tilgangslausar um að bera saman flot/tvöfalt gildi. Og sumir flokka þá sem mikilvæga og verðuga náms []. Hvaða viðvaranir eru taldar eiga við og hverjar ekki er í höndum þróunarhópsins að ákveða.
Það eru aðrar leiðir til að bæla niður rangar viðvaranir. Til dæmis var þjóðhagsálagning nefnd áðan. Öllu þessu er lýst nánar í skjölunum. Mikilvægast er að skilja að ef þú nálgast það smám saman og kerfisbundið að vinna með rangar jákvæðar, þá er ekkert að þeim. Langflestar óáhugaverðar viðvaranir hverfa eftir uppsetningu og aðeins staðir sem raunverulega krefjast vandlegrar rannsóknar og nokkrar breytingar á kóðanum eru eftir.
Einnig hjálpum við viðskiptavinum okkar alltaf að setja upp PVS-Studio ef einhverjir erfiðleikar koma upp. Ennfremur komu upp dæmi þar sem við sjálf útrýmdum rangar viðvaranir og leiðréttum villur []. Til öryggis ákvað ég að nefna að þessi valkostur fyrir lengra samstarf er líka mögulegur :).
Ratchet aðferð
Það er önnur áhugaverð nálgun til að bæta gæði kóða smám saman með því að útrýma viðvöruninni um kyrrstöðugreiningartæki. Niðurstaðan er sú að viðvörunum getur aðeins fækkað.
Fjöldi viðvarana sem kyrrstöðugreiningartækið gefur út er skráður. Gæðahliðið er stillt þannig að nú er aðeins hægt að slá inn kóða sem fjölgar ekki aðgerðum. Þess vegna byrjar ferlið við að fækka viðvörunum smám saman með því að stilla greiningartækið og leiðrétta villur.
Jafnvel þó að einstaklingur vilji svindla aðeins og ákveði að fara framhjá gæðahliðinu, ekki með því að útrýma viðvörunum í nýja kóðanum sínum, heldur með því að bæta gamla þriðja aðila kóðann, þá er þetta ekki skelfilegt. Að sama skapi snýst skrallinn í eina átt og smám saman mun bilunum fækka. Jafnvel þótt einstaklingur vilji ekki laga eigin nýja galla, verður hann samt að bæta eitthvað í nágrannakóðanum. Á einhverjum tímapunkti lýkur auðveldu leiðunum til að fækka viðvörunum og það kemur að því að raunverulegar villur verða lagaðar.
Þessari aðferðafræði er lýst nánar í mjög áhugaverðri grein eftir Ivan Ponomarev "", sem ég mæli með að lesa fyrir alla sem hafa áhuga á að bæta kóða gæði.
Greinarhöfundur hefur einnig skýrslu um þetta efni: "".
Ályktun
Ég vona að eftir þessa grein muni lesendur sætta sig betur við kyrrstöðugreiningartæki og vilja innleiða þau í þróunarferlið. Ef þú hefur einhverjar spurningar erum við alltaf tilbúin notendur stöðugreiningartækisins okkar PVS-Studio og aðstoða við innleiðingu þess.
Það eru aðrar dæmigerðar efasemdir um hvort kyrrstöðugreining geti raunverulega verið þægileg og gagnleg. Ég reyndi að eyða flestum þessum efasemdum í ritinu „Ástæður til að kynna PVS-Studio truflana kóða greiningartækið í þróunarferlinu“ [].
Þakka þér fyrir athyglina og komdu og prófaðu PVS-Studio greiningartækið.
Viðbótartenglar
- Andrey Karpov.
- Wikipedia. .
- Andrey Karpov og Victoria Khanieva. .
- PVS-stúdíó. Skjöl. .
- Andrey Karpov. .
- PVS-stúdíó. Skjöl. .
- Ivan Andryashin. .
- Pavel Eremeev og Svyatoslav Razmyslov. .
- Andrey Karpov. .
Ef þú vilt deila þessari grein með enskumælandi áhorfendum, vinsamlegast notaðu þýðingartengilinn: Andrey Karpov. .
Heimild: www.habr.com