Moeg vir eindelose kodehersiening of ontfouting, dink jy soms aan hoe om jou lewe te vereenvoudig. En nadat jy 'n bietjie gesoek het, of per ongeluk daarop afgekom het, kan jy die magiese frase sien: "Statiese analise." Kom ons kyk wat dit is en hoe dit met jou projek kan inwerk.
Trouens, as jy in enige moderne taal skryf, dan, sonder om dit eers te besef, het jy dit deur 'n statiese ontleder laat loop. Die feit is dat enige moderne samesteller verskaf, alhoewel 'n klein stel waarskuwings oor potensiële probleme in die kode. Byvoorbeeld, wanneer jy C++-kode in Visual Studio saamstel, kan jy dalk die volgende sien:
In hierdie uitset sien ons dat die veranderlike was is nooit op enige plek in die funksie gebruik nie. So in werklikheid het jy amper altyd 'n eenvoudige statiese kode-ontleder gebruik. Anders as professionele ontleders soos Coverity, Klocwork of PVS-Studio, kan die waarskuwings wat deur die samesteller verskaf word, egter net 'n klein reeks probleme aandui.
As jy nie seker weet wat statiese analise is en hoe om dit te implementeer nie, om meer oor hierdie metodologie te leer.
Hoekom het jy statiese ontleding nodig?
In 'n neutedop: versnelling en vereenvoudiging.
Statiese analise laat jou toe om baie verskillende probleme in die kode te vind: van verkeerde gebruik van taalkonstrukte tot tikfoute. Byvoorbeeld, in plaas van
auto x = obj.x;
auto y = obj.y;
auto z = obj.z;Jy het die volgende kode geskryf:
auto x = obj.x;
auto y = obj.y;
auto z = obj.x;Soos jy kan sien, is daar 'n tikfout in die laaste reël. Byvoorbeeld, PVS-Studio reik die volgende waarskuwing uit:
Oorweeg om die korrektheid van 'y'-item se gebruik te hersien.
As jy jou hande in hierdie fout wil steek, probeer 'n klaargemaakte voorbeeld in Compiler Explorer: **.
En soos jy verstaan, is dit nie altyd moontlik om dadelik aandag te gee aan sulke gedeeltes van kode nie, en daarom kan jy vir 'n goeie uur sit en ontfouting en wonder hoekom alles so vreemd werk.
Dit is egter duidelik 'n fout. Wat as die ontwikkelaar suboptimale kode geskryf het omdat hy die subtiliteit van die taal vergeet het? Of selfs toegelaat om dit in die kode ? Ongelukkig is sulke gevalle heeltemal alledaags en word die grootste deel van die tyd bestee aan ontfouting van spesifiek werkende kode wat tikfoute, tipiese foute of ongedefinieerde gedrag bevat.
Dit is vir hierdie situasies dat statiese analise verskyn het. Dit is 'n assistent vir die ontwikkelaar wat verskeie probleme in die kode sal uitwys en in die dokumentasie sal verduidelik waarom dit nie nodig is om so te skryf nie, waartoe dit kan lei en hoe om dit reg te stel. Hier is 'n voorbeeld van hoe dit kan lyk: **.
U kan meer interessante foute vind wat die ontleder kan opspoor in die artikels:
Noudat jy hierdie materiaal gelees het en oortuig is van die voordele van statiese analise, wil jy dit dalk probeer. Maar waar om te begin? Hoe om 'n nuwe instrument in jou huidige projek te integreer? En hoe om die span aan hom voor te stel? Jy sal antwoorde op hierdie vrae hieronder vind.
Noot. Statiese analise vervang of kanselleer nie so 'n nuttige ding soos kode resensies nie. Dit vul hierdie proses aan en help om tikfoute, onakkuraathede en gevaarlike ontwerpe vooraf op te let en reg te stel. Dit is baie meer produktief om te fokus op kode-resensies op algoritmes en kode duidelikheid, eerder as om te soek na 'n misplaaste parentese of .
0. Om die instrument te leer ken
Dit begin alles met 'n proefweergawe. Inderdaad, dit is moeilik om te besluit om iets in die ontwikkelingsproses te implementeer as jy nog nooit die instrument regstreeks gesien het nie. Daarom is die eerste ding wat u moet doen, aflaai .
Wat jy op hierdie stadium sal leer:
- Wat is die maniere om met die ontleder te kommunikeer;
- Is die ontleder versoenbaar met jou ontwikkelingsomgewing?
- Watter probleme is daar tans in jou projekte?
Nadat jy alles geïnstalleer het wat jy nodig het, is die eerste ding wat jy moet doen 'n ontleding van die hele projek (, , ). In die geval van PVS-Studio in Visual Studio sal jy 'n soortgelyke prentjie sien (klikbaar):
Die feit is dat statiese ontleders gewoonlik 'n groot aantal waarskuwings uitreik vir projekte met 'n groot kodebasis. Dit is nie nodig om hulle almal reg te stel nie, aangesien u projek reeds werk, wat beteken dat hierdie probleme nie kritiek is nie. Jy egter en korrigeer dit indien nodig. Om dit te doen, moet jy die uitset filter en net die mees betroubare boodskappe laat. In die PVS-Studio-inprop vir Visual Studio word dit gedoen deur te filter volgens foutvlakke en kategorieë. Vir die mees akkurate uitset, laat slegs Hoogte и algemene (ook klikbaar):
Inderdaad, 178 waarskuwings is baie makliker om te sien as etlike duisende ...
In oortjies Medium и Laagte Dikwels is daar goeie waarskuwings, maar hierdie kategorieë sluit dié diagnostiek in wat minder akkuraatheid (betroubaarheid) het. Meer inligting oor waarskuwingsvlakke en opsies om onder Windows te werk, kan hier gevind word: **.
Dit is die moeite werd om die interessantste foute suksesvol te hersien (en suksesvol reg te stel). . Dit is nodig sodat nuwe waarskuwings nie tussen die oues verlore raak nie. Daarbenewens is 'n statiese ontleder 'n assistent vir die programmeerder, en nie 'n lys foute nie. 🙂
1. Outomatisering
Nadat u kennis gemaak het, is dit tyd om plugins op te stel en by CI te integreer. Dit moet gedoen word voordat programmeerders die statiese ontleder begin gebruik. Die feit is dat die programmeerder dalk vergeet om analise te aktiveer of dit glad nie wil doen nie. Om dit te doen, moet u 'n paar finale kontrole van alles doen sodat ongetoetste kode nie in die algemene ontwikkelingstak kan kom nie.
Wat jy op hierdie stadium sal leer:
- Watter outomatiseringsopsies bied die instrument;
- Is die ontleder versoenbaar met jou monteerstelsel?
Aangesien perfekte dokumentasie nie bestaan nie, moet jy soms inskryf . Dit is normaal en ons help jou graag. 🙂
Kom ons gaan nou oor na deurlopende integrasie (CI) dienste. Enige ontleder kan sonder enige ernstige probleme daarin geïmplementeer word. Om dit te doen, moet jy 'n aparte stadium in die pyplyn skep, wat gewoonlik na die bou- en eenheidstoetse geleë is. Dit word gedoen met behulp van verskeie konsole-nutsprogramme. Byvoorbeeld, PVS-Studio bied die volgende nutsprogramme:
- (ontleding van oplossings, C#, C++ projekte op Windows)
- (samestelling monitering)
- (ontleding van C++-projekte op Linux / macOS)
- (oplossingsanalise, C#-projekte op Linux / macOS)
- (ontleding van Java-projekte)
- (verslaglêer-omskakelaar)
Om analise in CI te integreer, moet jy drie dinge doen:
- Installeer die ontleder;
- Loop analise;
- Lewer resultate.
Byvoorbeeld, om PVS-Studio op Linux (Debian-base) te installeer, moet jy die volgende opdragte uitvoer:
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-studioOp stelsels wat Windows gebruik, is daar geen manier om die ontleder vanaf die pakketbestuurder te installeer nie, maar dit is moontlik om die ontleder vanaf die opdragreël te ontplooi:
PVS-Studio_setup.exe /verysilent /suppressmsgboxes
/norestart /nocloseapplicationsU kan meer lees oor die implementering van PVS-Studio op stelsels wat Windows gebruik **.
Na die installasie moet u die ontleding direk uitvoer. Dit word egter aanbeveel om dit eers te doen nadat samestelling en toetse geslaag het. Dit is omdat statiese analise tipies twee keer so lank neem as samestelling.
Aangesien die bekendstellingsmetode afhang van die platform- en projekkenmerke, sal ek die opsie vir C++ (Linux) as voorbeeld wys:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
plog-converter -t errorfile PVS-Studio.log --cerr -wDie eerste opdrag sal die analise uitvoer, en die tweede skakel die verslag om in teksformaat, vertoon dit op die skerm en gee 'n ander terugkeerkode as 0 terug as daar waarskuwings is. 'n Meganisme soos hierdie kan gerieflik gebruik word om 'n bou te blokkeer wanneer daar foutboodskappe is. Jy kan egter altyd die vlag verwyder -w en moenie 'n samestelling blokkeer wat waarskuwings bevat nie.
Noot. Die teksformaat is ongerieflik. Dit word bloot as voorbeeld verskaf. Gee aandag aan 'n meer interessante verslagformaat - FullHtml. Dit laat jou toe om deur die kode te navigeer.
Jy kan meer lees oor die opstel van analise op CI in die artikel "" (Windows) of "" (Linux).
Goed, jy het die ontleder op die boubediener gekonfigureer. Nou, as iemand ongetoetste kode opgelaai het, sal die verifikasie stadium misluk, en jy sal die probleem kan opspoor, maar dit is nie heeltemal gerieflik nie, aangesien dit meer doeltreffend is om die projek na te gaan nie nadat die takke saamgevoeg is nie, maar voor dit, by die trekversoekstadium. A.
Oor die algemeen verskil die opstel van 'n trekversoek-analise nie veel van die gewone bekendstelling van 'n analise op CI nie. Behalwe vir die behoefte om 'n lys van veranderde lêers te kry. Dit kan gewoonlik verkry word deur die verskille tussen takke met behulp van git navraag te doen:
git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.listNou moet jy hierdie lys lêers as invoer na die ontleder deurgee. Byvoorbeeld, in PVS-Studio word dit geïmplementeer deur die vlag te gebruik -S:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
-S .pvs-pr.listJy kan meer uitvind oor die ontleding van trekversoeke **. Selfs al is jou CI nie op die lys van dienste wat in die artikel genoem word nie, sal jy die algemene afdeling gewy aan die teorie van hierdie tipe analise nuttig vind.
Deur ontleding van trekversoeke op te stel, kan jy commits blokkeer wat waarskuwings bevat, en sodoende 'n grens skep wat ongetoetste kode nie kan oorsteek nie.
Dit is alles beslis goed, maar ek wil graag al die waarskuwings op een plek kan sien. Nie net van die statiese ontleder nie, maar ook van eenheidstoetse of van die dinamiese ontleder. Daar is verskeie dienste en plugins hiervoor. PVS-Studio het byvoorbeeld .
2. Integrasie op ontwikkelaarmasjiene
Nou is dit tyd om die ontleder te installeer en op te stel vir alledaagse ontwikkelingsgebruik. Teen hierdie tyd het jy reeds vertroud geraak met die meeste van die maniere van werk, so dit kan die maklikste deel genoem word.
As die eenvoudigste opsie kan ontwikkelaars self die nodige ontleder installeer. Dit sal egter baie tyd neem en hulle aandag van ontwikkeling aftrek, sodat jy hierdie proses kan outomatiseer met behulp van 'n installeerder en die nodige vlae. Vir PVS-Studio is daar verskeie . Daar is egter altyd pakketbestuurders, byvoorbeeld Chocolatey (Windows), Homebrew (macOS) of dosyne opsies vir Linux.
Dan sal jy die nodige plugins moet installeer, byvoorbeeld vir , , ens.
3. Daaglikse gebruik
Op hierdie stadium is dit tyd om 'n paar woorde te sê oor maniere om die ontleder tydens daaglikse gebruik te bespoedig. ’n Volledige ontleding van die hele projek neem baie tyd in beslag, maar hoe gereeld verander ons kode deur die hele projek gelyktydig? Daar is skaars enige herfaktorering wat so groot is dat dit onmiddellik die hele kodebasis sal beïnvloed. Die aantal lêers wat op 'n slag verander word, oorskry selde 'n dosyn, so dit maak sin om hulle te ontleed. Vir so 'n situasie is daar . Moet net nie bekommerd wees nie, dit is nie 'n ander hulpmiddel nie. Dit is 'n spesiale modus waarmee jy slegs veranderde lêers en hul afhanklikhede kan ontleed, en dit gebeur outomaties nadat jy gebou het as jy in 'n IDE werk met die inprop geïnstalleer.
As die ontleder probleme in die onlangs veranderde kode opspoor, sal dit dit onafhanklik rapporteer. Byvoorbeeld, PVS-Studio sal jou hiervan vertel deur 'n waarskuwing te gebruik:
Dit is natuurlik nie genoeg om ontwikkelaars te vertel om die instrument te gebruik nie. Ons moet op een of ander manier vir hulle vertel wat dit is en hoe dit is. Hier is byvoorbeeld artikels oor 'n vinnige begin vir PVS-Studio, maar jy kan soortgelyke tutoriale vind vir enige instrument wat jy verkies:
Sulke artikels verskaf al die inligting wat nodig is vir alledaagse gebruik en neem nie veel tyd in beslag nie. 🙂
Selfs in die stadium om die instrument te leer ken, het ons baie waarskuwings onderdruk tydens een van die eerste bekendstellings. Ongelukkig is statiese ontleders nie perfek nie, so van tyd tot tyd gee hulle vals positiewes. Dit is gewoonlik maklik om hulle te onderdruk; byvoorbeeld, in die PVS-Studio-inprop vir Visual Studio hoef jy net een knoppie te klik:
Jy kan egter meer doen as om hulle net te onderdruk. U kan byvoorbeeld 'n probleem by ondersteuning aanmeld. As die vals positiewe reggestel kan word, kan u in toekomstige opdaterings agterkom dat daar elke keer minder en minder vals positiewe spesifiek vir u kodebasis is.
Na integrasie
Ons het dus deur al die stadiums gegaan om statiese analise in die ontwikkelingsproses te integreer. Ten spyte van die belangrikheid daarvan om sulke instrumente op CI op te stel, is die belangrikste plek om dit te laat loop die ontwikkelaar se rekenaar. 'n Statiese ontleder is immers nie 'n regter wat iewers ver van jou af sê dat die kode nie goed is nie. Inteendeel, dit is ’n assistent wat vir jou sê as jy moeg is en jou herinner as jy iets vergeet het.
Dit is waar, sonder gereelde gebruik, is dit onwaarskynlik dat statiese analise ontwikkeling aansienlik sal vereenvoudig. Die grootste voordeel daarvan vir 'n ontwikkelaar lê immers nie soseer in die soeke na komplekse en kontroversiële dele van kode nie, maar in die vroeë opsporing daarvan. Stem saam dat dit nie net onaangenaam is om 'n probleem te ontdek nadat die wysigings vir toetsing gestuur is nie, maar ook baie tydrowend. Statiese analise, wanneer dit gereeld gebruik word, kyk na elke verandering direk op jou rekenaar en rapporteer verdagte plekke terwyl jy aan die kode werk.
En as jy of jou kollegas nog nie seker is of dit die moeite werd is om die ontleder te implementeer nie, stel ek voor dat jy nou die artikel begin lees ""Dit spreek tipiese bekommernisse van ontwikkelaars aan dat statiese analise hul tyd sal neem en so aan.
As jy hierdie artikel met 'n Engelssprekende gehoor wil deel, gebruik asseblief die vertaalskakel: Maxim Zvyagintsev. .
Bron: will.com