Ji min hate xwestin ku ez vê gotarê binivîsim ji hêla gelek materyalên li ser analîzên statîk ên ku her ku diçe bala min tê. Ya yekem, ev , ku bi arîkariya nirxandinên xeletiyên ku ji hêla amûra wan ve di projeyên çavkaniya vekirî de têne dîtin bi çalak xwe li ser Habré pêşve dixe. Di van demên dawî de PVS-studio hate pêkanîn , û, bê guman, pêşdebirên IntelliJ IDEA, ku analyzera çêkirî ya ku belkî îro ji bo Java ya herî pêşkeftî ye, .
Dema ku nirxandinên weha dixwînin, hûn hest dikin ku em li ser elîxirek sêrbaz diaxivin: bişkojkê bikirtînin, û li vir ew e - navnîşek kêmasiyan li ber çavên we. Wusa dixuye ku her ku analîzer çêtir dibin, dê bêtir û bêtir xeletî bixweber werin dîtin, û hilberên ku ji hêla van robotan ve têne şopandin dê çêtir û çêtir bibin, bêyî ku ti hewldanek ji hêla me ve hebe.
Lê elîxirên sêrbaz tune. Ez dixwazim li ser tiştê ku bi gelemperî di postên wekî "li vir tiştên ku robotê me dikare bibîne" de nayê axaftin biaxivim: analîzator nekare çi bike, di pêvajoya radestkirina nermalavê de rola wan û cîhê wan ê rastîn çi ye, û meriv çawa wan bi rengek rast bicîh tîne .
Ratchet (çavkanî: ).
Tiştê ku analîzerên statîk qet nikarin bikin
Analîzkirina koda çavkaniyê, ji nêrînek pratîkî çi ye? Em hin koda çavkaniyê wekî têketinê pêşkêş dikin, û wekî encam, di demek kurt de (ji ceribandinên xebitandinê pir kurttir) em di derheqê pergala xwe de hin agahdarî digirin. Sînordariya bingehîn û ji hêla matematîkî ve nayê derbas kirin ev e ku em dikarin bi vî rengî tenê çînek pir teng agahiyê bi dest bixin.
Mînaka herî navdar a pirsgirêkek ku bi analîza statîk nayê çareser kirin ev e : Ev teoremek e ku îsbat dike ku ne mimkûn e ku algorîtmayek giştî were pêşve xistin ku bikare ji koda çavkaniya bernameyekê diyar bike ka ew ê di demek bêdawî de biqelişe an biqede. Berfirehkirina vê teoremê ye , ku diyar dike ku ji bo her taybetmendiyek ne-pîwan a fonksiyonên hesabker, destnîşankirina ka bernameyek keyfî fonksiyonek bi taybetmendiyek wusa dinirxîne pirsgirêkek algorîtmîkî ya neçar e. Mînakî, ne mimkûn e ku meriv analîzerek binivîsîne ku bikaribe ji her kodek çavkaniyê diyar bike ka bernameya ku tê analîz kirin pêkanîna algorîtmayek e ku, bêje, çargoşekirina jimarek tevahî hesab dike.
Bi vî rengî, fonksiyona analîzkerên statîk xwedan tixûbên bêserûber e. Analîzatorek statîk dê çu carî nikaribe di hemî rewşan de tiştên wekî, mînakî, peydabûna "îstîsna nîşana null" di zimanên ku destûrê dide nirxa null, an di hemî rewşan de diyar bike ku bûyerek "teşhîs bike. taybetmendî nehat dîtin" di zimanên dînamîkî de tîpkirî. Tiştê ku analîzkera statîk a herî pêşkeftî dikare bike ev e ku dozên taybetî ronî bike, ku hejmara wan, di nav hemî pirsgirêkên gengaz ên bi koda çavkaniya we de, bê zêdegavî, di nav kelekek de ye.
Analîza statîk ne li ser dîtina xeletiyan e
Ji jor ve, encam wiha ye: analîza statîk ne amûrek kêmkirina hejmara kêmasiyên di bernameyekê de ye. Ez cesaretê didim ku bêjim: gava ku yekem car li projeya we were sepandin, ew ê di kodê de cîhên "balkêş" bibîne, lê, bi îhtîmalek mezin, ew ê ti kêmasiyên ku bandorê li kalîteya bernameya we bike nebîne.
Nimûneyên kêmasiyên ku bixweber ji hêla analyzeran ve têne dîtin balkêş in, lê divê em ji bîr nekin ku ev mînak bi şopandina komek mezin a bingehên kodên mezin hatine dîtin. Bi heman prensîbê, hackerên ku derfeta wan heye ku çend şîfreyên hêsan li ser hejmareke mezin ji hesaban biceribînin, di dawiyê de wan hesabên ku şîfreyek sade heye bibînin.
Ma ev tê wê wateyê ku analîzên statîk nayên bikar anîn? Helbet na! Û ji ber heman sedemê ku hêja ye ku her şîfreyek nû kontrol bikin da ku pê ewle bibin ku ew di navnîşa rawestandina şîfreyên "hêsan" de ye.
Analîza statîk ji dîtina xeletiyan wêdetir e
Bi rastî, pirsgirêkên ku di pratîkê de bi analîzê têne çareser kirin pir berfireh in. Beriya her tiştî, bi gelemperî, analîza statîk her verastkirina kodên çavkaniyê ye ku berî destpêkirina wan têne kirin. Li vir çend tişt hene ku hûn dikarin bikin:
- Kontrolkirina şêwaza kodkirinê di wateya berfireh a peyvê de. Di vê yekê de hem kontrolkirina formatkirinê, hem lêgerîna li karanîna parantezên vala/zêde, hem danîna bendên li ser metrîkan ên wekî hejmara rêzan/tevliheviya cyclomatic ya rêbazê, hwd. - her tiştê ku bi potansiyel xwendin û domandina kodê asteng dike. Di Java de, amûrek weha Checkstyle e, di Python de - flake8. Bernameyên vê polê bi gelemperî "linters" têne gotin.
- Ne tenê koda darvekirî dikare were analîz kirin. Pelên çavkaniyê yên wekî JSON, YAML, XML, .taybetmendî dikarin (û divê!) bixweber ji bo derbasbûnê werin kontrol kirin. Beriya her tiştî, çêtir e ku meriv fêr bibe ku strukturê JSON ji ber hin bêjeyên nehevkirî di qonaxek destpêkê ya verastkirina Daxwaza Vekêşana otomatîkî de ji dema ceribandinê an dema xebitandinê de şikestiye? Amûrên minasib hene: mînak. , .
- Berhevkirin (an parsek ji bo zimanên bernamesaziya dînamîkî) jî celebek analîzek statîk e. Bi gelemperî, berhevkar dikarin hişyariyên ku pirsgirêkên bi kalîteya koda çavkaniyê destnîşan dikin çêbikin û divê neyê paşguh kirin.
- Carinan berhevkirin ji berhevkirina koda darvekirinê wêdetir e. Mînakî, heke we belgeyek di formatê de hebe , dûv re di dema zivirîna wê di nav HTML/PDF-ê de hilgirê AsciiDoctor () dikare hişyariyan bide, mînakî, li ser girêdanên navxweyî yên têkçûyî. Û ev sedemek baş e ku hûn Daxwaza Bikişînê bi guhertinên belgekirinê re qebûl nekin.
- Kontrolkirina rastnivîsê jî celebek analîzek statîk e. Utility dikare rastnivîsînê ne tenê di belgenameyê de, lê di heman demê de di kodên çavkaniya bernameyê de (şîrove û biwêj) bi zimanên bernamesaziyê yên cihêreng, di nav de C/C++, Java û Python jî kontrol bike. Di navrûya bikarhêner an belgenameyê de xeletiyek rastnivîsînê jî kêmasiyek e!
- Testên vesazkirinê (li ser çi ne - binêre. и rapor), her çend di dema ceribandinek yekîneyek wekî pytest de têne darve kirin jî, di rastiyê de celebek analîzek statîk jî ne, ji ber ku ew di dema darvekirina xwe de kodên çavkaniyê pêk naynin.
Wekî ku hûn dikarin bibînin, lêgerîna xeletiyan di vê navnîşê de rola herî hindik dilîze, û her tiştê din bi karanîna amûrên çavkaniya vekirî ya belaş peyda dibe.
Divê hûn kîjan ji van celeb analîzên statîk di projeya xwe de bikar bînin? Bê guman, çiqas bêtir çêtir e! Ya sereke ev e ku meriv wê rast bicîh bîne, ku dê bêtir were nîqaş kirin.
Xeta radestkirinê wekî parzûnek pir-qonaxê û analîza statîk wekî qonaxa yekem
Metafora klasîk a ji bo yekbûna domdar rêgezek e ku tê de guhertin diherikin, ji guhertina koda çavkaniyê bigire heya radestkirinê heya hilberînê. Rêzeya standard a qonaxan di vê boriyê de wiha xuya dike:
- analîzên statîk
- kompilyaciya
- testên yekîneyê
- testên entegrasyonê
- testên UI
- kontrol manual
Guhertinên ku di qonaxa N-emîn a boriyê de hatine red kirin, ji qonaxa N+1 re nayên veguheztin.
Çima tam bi vî awayî û ne wekî din? Di beşa ceribandinê ya boriyê de, ceribandin dê pîramîda ceribandinê ya naskirî nas bikin.
Pyramid Test. Kanî: Martin Fowler.
Di binê vê pîramîdê de ceribandinên ku hêsantir têne nivîsandin, zûtir têne darve kirin û meyla wan a têkçûnê tune ye. Ji ber vê yekê, divê ji wan zêdetir hebin, divê ew bêtir kodê veşêrin û pêşî bêne darve kirin. Li serê pîramîdê, berevajî rast e, ji ber vê yekê divê hejmara entegrasyonê û testên UI-ê di hindiktirîn hewce de were kêm kirin. Kesê di vê zincîrê de çavkaniya herî biha, hêdî û ne pêbawer e, ji ber vê yekê ew di dawiya dawiyê de ye û tenê heke qonaxên berê tu kêmasiyek nedîtibe, kar dike. Lêbelê, heman prensîb ji bo avakirina boriyek li beşên ku rasterast bi ceribandinê re têkildar ne têne bikar anîn!
Ez dixwazim di şiklê pergalek parzûna avê ya pir-qonaxê de analojiyek pêşkêşî bikim. Ava pîs (guhertinên bi kêmasiyan re) ji têketinê re tê peyda kirin; di dergehê de divê em ava paqij werbigirin, ku tê de hemî gemarên nexwestî ji holê rabin.
Parzûna pir-qonaxa. Kanî:
Wekî ku hûn dizanin, fîlterên paqijkirinê bi vî rengî têne sêwirandin ku her kaskadek paşîn dikare perçeyek her ku diçe hûrtir ji gemaran fîltre bike. Di heman demê de, kaskadên paqijkirina qehweyî xwedan karûbarê bilind û lêçûnek kêmtir in. Di analojiya me de, ev tê vê wateyê ku deriyên kalîteya têketinê zûtir in, ji bo destpêkirinê kêmtir hewildan hewce dikin, û bi xwe jî di xebitandinê de bêserûber in - û ev rêza ku ew tê de têne çêkirin ev e. Rola analîza statîk, ya ku, wekî ku em nuha fam dikin, dikare tenê kêmasiyên herî mezin ji holê rabike, rola tora "herê" ya di destpêka kaskada parzûnê de ye.
Analîzên statîk bi serê xwe qalîteya hilbera dawîn baştir nake, çawa ku "parzûnek heriyê" avê nade vexwarin. Lê dîsa jî, digel hêmanên din ên boriyê, girîngiya wê diyar e. Her çend di parzûnek pirqonaxî de qonaxên derketinê bi potansiyel dikarin her tiştê ku qonaxên têketinê dikin bigirin jî, diyar e ku dê çi encam ji hewildanek ku tenê bi qonaxên paqijkirina xweş, bêyî qonaxên têketinê pêk were, encam bide.
Armanca "xefika heriyê" ew e ku kaskadên paşîn ji girtina kêmasiyên pir mezin xilas bike. Mînakî, bi kêmî ve, kesê ku vekolîna kodê dike divê ji koda ku bi xeletî hatî çêkirin û binpêkirinên standardên kodkirinê yên sazkirî (wek parantezên zêde an şaxên pir kûr ên hêlînkirî) neyên kişandin. Pêdivî ye ku xeletiyên mîna NPE ji hêla ceribandinên yekîneyê ve werin girtin, lê heke berî ceribandinê jî analîzer ji me re destnîşan bike ku xeletiyek çêdibe, ev ê rastkirina wê bi girîngî bilez bike.
Ez bawer dikim ku naha eşkere ye ku çima analîza statîk heke carinan were bikar anîn qalîteya hilberê baştir nake, û divê bi domdarî were bikar anîn da ku guhartinên bi kêmasiyên mezin veqetîne. Pirsa ka gelo karanîna analîzatorek statîk dê qalîteya hilberê we baştir bike, bi qasî pirsê ye, "Gelo ava ku ji hewzek pîs tê hilanîn dê di qalîteya vexwarinê de baştir bibe ger ku di qulikê de derbas bibe?"
Pêkanîna nav projeyek mîras
Pirseke pratîkî ya girîng: meriv çawa analîza statîk di pêvajoya entegrasyonê ya domdar de wekî "dergehek kalîteyê" bicîh tîne? Di mijara ceribandinên otomatîkî de, her tişt eşkere ye: komek ceribandin hene, têkçûna yek ji wan sedemek bes e ku em bawer bikin ku meclîs deriyê kalîteyê derbas nekir. Hewldanek ji bo sazkirina dergehek bi heman rengî li ser bingeha encamên analîzek statîk têk diçe: di koda mîrateyê de pir hişyariyên analîzê hene, hûn naxwazin wan bi tevahî paşguh bikin, lê di heman demê de ne gengaz e ku hûn şandina hilberek rawestînin. tenê ji ber ku ew hişyariyên analîstê vedihewîne.
Dema ku ji bo yekem car tê bikar anîn, analîzer li ser her projeyek hejmareke mezin hişyariyan çêdike, ku pirraniya wan bi xebata rast a hilberê ve girêdayî ne. Ne gengaz e ku meriv van hemî şîroveyan bi yekcarî rast bike, û gelek ne hewce ne. Beriya her tiştî, em dizanin ku hilbera me bi tevahî dixebite, tewra berî danasîna analîzên statîk!
Wekî encamek, pir kes bi carinan carinan bi karanîna analîzên statîk ve têne sînor kirin, an jî wê tenê di moda agahdarî de bikar tînin, dema ku raporek analîzer bi tenê di dema civînê de tê derxistin. Ev wekhevî nebûna analîzek e, ji ber ku ger jixwe gelek hişyariyên me hebin, wê hingê dema guheztina kodê bûyerek din (çiqas ciddî be jî) ji nedîtî ve diçe.
Rêbazên jêrîn ên danasîna dergehên kalîteyê têne zanîn:
- Sazkirina sînorek li ser hejmara giştî ya hişyariyan an jî hejmara hişyariyan bi hejmara rêzikên kodê ve dabeş kirin. Ev nebaş dixebite, ji ber ku dergehek wusa bi serbestî dihêle ku guhertinên bi kêmasiyên nû derbas bibin, heya ku sînorê wan derbas nebe.
- Di demek diyarkirî de, hemî hişyariyên kevn ên di kodê de wekî ku têne paşguh kirin rast bikin, û dema ku hişyariyên nû çêbibin avakirina avakirina red dikin. Vê fonksiyonê ji hêla PVS-studio û hin çavkaniyên serhêl ve têne peyda kirin, mînakî Codacy. Derfeta min tune ku ez di PVS-studio de bixebitim, ji ber ku ezmûna min bi Codacy re, pirsgirêka wan a sereke ev e ku destnîşankirina xeletiyek "kevn" û çi "nû" algorîtmayek pir tevlihev e ku her gav naxebite. rast, nemaze heke pelan bi giranî hatine guheztin an jî navên wan werin guhertin. Di ezmûna min de, Codacy dikaribû di daxwazek kişandinê de hişyariyên nû paşguh neke, di heman demê de ji ber hişyariyên ku ne girêdayî guheztina koda PR-ya diyarkirî ne, daxwazek kişandinê derbas nake.
- Bi dîtina min çareseriya herî bibandor ya ku di pirtûkê de hatiye vegotin e "rêbaza raçêkirinê". Fikra bingehîn ev e ku hejmara hişyariyên analîza statîk taybetmendiyek her berdanê ye, û tenê guhertin têne destûr kirin ku jimara giştî ya hişyariyan zêde nakin.
Ratchet
Ew bi vî rengî dixebite:
- Di qonaxa destpêkê de, di metadata de tomarek di derbarê serbestberdana hejmara hişyariyên di koda ku ji hêla analîzkeran ve hatî dîtin de tê çêkirin. Ji ber vê yekê, gava ku hûn jor ve ava dikin, rêveberê depoya we ne tenê "7.0.2 berdan", lê "7.0.2 berdan ku 100500 hişyariyên şêwaza kontrolê vedihewîne." Ger hûn rêveberek depoyek pêşkeftî (wek Artifactory) bikar bînin, hilanîna metadaneyên weha di derheqê berdana we de hêsan e.
- Naha her daxwaza kişandinê, dema ku hatî çêkirin, hejmara hişyariyên encam bi hejmara hişyariyên ku di serbestberdana heyî de peyda dibin berhev dike. Ger PR bibe sedema zêdebûna vê hejmarê, wê hingê kod ji bo analîza statîk deriyê kalîteyê derbas nake. Ger hejmara hişyariyan kêm bibe an neyê guhertin, wê hingê ew derbas dibe.
- Di weşana din de, dê ji nû ve hejmartina hişyariyan di metadata berdanê de were tomar kirin.
Ji ber vê yekê hêdî hêdî lê bi domdarî (wek dema ku raçek dixebite), dê hejmara hişyariyan berbi sifirê ve biçe. Bê guman, sîstem dikare bi danasîna hişyariyek nû were xapandin, lê rastkirina yekî din. Ev normal e, ji ber ku di nav dûrek dirêj de ew encam dide: hişyarî, wekî qaîdeyek, ne bi ferdî, lê di komek celebek diyar de yekcar têne rast kirin, û hemî hişyariyên ku bi hêsanî têne rakirin pir zû têne rakirin.
Ev graf ji bo şeş mehên xebitandina "ratchet"ek wusa jimara giştî ya hişyariyên Checkstyle nîşan dide . Hejmara hişyariyan bi rêzek mezinahiyê kêm bûye, û ev bi xwezayî, bi pêşkeftina hilberê re, bi xwezayî qewimî!
Ez guhertoyek guhêrbar a vê rêbazê bikar tînim, ji hêla modula projeyê û amûra analîzê ve hişyariyan ji hev dihejmêrim, di encamê de pelek YAML bi metadata çêkirî ku tiştek wusa xuya dike:
celesta-sql:
checkstyle: 434
spotbugs: 45
celesta-core:
checkstyle: 206
spotbugs: 13
celesta-maven-plugin:
checkstyle: 19
spotbugs: 0
celesta-unit:
checkstyle: 0
spotbugs: 0
Di her pergalek pêşkeftî ya CI de, ratchet dikare ji bo her amûrên analîzên statîk bêyî ku xwe bispêre pêvek û amûrên sêyemîn were bicîh kirin. Her analîzer raporta xwe bi nivîsek hêsan an jî formatek XML-ê ku analîzkirina wê hêsan e çêdike. Tiştê ku dimîne ev e ku meriv mantiqa pêwîst di nivîsara CI de binivîsîne. Hûn dikarin bibînin ka ev çawa di projeyên me yên çavkaniya vekirî de li ser bingeha Jenkins û Artifactory têne bicîh kirin an . Her du mînak bi pirtûkxaneyê ve girêdayî ne : rêbaz countWarnings() etîketên xml di pelên ku ji hêla Checkstyle û Spotbugs ve têne çêkirin bi awayê asayî dihejmêre, û compareWarningMaps() dema ku hejmara hişyariyan di yek ji kategoriyan de zêde dibe heman raçê bicîh dike, xeletiyek davêje.
Pêkanîna balkêş a "ratchet" ji bo analîzkirina rastnivîsîna şîroveyan, rastnivîsên nivîsê û belgekirinê bi karanîna aspell gengaz e. Wekî ku hûn dizanin, dema rastnivîsînê kontrol dikin, ne hemî peyvên ku ji ferhenga standard re nenas in xelet in; ew dikarin li ferhenga bikarhêner werin zêdekirin. Ger hûn ferhengek xwerû bikin beşek ji koda çavkaniyê ya projeyê, wê hingê deriyê kalîteya rastnivîsê dikare bi vî rengî were formule kirin: aspell bi ferhengek standard û xwerû ve were xebitandin. tu xeletiyên rastnivîsînê nabînin.
Di derbarê girîngiya rastkirina guhertoya analîstê de
Di encamê de, xala ku divê were destnîşan kirin ev e ku hûn çawa analîzê di lûleya radestkirina xwe de bicîh dikin, divê guhertoya analîstê were rast kirin. Ger hûn destûrê bidin ku analîzer bixweber nûve bike, wê hingê dema ku daxwaznameya vekişînê ya paşîn berhev dike, dibe ku kêmasiyên nû "derkevin" ku ne girêdayî guheztinên kodê ne, lê bi vê yekê ve girêdayî ne ku analîzkera nû bi hêsanî dikare bêtir kêmasiyan bibîne - û ev ê pêvajoya we ya pejirandina daxwazên kişandinê bişkîne. Nûvekirina analîzatorek divê çalakiyek hişmend be. Lêbelê, rastkirina hişk a guhertoya her pêkhateya civînê bi gelemperî hewcedariyek pêdivî ye û mijarek ji bo nîqaşek cûda ye.
vebiguherin
- Analîza statîk dê ji we re xeletiyan nebîne û dê di encama serîlêdana yekane de kalîteya hilberê we baştir neke. Bandorek erênî li ser kalîteyê tenê bi karanîna wê ya domdar di dema pêvajoya radestkirinê de dikare were bidestxistin.
- Dîtina xeletiyan bi tevahî ne karê sereke yê analîzê ye; piraniya fonksiyonên bikêrhatî di amûrên çavkaniya vekirî de hene.
- Dergehên kalîteyê li ser bingeha encamên analîzên statîk di qonaxa yekem a lûleya radestkirinê de bicîh bikin, ji bo koda mîrasê "ratchet" bikar bînin.
references
- rapor li ser awayên cihêreng ên analîzkirina kodê (ne tenê statîk!)
Source: www.habr.com