Þreyttur á endalausri endurskoðun kóða eða villuleit, stundum hugsarðu um hvernig eigi að einfalda líf þitt. Og eftir að hafa leitað aðeins, eða óvart rekist á það, geturðu séð töfrasetninguna: „Static analysis“. Við skulum sjá hvað það er og hvernig það getur haft samskipti við verkefnið þitt.
Reyndar, ef þú skrifar á einhverju nútímamáli, þá, án þess þó að gera þér grein fyrir því, keyrir þú það í gegnum kyrrstöðugreiningartæki. Staðreyndin er sú að hvaða nútíma þýðandi veitir, að vísu örlítið, sett af viðvörunum um hugsanleg vandamál í kóðanum. Til dæmis, þegar þú safnar saman C++ kóða í Visual Studio gætirðu séð eftirfarandi:
Í þessari útkomu sjáum við að breytan var var aldrei notað neins staðar í fallinu. Svo í raun og veru notaðir þú næstum alltaf einfaldan kyrrstæðan kóða greiningartæki. Hins vegar, ólíkt faglegum greiningartækjum eins og Coverity, Klocwork eða PVS-Studio, geta viðvaranirnar sem þýðandinn gefur aðeins gefið til kynna lítið úrval vandamála.
Ef þú veist ekki með vissu hvað kyrrstöðugreining er og hvernig á að útfæra hana, til að læra meira um þessa aðferðafræði.
Af hverju þarftu statíska greiningu?
Í hnotskurn: hröðun og einföldun.
Stöðug greining gerir þér kleift að finna mikið af mismunandi vandamálum í kóðanum: allt frá rangri notkun tungumálauppbygginga til innsláttarvillna. Til dæmis í staðinn fyrir
auto x = obj.x;
auto y = obj.y;
auto z = obj.z;Þú skrifaðir eftirfarandi kóða:
auto x = obj.x;
auto y = obj.y;
auto z = obj.x;Eins og þú sérð er prentvilla í síðustu línu. Til dæmis gefur PVS-Studio út eftirfarandi viðvörun:
Íhugaðu að skoða réttmæti notkunar „y“ atriðisins.
Ef þú vilt stinga höndum þínum í þessa villu skaltu prófa tilbúið dæmi í Compiler Explorer: **.
Og eins og þú skilur, þá er ekki alltaf hægt að fylgjast með slíkum köflum af kóða strax, og vegna þessa geturðu sest niður við villuleit í góðan klukkutíma og velt því fyrir þér hvers vegna allt virkar svona undarlega.
Hins vegar er þetta augljóslega mistök. Hvað ef verktaki skrifaði óákjósanlegan kóða vegna þess að hann gleymdi einhverri fíngerð tungumálsins? Eða jafnvel leyft það í kóðanum ? Því miður eru slík tilvik algjörlega algeng og bróðurpartur tímans fer í að kemba sérstaklega virkan kóða sem inniheldur innsláttarvillur, dæmigerðar villur eða óskilgreinda hegðun.
Það er fyrir þessar aðstæður sem kyrrstöðugreining birtist. Þetta er aðstoðarmaður fyrir þróunaraðila sem mun benda á ýmis vandamál í kóðanum og útskýra í skjölunum hvers vegna ekki er nauðsynlegt að skrifa á þennan hátt, hvað það getur leitt til og hvernig á að laga það. Hér er dæmi um hvernig það gæti litið út: **.
Þú getur fundið fleiri áhugaverðar villur sem greiningartækið getur greint í greinunum:
Nú þegar þú hefur lesið þetta efni og ert sannfærður um ávinninginn af kyrrstöðugreiningu gætirðu viljað prófa það. En hvar á að byrja? Hvernig á að samþætta nýtt verkfæri í núverandi verkefni? Og hvernig á að kynna liðið fyrir honum? Þú finnur svör við þessum spurningum hér að neðan.
Ath. Stöðug greining kemur ekki í stað eða hættir við svo gagnlegan hlut eins og kóðadóma. Það er viðbót við þetta ferli og hjálpar til við að taka eftir og leiðrétta innsláttarvillur, ónákvæmni og hættulega hönnun fyrirfram. Það er miklu afkastameira að einbeita sér að kóðadómum um reiknirit og skýrleika kóða, frekar en að leita að röngum svigum eða .
0. Að kynnast tólinu
Þetta byrjar allt með prufuútgáfu. Reyndar er erfitt að ákveða að kynna eitthvað í þróunarferlinu ef þú hefur aldrei séð tólið í beinni áður. Þess vegna er það fyrsta sem þú ættir að gera að hlaða niður .
Það sem þú munt læra á þessu stigi:
- Hverjar eru leiðirnar til að hafa samskipti við greiningartækið;
- Er greiningartækið samhæft við þróunarumhverfið þitt?
- Hvaða vandamál eru núna í verkefnum þínum?
Eftir að þú hefur sett upp allt sem þú þarft, það fyrsta sem þú ættir að gera er að keyra greiningu á öllu verkefninu (, , ). Þegar um er að ræða PVS-Studio í Visual Studio muntu sjá svipaða mynd (smellanleg):
Staðreyndin er sú að kyrrstöðugreiningartæki gefa venjulega út mikinn fjölda viðvarana fyrir verkefni með stóran kóðagrunn. Það er engin þörf á að laga þau öll, þar sem verkefnið þitt er nú þegar að vinna, sem þýðir að þessi vandamál eru ekki mikilvæg. Hins vegar þú og leiðrétta þær ef þörf krefur. Til að gera þetta þarftu að sía úttakið og skilja aðeins eftir áreiðanlegustu skilaboðin. Í PVS-Studio viðbótinni fyrir Visual Studio er þetta gert með því að sía eftir villustigum og flokkum. Til að fá sem nákvæmasta framleiðsla, skildu aðeins eftir Hár и almennt (einnig smellanlegt):
Reyndar er miklu auðveldara að skoða 178 viðvaranir en nokkur þúsund...
Í flipa Medium и Low Oft eru góðar viðvaranir, en í þessum flokkum eru greiningar sem hafa minni nákvæmni (áreiðanleika). Frekari upplýsingar um viðvörunarstig og möguleika til að vinna undir Windows má finna hér: **.
Það er þess virði að hafa farið yfir áhugaverðustu villurnar (og leiðrétt þær með góðum árangri). . Þetta er nauðsynlegt til að nýjar viðvaranir glatist ekki meðal þeirra gömlu. Að auki er kyrrstöðugreiningartæki aðstoðarmaður forritarans en ekki listi yfir villur. 🙂
1. Sjálfvirkni
Eftir að hafa kynnst er kominn tími til að stilla viðbætur og samþætta CI. Þetta verður að gera áður en forritarar byrja að nota stöðugreiningartækið. Staðreyndin er sú að forritarinn gæti gleymt að virkja greiningu eða vill alls ekki gera það. Til að gera þetta þarftu að gera lokaathugun á öllu svo að óprófaður kóði komist ekki inn í almenna þróunargreinina.
Það sem þú munt læra á þessu stigi:
- Hvaða sjálfvirknivalkostir býður tólið upp á;
- Er greiningartækið samhæft við samsetningarkerfið þitt?
Þar sem fullkomin skjöl eru ekki til þarf stundum að skrifa inn . Þetta er eðlilegt og við erum fús til að hjálpa þér. 🙂
Nú skulum við halda áfram í samfellda samþættingu (CI) þjónustu. Hægt er að útfæra hvaða greiningartæki sem er í þá án alvarlegra vandamála. Til að gera þetta þarftu að búa til sérstakt stig í leiðslunni, sem venjulega er staðsett eftir byggingar- og einingaprófanir. Þetta er gert með því að nota ýmis stjórnborðsforrit. Til dæmis, PVS-Studio býður upp á eftirfarandi tól:
- (greining á lausnum, C#, C++ verkefnum á Windows)
- (söfnunareftirlit)
- (greining á C++ verkefnum á Linux / macOS)
- (lausnagreining, C# verkefni á Linux / macOS)
- (greining á Java verkefnum)
- (skýrsluskráarbreytir)
Til að samþætta greiningu í CI þarftu að gera þrennt:
- Settu upp greiningartækið;
- Hlaupagreining;
- Skila árangri.
Til dæmis, til að setja upp PVS-Studio á Linux (Debian-base), þarftu að keyra eftirfarandi skipanir:
wget -q -O - https://files.viva64.com/etc/pubkey.txt
| sudo apt-key add -
sudo wget -O /etc/apt/sources.list.d/viva64.list
https://files.viva64.com/etc/viva64.list
sudo apt-get update -qq
sudo apt-get install -qq pvs-studioÁ kerfum sem keyra Windows er engin leið að setja upp greiningartækið frá pakkastjóranum, en það er hægt að nota greiningartækið frá skipanalínunni:
PVS-Studio_setup.exe /verysilent /suppressmsgboxes
/norestart /nocloseapplicationsÞú getur lesið meira um uppsetningu PVS-Studio á kerfum sem keyra Windows **.
Eftir uppsetningu þarftu að keyra greininguna beint. Hins vegar er mælt með því að gera þetta aðeins eftir að samantekt og próf hafa staðist. Þetta er vegna þess að kyrrstöðugreining tekur venjulega tvöfalt lengri tíma en samantekt.
Þar sem ræsingaraðferðin fer eftir vettvangi og verkefnaeiginleikum mun ég sýna valkostinn fyrir C++ (Linux) sem dæmi:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
plog-converter -t errorfile PVS-Studio.log --cerr -wFyrsta skipunin mun framkvæma greininguna og sú seinni breytir skýrslunni í textasnið, birtir hana á skjánum og skilar öðrum skilakóða en 0 ef það eru viðvaranir. Hægt er að nota vélbúnað eins og þetta til að loka fyrir byggingu þegar villuboð eru. Hins vegar er alltaf hægt að fjarlægja fánann -w og ekki loka fyrir samsetningu sem inniheldur viðvaranir.
Ath. Textasniðið er óþægilegt. Það er einfaldlega gefið sem dæmi. Gefðu gaum að áhugaverðara skýrslusniði - FullHtml. Það gerir þér kleift að fletta í gegnum kóðann.
Þú getur lesið meira um uppsetningu greiningar á CI í greininni "" (Windows) eða "“ (Linux).
Allt í lagi, þú hefur stillt greiningartækið á byggingarþjóninum. Nú, ef einhver hlóð upp óprófuðum kóða, mun staðfestingarstigið mistakast og þú munt geta greint vandamálið, hins vegar er þetta ekki alveg þægilegt, þar sem það er skilvirkara að athuga verkefnið ekki eftir að útibúin hafa verið sameinuð, en á undan því, á stigi beiðni um drátt. A.
Almennt séð er uppsetning á dráttarbeiðnigreiningu ekki mikið frábrugðin venjulegri ræsingu greiningar á CI. Nema fyrir þörfina á að fá lista yfir breyttar skrár. Þetta er venjulega hægt að fá með því að spyrjast fyrir um muninn á útibúum með því að nota git:
git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.listNú þarftu að senda þennan lista yfir skrár til greiningartækisins sem inntak. Til dæmis, í PVS-Stúdíó er þetta útfært með því að nota fánann -S:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
-S .pvs-pr.listÞú getur fengið frekari upplýsingar um að greina útdráttarbeiðnir **. Jafnvel þó að CI þín sé ekki á listanum yfir þjónustu sem nefnd er í greininni, þá muntu finna almenna hlutann sem helgaður er kenningunni um þessa tegund greiningar gagnlegur.
Með því að setja upp greiningu á dráttarbeiðnum geturðu lokað á skuldbindingar sem innihalda viðvaranir og þar með búið til mörk sem óprófaður kóði kemst ekki yfir.
Þetta er vissulega allt gott, en ég myndi vilja sjá allar viðvaranir á einum stað. Ekki aðeins frá kyrrstöðugreiningartækinu, heldur einnig frá einingarprófum eða frá kraftmikla greiningartækinu. Það eru ýmsar þjónustur og viðbætur fyrir þetta. PVS-Studio, til dæmis, hefur .
2. Samþætting á þróunarvélum
Nú er kominn tími til að setja upp og stilla greiningartækið fyrir daglega þróunarnotkun. Á þessum tímapunkti hefur þú nú þegar kynnst flestum vinnubrögðum, svo þetta má kalla það auðveldasta.
Sem einfaldasti kosturinn geta verktaki sjálfir sett upp nauðsynlegan greiningartæki. Hins vegar mun þetta taka mikinn tíma og afvegaleiða þá frá þróun, svo þú getur sjálfvirkt þetta ferli með því að nota uppsetningarforrit og nauðsynlega fána. Fyrir PVS-Stúdíó eru ýmsar . Hins vegar eru alltaf pakkastjórar, til dæmis Chocolatey (Windows), Homebrew (macOS) eða heilmikið af valkostum fyrir Linux.
Þá þarftu að setja upp nauðsynlegar viðbætur, til dæmis fyrir , , o.fl.
3. Dagleg notkun
Á þessu stigi er kominn tími til að segja nokkur orð um leiðir til að flýta fyrir greiningartækinu við daglega notkun. Heildargreining á öllu verkefninu tekur mikinn tíma, en hversu oft breytum við kóða í öllu verkefninu í einu? Það er varla til nein refactoring sem er svo stór að hún hafi strax áhrif á allan kóðagrunninn. Fjöldi skráa sem verið er að breyta í einu fer sjaldan yfir tugi, svo það er skynsamlegt að greina þær. Fyrir slíkar aðstæður er til . Bara ekki vera brugðið, þetta er ekki annað tæki. Þetta er sérstakur háttur sem gerir þér kleift að greina aðeins breyttar skrár og ósjálfstæði þeirra, og þetta gerist sjálfkrafa eftir byggingu ef þú ert að vinna í IDE með viðbótina uppsett.
Ef greiningartækið finnur vandamál í nýlega breyttum kóða mun hann tilkynna það sjálfstætt. Til dæmis mun PVS-Studio segja þér frá þessu með því að nota viðvörun:
Auðvitað er ekki nóg að segja forriturum að nota tólið. Við þurfum einhvern veginn að segja þeim hvað það er og hvernig það er. Hér eru til dæmis greinar um fljótlega byrjun fyrir PVS-Studio, en þú getur fundið svipaðar kennsluefni fyrir hvaða tól sem þú vilt:
Slíkar greinar veita allar nauðsynlegar upplýsingar fyrir daglega notkun og taka ekki mikinn tíma. 🙂
Jafnvel á því stigi að kynnast tólinu, bældum við niður margar viðvaranir í einni af fyrstu kynningum. Því miður eru stöðugreiningartæki ekki fullkomin, svo af og til gefa þeir rangar jákvæðar. Það er venjulega auðvelt að bæla þá niður; til dæmis, í PVS-Studio viðbótinni fyrir Visual Studio þarftu bara að smella á einn hnapp:
Hins vegar geturðu gert meira en bara bæla þau niður. Til dæmis geturðu tilkynnt vandamál til stuðnings. Ef hægt er að leiðrétta falsku jákvæðuna, þá geturðu í framtíðaruppfærslum tekið eftir því að í hvert skipti sem það eru færri og færri falskar jákvæðar sem eru sértækar fyrir kóðagrunninn þinn.
Eftir samþættingu
Þannig að við höfum farið í gegnum öll stigin við að samþætta truflanir greiningar í þróunarferlinu. Þrátt fyrir mikilvægi þess að setja upp slík verkfæri á CI, er mikilvægasti staðurinn til að keyra þau tölva þróunaraðilans. Eftir allt saman, static analysator er ekki dómari sem segir einhvers staðar langt í burtu frá þér að kóðinn sé ekki góður. Þvert á móti er það aðstoðarmaður sem segir þér ef þú ert þreyttur og minnir þig á ef þú hefur gleymt einhverju.
True, án reglulegrar notkunar er ólíklegt að truflanir greining muni einfalda þróun verulega. Þegar öllu er á botninn hvolft liggur helsti ávinningur þess fyrir þróunaraðila ekki svo mikið í því að leita að flóknum og umdeildum köflum kóðans, heldur í því að greina snemma. Sammála því að það að uppgötva vandamál eftir að breytingarnar hafa verið sendar til prófunar er ekki bara óþægilegt heldur líka mjög tímafrekt. Statísk greining, þegar hún er notuð reglulega, skoðar allar breytingar beint á tölvunni þinni og tilkynnir um grunsamlega staði á meðan unnið er að kóðanum.
Og ef þú eða samstarfsmenn þínir eru enn ekki vissir um hvort það sé þess virði að innleiða greiningartækið, þá legg ég til að þú byrjar núna að lesa greinina "". Það tekur á dæmigerðum áhyggjum þróunaraðila að kyrrstöðugreining taki tíma þeirra og svo framvegis.
Ef þú vilt deila þessari grein með enskumælandi áhorfendum, vinsamlegast notaðu þýðingartengilinn: Maxim Zvyagintsev. .
Heimild: www.habr.com