Ew hêsan e ku meriv analîzek kodek statîk biceribîne. Lê ji bo pêkanîna wê, nemaze di pêşvebirina projeyek mezin a kevn de, jêhatîbûn hewce dike. Ger bi xeletî were kirin, analîzer dikare xebatê zêde bike, pêşveçûnê hêdî bike, û tîmê demotîv bike. Ka em bi kurtî biaxivin ka meriv çawa bi rêkûpêk nêzikî yekbûna analîza statîk di pêvajoya pêşkeftinê de dibe û dest bi karanîna wê wekî beşek CI/CD-ê dike.
Pîrozbahiyê
Di van demên dawî de bala min kişand ser weşana "". Ji aliyekî ve, ev gotarek baş e ku hêja ye ku pê were nas kirin. Ji hêla din ve, ji min re xuya dike ku ew hîn jî bersivek bêkêmasî nade ka meriv çawa di projeyek pir pir de analîza statîk bi rengek bê êş bicîh tîne. ji koda mîrasê gotar dibêje ku hûn dikarin deynê teknîkî qebûl bikin û tenê li ser koda nû bixebitin, lê bersivek tune ku hûn paşê bi vî deynê teknîkî re bikin.
Tîma meya PVS-Studio li ser vê mijarê nêrîna xwe pêşkêşî dike. Ka em binihêrin ka di rêza yekem de pirsgirêka pêkanîna analîzatorek kodê statîk çawa derdikeve, meriv çawa vê pirsgirêkê derbas dike, û meriv çawa hêdî hêdî hêdî hêdî deynê teknîkî ji holê radike.
Issues
Bi gelemperî ne dijwar e ku meriv dest pê bike û bibîne ka analîzkerek statîk çawa dixebite []. Hûn dikarin di kodê de xeletiyên balkêş an jî qelsiyên potansiyel ên tirsnak bibînin. Tewra hûn dikarin tiştek rast bikin, lê paşê gelek bernamenûs dev jê berdidin.
Hemî analîzerên statîk pozîtîfên derewîn çêdikin. Ev taybetmendiyek metodolojiya analîzkirina koda statîk e, û tiştek li ser wê nayê kirin. Di rewşa giştî de, ev pirsgirêkek bêçareser e, wekî ku ji hêla teorema Rice ve hatî pejirandin []. Algorîtmayên fêrbûna makîneyê jî dê nebin alîkar []. Ger kesek her gav nikaribe bêje ka ev an ew kod xelet e, wê hingê divê hûn vê ji bernameyê hêvî nekin :).
Ger analyzera statîk jixwe hatî mîheng kirin, pozîtîfên derewîn ne pirsgirêk in:
- Komên qaîdeyên negirêdayî yên astengdar;
- Hin tespîtên negirêdayî hatine asteng kirin;
- Ger em li ser C an C++ dipeyivin, wê hingê makro têne nîşankirin ku avahiyên taybetî hene ku dibin sedem ku hişyariyên bêkêr li her cihê ku makroyên weha têne bikar anîn xuya bibin;
- Fonksiyonên xwe têne nîşankirin ku çalakiyên mîna fonksiyonên pergalê pêk tînin (analoga xwe memcpy an printf) [];
- Pozîtîvên derewîn bi taybetî bi karanîna şîroveyan têne asteng kirin;
- Û vî awayî.
Di vê rewşê de, em dikarin li bendê bin ku rêjeya erênî ya derewîn a kêm bi qasî 10-15% []. Bi gotinek din, 9 ji 10 hişyariyên analîzer dê di kodê de pirsgirêkek rastîn, an bi kêmanî "kodê bi bîhnxweş" destnîşan bikin. Bipejirînim, ev senaryo pir xweş e, û analîzer hevalek rastîn a bernamenûs e.
Di rastiyê de, di projeyek mezin de, wêneya destpêkê dê bi tevahî cûda be. Analîzator ji bo koda mîras bi sedan an bi hezaran hişyarî dide. Ne gengaz e ku meriv zû fêm bike ka kîjan ji van hişyariyan têkildar in û kîjan ne. Bêaqil e ku meriv rûnin û bi van hemî hişyariyan re mijûl bibin, ji ber ku xebata sereke di vê rewşê de dê bi rojan an hefteyan raweste. Bi gelemperî, tîmek nikare senaryoyek weha bigire. Di heman demê de dê gelek cûdahiyên ku dîroka guherînê xera dikin jî hebin. Û guherandina girseyî ya bilez a ewqas perçeyên di kodê de bê guman dê bibe sedema xeletî û xeletiyên nû.
Û ya herî girîng, serkeftinek wusa di şerê li dijî hişyariyan de hindik maqûl e. Bipejirînin ku ji ber ku proje gelek salan bi serfirazî dimeşe, piraniya xeletiyên krîtîk ên di wê de berê hatine rast kirin. Erê, ev serrastkirin pir biha bûn, diviyabû bihatana debugkirin, di derheqê xeletiyan de nerînên bikarhêner ên neyînî wergirin û hwd. Analîzerek statîk dê bibe alîkar ku gelek ji van xeletiyan di qonaxa kodkirinê de, zû û erzan rast bikin. Lê heya niha, bi rengekî an din, ev xeletî hatine rast kirin, û analîzer bi gelemperî di koda kevn de xeletiyên ne-krîtîk tespît dike. Dibe ku ev kod neyê bikar anîn, dibe ku pir kêm were bikar anîn, û xeletiyek di wê de dibe ku bibe sedema encamên berbiçav. Dibe ku li cîhek siya ji bişkojê rengê xelet be, lê ev yek di karanîna kesek hilberê de asteng nake.
Bê guman, xeletiyên piçûk jî dîsa jî xelet in. Û carinan xeletiyek dikare qelsiyek rastîn veşêre. Lêbelê, dev ji her tiştî berdin û bi rojan/hefteyan re mijûlbûna bi kêmasiyên ku bi zor xwe diyar dikin, wekî ramanek gumanbar xuya dike.
Bernamesaz li van hemî hişyariyên li ser koda xebatê ya kevin dinêrin, dinêrin, lê dinêrin... Û ew difikirin: em dikarin bêyî analîzên statîk bikin. Ka em biçin hin fonksiyonên nû yên kêrhatî binivîsin.
Bi awayê xwe, ew rast in. Ew fehm dikin ku pêşî divê ew bi rengekî ji van hemî hişyariyan xilas bibin. Tenê wê hingê ew ê bikaribin ji karanîna birêkûpêk a analîzera kodê sûd werbigirin. Wekî din, hişyariyên nû dê bi tenê di yên kevin de xeniqin, û kes guh nade wan.
Ev heman analogî ye ku bi hişyariyên berhevkar re ye. Ne bê sedem e ku ew pêşniyar dikin ku hijmara hişyariyên berhevkar di 0 de bimîne. Ger 1000 hişyarî hebin, wê demê gava ku 1001 hebin, kes guh nade wê, û ne diyar e ku meriv li vê hişyariya herî nû li ku bigere.
Di vê çîrokê de tiştê herî xirab ev e ku kesek ji jor di vê gavê de we mecbûr dike ku hûn analîza koda statîk bikar bînin. Ev ê tenê tîmê demotîf bike, ji ber ku ji nêrîna wan dê tevliheviyek burokratîk a zêde hebe ku tenê rê li ber digire. Dê kes li raporên analîzer mêze neke, û hemî karanîna wê tenê "li ser kaxezê" be. Ewan. Bi fermî, analîz di pêvajoya DevOps de tête çêkirin, lê di pratîkê de ev yek bi kêrî kesî nayê. Me ji beşdarên konferansê çîrokên bi hûrgilî li standan bihîst. Tecrûbeyek weha dikare bernamenûsan ji karanîna amûrên analîzên statîk ji bo demek dirêj, heke ne her û her, nehêle.
Bicîhkirin û rakirina deynê teknîkî
Di rastiyê de, di danasîna analîzên statîk de jî di nav projeyek mezin a kevn de tiştek dijwar an tirsnak tune.
CI / CD
Digel vê yekê, analîzer tavilê dikare bibe beşek ji pêvajoya pêşkeftina domdar. Mînakî, belavkirina PVS-Studio ji bo bi rehetî temaşekirina raporê bi forma ku hûn hewce ne, û ji pêşdebiran re ku beşên pirsgirêk ên kodê nivîsandine re agahdariyan vedihewîne. Ji bo kesên ku bêtir eleqedar in ku PVS-Studio ji pergalên CI/CD dest pê bikin, ez pêşniyar dikim ku hûn xwe bi pêwendiya têkildar re nas bikin. belge û rêze gotar:
Lê em vegerin ser mijara hejmareke mezin a erênîyên derewîn di qonaxên yekem ên bicîhkirina amûrên analîzkirina kodê de.
Rastkirina deynê teknîkî yê heyî û mijûlbûna bi hişyariyên nû
Analîzatorên statîk ên bazirganî yên nûjen dihêlin hûn tenê hişyariyên nû yên ku di koda nû an guhertî de xuya dibin bixwînin. Pêkanîna vê mekanîzmayê diguhere, lê esas yek e. Di analîzera statîk a PVS-Studio de, ev fonksiyon bi vî rengî tête bicîh kirin.
Ji bo ku zû dest bi karanîna analîzên statîk bikin, em pêşniyar dikin ku bikarhênerên PVS-Studio mekanîzmaya tepeserkirina girseyî ya hişyariyan bikar bînin []. Fikra giştî li jêr e. Bikarhêner analîzker dest pê kir û gelek hişyarî wergirt. Ji ber ku projeyek ku bi salan di pêşkeftinê de ye zindî ye, pêşve diçe û drav dike, wê hingê bi îhtîmalek mezin dê di raporê de gelek hişyarî nebin ku kêmasiyên krîtîk destnîşan dikin. Bi gotinek din, xeletiyên krîtîk jixwe bi rengekî an yekî din bi karanîna rêbazên bihatir an spas ji bertekên xerîdar re hatine rast kirin. Li gorî vê yekê, her tiştê ku analîzer niha dibîne dikare deynê teknîkî were hesibandin, ku nepraktîk e ku meriv hewl bide tavilê jê bibe.
Hûn dikarin ji PVS-Studio re bêjin ku van hişyariyan ji bo nuha ne girîng bihesibîne (deynê teknîkî ji bo paşê hilîne), û ew ê êdî wan nîşan nede. Analîzker pelek taybetî diafirîne ku li wir agahdariya li ser xeletiyên ku hîn ne balkêş in hilîne. Û naha PVS-Studio dê tenê ji bo koda nû an guhertî hişyariyan bide. Ji bilî vê, ev hemû bi aqilane pêk tê. Ger, bo nimûne, xêzek vala li destpêka pelê koda çavkaniyê were zêdekirin, wê hingê analîzer fam dike ku, bi rastî, tiştek neguheriye, û dê bêdeng bimîne. Ev pelê nîşankirinê dikare di pergala kontrola guhertoyê de were danîn. Pelê mezin e, lê ev ne pirsgirêk e, ji ber ku pir caran hilanîna wê tune ye.
Naha hemî bernamenûs dê hişyariyên ku tenê bi koda nû an guhertî ve girêdayî ne bibînin. Bi vî rengî, hûn dikarin ji roja din dest bi karanîna analyzerê bikin, wekî ku ew dibêjin. Û hûn dikarin paşê vegerin deynê teknîkî, û hêdî hêdî xeletiyan rast bikin û analîzkerê mîheng bikin.
Ji ber vê yekê, pirsgirêka yekem a pêkanîna analîzerê di projeyek mezin a kevn de çareser bûye. Naha em fêr bibin ka meriv bi deynê teknîkî re çi bike.
Çareserkirina bug û refactorings
Tişta herî hêsan û xwezayî ev e ku meriv demek veqetîne da ku hişyariyên analîzker ên bi girseyî hatine tepisandin analîz bike û hêdî hêdî bi wan re mijûl bibe. Li deverek divê hûn di kodê de xeletiyên rast bikin, li cîhek divê hûn ji analîzkerê re bibêjin ku kod ne pirsgirêk e. Mînakek hêsan:
if (a = b)Piraniya berhevkar û analîzkerên C++ ji kodek weha gilî dikin, ji ber ku îhtîmalek mezin heye ku wan bi rastî dixwestin binivîsin. (a == b). Lê peymanek negotî heye, û ev bi gelemperî di belgenameyê de tê destnîşan kirin, ku heke parantezên din jî hebin, wê hingê tê hesibandin ku bernamenûs bi qestî kodek weha nivîsandiye, û ne hewce ye ku sond bixwe. Mînakî, di belgeya PVS-Studio de ji bo tespîtkirinê bi zelalî hatiye nivîsandin ku rêzika jêrîn dê rast û ewle were hesibandin:
if ((a = b))Mînakek din. Ma ew di vê koda C ++ de ji bîr kiriye? şikesta an na?
case A:
foo();
case B:
bar();
break;Analîzatora PVS-Studio dê li vir hişyariyek bide . Dibe ku ev ne xeletiyek be, di vê rewşê de divê hûn bi lêzêdekirina taybetmendiyê îşaretekê bidin parserê an, wek nimûne, __taybetî__((hilweşîn)):
case A:
foo();
[[fallthrough]];
case B:
bar();
break;Dikare were gotin ku guhertinên kodê yên weha xeletiyê rast nakin. Erê, ev rast e, lê ew du tiştên kêrhatî dike. Pêşîn, raporta analîstê ji erênîyên derewîn xilas dibe. Ya duyemîn, kod ji bo kesên ku di domandina wê de beşdar dibin bêtir tê fêm kirin. Û ev pir girîng e! Ji bo vê yekê tenê, hêja ye ku nûvekirinên piçûk werin kirin da ku kod zelaltir û parastinê hêsantir bikin. Ji ber ku analîzer fam nake ka "şikestin" hewce ye an na, ew ê ji bernamenûsan re jî ne diyar be.
Digel rastkirin û vesazkirina xeletiyan, hûn dikarin bi taybetî hişyariyên analîstê yên eşkere derewîn bişkînin. Hin teşhîsên negirêdayî dikarin bên asteng kirin. Mînakî, kesek difikire ku hişyarî bêwate ne di derbarê berhevdana nirxên float / ducar de. Û hinek jî wan wekî girîng û hêjayî xwendinê dabeş dikin []. Kîjan hişyarî têkildar têne hesibandin û kîjan ne girêdayî tîmê pêşveçûnê ye ku biryar bide.
Rêyên din jî hene ku hişyariyên derewîn tepeser bikin. Mînakî, nîşankirina makro berê hate behs kirin. Hemî ev bi hûrgulî di belgeyê de tête diyar kirin. Ya herî girîng ev e ku hûn fêm bikin ku heke hûn hêdî hêdî û bi rêkûpêk nêzikî xebata bi pozîtîfên derewîn bibin, tiştek di wan de tune. Piraniya hişyariyên nebalkêş piştî veavakirinê winda dibin, û tenê cîhên ku bi rastî hewceyê lêkolînek baldar û hin guhertinên di kodê de ne dimînin.
Di heman demê de, em her gav ji xerîdarên xwe re dibin alîkar ku PVS-Studio saz bikin heke dijwariyek çêbibe. Wekî din, rewş hebûn ku me bixwe hişyariyên derewîn ji holê rakir û xeletî rast kir []. Tenê di rewşê de, min biryar da ku behs bikim ku ev vebijark ji bo hevkariya berfireh jî gengaz e :).
Rêbaza Ratchet
Nêzîkatiyek din a balkêş heye ku hêdî hêdî kalîteya kodê bi rakirina hişyariya analîstê statîk çêtir bike. Rêza jêrîn ev e ku hejmara hişyariyan tenê dikare kêm bibe.
Hejmara hişyariyên ku ji hêla analyzera statîk ve têne şandin têne tomar kirin. Deriyê kalîteyê bi vî rengî tête mîheng kirin ku naha hûn tenê dikarin kodek têkevin ku hejmara operasyonan zêde nake. Wekî encamek, pêvajoya kêmkirina hêdî hêdî hejmara alarman bi sererastkirina analîzer û rastkirina xeletiyan dest pê dike.
Tewra ku kesek bixwaze piçek bixapîne û biryar bide ku ne bi rakirina hişyariyên di koda xweya nû de, lê bi baştirkirina koda sêyemîn-a kevn, deriyê kalîteyê derbas bike, ev ne tirsnak e. Di heman demê de, ratchet di yek alî de dizivire, û hêdî hêdî dê hejmara kêmasiyan kêm bibe. Tewra ku kesek nexwaze kêmasiyên xwe yên nû rast bike, ew ê dîsa jî di koda cîran de tiştek çêtir bike. Di hin xalan de, awayên hêsan ên kêmkirina hejmara hişyariyan bi dawî dibin, û xalek tê ku xeletiyên rastîn werin rast kirin.
Ev metodolojî di gotarek pir balkêş a Ivan Ponomarev de bi hûrgulî tête diyar kirin.", ku ez ji her kesê re eleqedar e ku bi baştirkirina kalîteya kodê re bixwîne pêşniyar dikim.
Nivîskarê gotarê jî di vê mijarê de raporek heye: "".
encamê
Ez hêvî dikim ku piştî vê gotarê, xwendevan dê amûrên analîzên statîk bêtir bipejirînin û dê bixwazin ku wan di pêvajoya pêşkeftinê de bicîh bikin. Ger pirsên we hebin, em her gav amade ne bikarhênerên analyzera meya statîk PVS-Studio û di pêkanîna wê de dibin alîkar.
Gumanên din ên tîpîk hene ku gelo analîza statîk bi rastî dikare hêsan û kêrhatî be. Min hewl da ku piraniya van gumanan di weşana "Sedemên danasîna analyzera koda statîk a PVS-Studio di pêvajoya pêşkeftinê de" ji holê rakim [].
Spas ji bo baldariya we û hatin û analîzerê PVS-Studio biceribînin.
girêdan Additional
- Andrey Karpov.
- Wikipedia. .
- Andrey Karpov, Victoria Khanieva. .
- PVS-Studio. Documentation. .
- Andrey Karpov. .
- PVS-Studio. Documentation. .
- Ivan Andryashin. .
- Pavel Eremeev, Svyatoslav Razmyslov. .
- Andrey Karpov. .
Heke hûn dixwazin vê gotarê bi temaşevanên îngilîzîaxêv re parve bikin, ji kerema xwe lînka wergerê bikar bînin: Andrey Karpov. .
Source: www.habr.com