Gampang pikeun nyobaan analisa kode statik. Tapi pikeun nerapkeun eta, utamana dina ngembangkeun hiji proyék heubeul badag, merlukeun skill. Upami teu leres dilakukeun, analisa tiasa nambihan padamelan, ngalambatkeun pamekaran, sareng ngirangan motivasi tim. Hayu urang sakeudeung ngobrol ngeunaan kumaha carana leres ngadeukeutan integrasi analisis statik kana prosés ngembangkeun tur mimitian ngagunakeun eta salaku bagian tina CI / CD.
perkenalan
Nembe perhatian kuring ditarik ka publikasi "". Di hiji sisi, ieu artikel alus nu patut meunang acquainted kalawan. Di sisi séjén, sigana kuring nu masih teu nyadiakeun jawaban lengkep ngeunaan kumaha carana painlessly nerapkeun analisis statik dina proyék kalawan loba. tina kode warisan Artikel nyebutkeun yen Anjeun tiasa nampi hutang teknis na dianggo ukur dina kode anyar, tapi euweuh jawaban kana naon anu kudu dipigawé kalayan hutang teknis ieu engké.
Tim PVS-Studio kami nawiskeun pandangan ngeunaan topik ieu. Hayu urang nempo kumaha masalah palaksanaan analisa kode statik timbul di tempat munggaran, kumaha carana nungkulan masalah ieu, sarta kumaha carana painlessly laun ngaleungitkeun hutang teknis.
Isu
Biasana henteu sesah ngaluncurkeun sareng ningali kumaha cara analisa statik jalan []. Anjeun tiasa ningali kasalahan anu pikaresepeun atanapi bahkan kerentanan poténsial anu pikasieuneun dina kode éta. Anjeun malah bisa ngalereskeun hal, tapi lajeng loba programer nyerah.
Sadaya analis statik ngahasilkeun positip palsu. Ieu mangrupikeun fitur tina metodologi analisis kode statik, sareng teu aya anu tiasa dilakukeun ngeunaan éta. Dina kasus umum, ieu masalah unsolvable, sakumaha dikonfirmasi ku teorema Rice urang []. Algoritma pembelajaran mesin ogé moal ngabantosan []. Sanaos jalma henteu tiasa nyarios naha ieu atanapi kode éta salah, maka anjeun henteu kedah nyangka ieu tina program :).
Positip palsu henteu janten masalah upami analisa statik parantos dikonpigurasi:
- Ditumpurkeun susunan aturan teu relevan;
- Sababaraha diagnostics teu relevan geus ditumpurkeun;
- Lamun urang ngobrol ngeunaan C atanapi C ++, macros ditandaan up nu ngandung constructs husus anu ngabalukarkeun warnings gunana muncul di unggal tempat dimana macros sapertos anu dipaké;
- Fungsi sorangan ditandaan anu ngalakukeun tindakan anu sami sareng fungsi sistem (analog sorangan mémbran atawa printf) [];
- Positip palsu sacara khusus ditumpurkeun nganggo koméntar;
- Jeung saterusna.
Dina hal ieu, urang bisa ngaharepkeun laju positif palsu low ngeunaan 10-15% []. Dina basa sejen, 9 kaluar 10 warnings analis bakal nunjukkeun masalah nyata dina kode, atawa sahenteuna "kode bau kuat". Satuju, skenario ieu pisan pikaresepeun, sarta analyzer mangrupakeun sobat nyata programmer.
Dina kanyataanana, dina proyék badag, gambar awal bakal sagemblengna béda. Analis ngaluarkeun ratusan atanapi rébuan peringatan pikeun kode warisan. Teu mungkin pikeun gancang ngartos mana tina peringatan ieu relevan sareng mana anu henteu. Teu rasional pikeun calik sareng ngamimitian ngurus sadaya peringatan ieu, sabab padamelan utama dina hal ieu bakal lirén sababaraha dinten atanapi minggu. Ilaharna, tim teu tiasa mampuh skenario sapertos kitu. Bakal aya ogé sajumlah ageung béda anu ngarusak sajarah parobihan. Sareng éditan massa anu gancang tina seueur fragmen dina kode pasti bakal nyababkeun typos sareng kasalahan énggal.
Sareng anu paling penting, prestasi sapertos kitu dina perang ngalawan peringatan henteu aya akal. Satuju yén saprak proyék parantos suksés salami mangtaun-taun, seueur kasalahan kritis di jerona parantos dilereskeun. Leres, perbaikan ieu mahal pisan, kedah di-debug, nampi tanggapan négatip ngeunaan bug, sareng saterasna. Analis statik bakal ngabantosan ngalereskeun seueur kasalahan ieu dina tahap coding, gancang sareng murah. Tapi di momen, salah sahiji atawa cara sejen, kasalahan ieu geus dibereskeun, sarta analyzer utamana ngadeteksi kasalahan non-kritis dina kode heubeul. Kode ieu teu bisa dipaké, éta bisa dipaké pisan jarang, sarta kasalahan di dinya bisa jadi teu ngakibatkeun konsékuansi noticeable. Panginten wae kalangkang tina tombol mangrupikeun warna anu salah, tapi ieu henteu ngaganggu panggunaan produk saha waé.
Tangtu, sanajan kasalahan leutik tetep kasalahan. Sareng kadang kasalahan tiasa nyumputkeun kerentanan anu nyata. Nanging, nyerah sadayana sareng nyéépkeun dinten / minggu pikeun nyanghareupan cacad anu bieu katingalina sigana mangrupikeun ide anu teu jelas.
Programer kasampak, kasampak, kasampak di sakabeh warnings ieu ngeunaan kode kerja heubeul ... Jeung maranéhna pikir: urang tiasa ngalakukeun tanpa analisis statik. Hayu urang nulis sababaraha pungsi mangpaat anyar.
Dina cara sorangan, aranjeunna leres. Aranjeunna nganggap yén mimitina aranjeunna kedah kumaha waé ngaleungitkeun sagala peringatan ieu. Ngan lajeng aranjeunna bakal tiasa nyandak kauntungan tina pamakéan biasa tina kode analyzer. Upami teu kitu, peringatan anyar ngan saukur bakal ngalelepkeun anu lami, sareng teu aya anu bakal merhatikeunana.
Ieu analogi anu sami sareng peringatan kompiler. Éta henteu tanpa alesan yén maranéhna nyarankeun tetep jumlah warnings kompiler dina 0. Mun aya 1000 warnings, lajeng nalika aya 1001, teu saurang ogé bakal nengetan eta, sarta teu jelas dimana néangan peringatan newest ieu.
Hal awon dina carita ieu lamun batur ti luhur ayeuna maksa anjeun ngagunakeun analisis kode statik. Ieu ngan ukur bakal ngademotivasi tim, sabab tina sudut pandangna bakal aya pajeulitna birokrasi tambahan anu ngan ukur ngahalangan. Teu aya anu bakal ningali laporan analisa, sareng sadaya panggunaan bakal ngan ukur "dina kertas". Jelema. Sacara resmi, analisa diwangun kana prosés DevOps, tapi dina prakna ieu henteu nguntungkeun saha waé. Urang ngadéngé carita lengkep dina stan ti Hadirin konferensi. Pangalaman sapertos kitu tiasa nyegah programer tina ngagunakeun alat analisis statik kanggo waktos anu lami, upami henteu salamina.
Ngalaksanakeun sareng ngaleungitkeun hutang téknis
Kanyataanna, aya nanaon hésé atawa pikasieuneun ngeunaan ngawanohkeun analisis statik malah kana proyék heubeul badag.
CI / CD
Sumawona, analisa tiasa langsung janten bagian tina prosés pangembangan kontinyu. Salaku conto, distribusi PVS-Studio ngandung utilitas pikeun gampang ningali laporan dina format anu anjeun peryogikeun, sareng béwara ka pamekar anu nyerat bagian kode masalah. Pikeun anu langkung resep ngaluncurkeun PVS-Studio tina sistem CI / CD, kuring nyarankeun yén anjeun familiarize diri sareng anu saluyu. dokuméntasi jeung runtuyan artikel:
Tapi hayu urang uih deui ka masalah sajumlah ageung positip palsu dina tahap awal ngalaksanakeun alat analisis kode.
Ngalereskeun hutang téknis anu tos aya sareng ngurus peringatan énggal
Analis statik komérsial modéren ngamungkinkeun anjeun ngan ukur diajar peringatan énggal anu muncul dina kode anu énggal atanapi dirobih. Palaksanaan mékanisme ieu beda-beda, tapi hakekatna sami. Dina analisa statik PVS-Studio, fungsionalitas ieu dilaksanakeun sapertos kieu.
Pikeun gancang mimitian nganggo analisa statik, kami nyarankeun pangguna PVS-Studio nganggo mékanisme pikeun suprési massal peringatan []. Gagasan umum nyaéta kieu. Pamaké ngaluncurkeun analisa sareng nampi seueur peringatan. Kusabab hiji proyék anu geus di ngembangkeun salila sababaraha taun hirup, ngamekarkeun jeung nyieun duit, lajeng paling dipikaresep moal aya loba warnings dina laporan nunjukkeun defects kritis. Dina basa sejen, bug kritis geus dibereskeun hiji atawa cara séjén ngagunakeun métode leuwih mahal atawa berkat eupan balik ti konsumén. Sasuai, sagalana yén analyzer ayeuna manggihan bisa dianggap hutang teknis, nu teu praktis pikeun nyobaan pikeun ngaleungitkeun langsung.
Anjeun tiasa ngabejaan PVS-Studio mertimbangkeun warnings ieu teu relevan pikeun ayeuna (nyimpen hutang teknis pikeun engké), sarta eta moal deui nembongkeun aranjeunna. Analis nyiptakeun file khusus dimana nyimpen inpormasi ngeunaan kasalahan anu henteu acan pikaresepeun. Sareng ayeuna PVS-Studio bakal ngaluarkeun peringatan ngan ukur pikeun kode anu énggal atanapi dirobih. Leuwih ti éta, sakabéh ieu dilaksanakeun cleverly. Lamun, contona, hiji garis kosong ditambahkeun kana awal file kode sumber, mangka analyzer ngartos yen, dina kanyataanana, nanaon geus robah, sarta bakal tetep jempé. File markup ieu tiasa dilebetkeun kana sistem kontrol versi. Filena ageung, tapi ieu sanés masalah, sabab henteu aya gunana pikeun nyimpen éta sering.
Ayeuna sadaya programer bakal ningali peringatan anu aya hubunganana sareng kode anu énggal atanapi anu dirobih. Ku kituna, anjeun bisa mimitian nganggo analyzer, sabab nyebutkeun, ti poé saterusna. Tur anjeun bisa balik deui ka hutang teknis engké, sarta saeutik demi saeutik ngabenerkeun kasalahan jeung ngonpigurasikeun analyzer nu.
Janten, masalah anu munggaran sareng palaksanaan analisa dina proyék lami ageung parantos direngsekeun. Ayeuna hayu urang terang naon anu kudu dilakukeun ku hutang téknis.
Perbaikan bug sareng refactorings
Hal anu pangbasajanna sareng paling alami nyaéta nyéépkeun sababaraha waktos pikeun nganalisis peringatan analis anu diteken sacara massal sareng laun-laun nungkulanana. Dimana wae anjeun kedah ngalereskeun kasalahan dina kode, dimana anjeun kedah refactor pikeun nyarioskeun ka analisa yén kode éta henteu masalah. conto basajan:
if (a = b)Paling C ++ compilers na analyzers ngawadul ngeunaan kode sapertos, saprak aya kamungkinan luhur yén maranéhna sabenerna hayang nulis (a == b). Tapi aya hiji perjangjian unspoken, sarta ieu biasana nyatet dina dokuméntasi, yén lamun aya tambahan kurung, mangka dianggap programmer nu ngahaja nulis kode misalna, sarta teu kudu sumpah. Contona, dina dokuméntasi PVS-Studio pikeun diagnostics eta jelas ditulis yén garis handap bakal dianggap bener tur aman:
if ((a = b))conto sejen. Éta poho dina C ++ kode ieu? peunggas atanapi henteu?
case A:
foo();
case B:
bar();
break;Analis PVS-Studio bakal ngaluarkeun peringatan di dieu . Ieu bisa jadi teu kasalahan, bisi nu kudu masihan parser hint ku nambahkeun atribut atawa, contona, __atribut__((fallthrough)):
case A:
foo();
[[fallthrough]];
case B:
bar();
break;Bisa disebutkeun yen parobahan kode misalna teu ngalereskeun bug. Leres, ieu leres, tapi ngalakukeun dua hal anu mangpaat. Anu mimiti, laporan analisa ngaleungitkeun positip palsu. Bréh, kode janten langkung kaharti pikeun jalma anu kalibet dina pangropéa na. Sareng ieu penting pisan! Pikeun ieu waé, éta patut ngalaksanakeun refactorings minor pikeun ngajantenkeun kodeu langkung jelas sareng gampang dijaga. Kusabab analisa henteu ngartos naha "break" diperyogikeun atanapi henteu, éta ogé bakal écés pikeun sasama programer.
Salian perbaikan bug sareng refactorings, anjeun tiasa sacara khusus ngahalangan peringatan analisa palsu. Sababaraha diagnostik anu teu relevan tiasa ditumpurkeun. Contona, batur nyangka warnings aya gunana ngeunaan ngabandingkeun ngambang / nilai ganda. Sareng sababaraha ngagolongkeun aranjeunna salaku penting sareng pantes pikeun diajar []. Peringatan mana anu dianggap relevan sareng mana anu henteu gumantung kana tim pamekar anu mutuskeun.
Aya cara séjén pikeun ngeureunkeun béwara palsu. Contona, markup makro ieu disebutkeun tadi. Sadaya ieu dijelaskeun sacara langkung rinci dina dokuméntasi. Anu paling penting nyaéta ngartos yén upami anjeun laun-laun sareng sacara sistematis ngadeukeutan damel sareng positip palsu, teu aya anu lepat sareng aranjeunna. Lolobana warnings uninteresting ngaleungit sanggeus konfigurasi, sarta ngan tempat anu bener merlukeun ulikan ati tur sababaraha parobahan kode tetep.
Ogé, kami salawasna mantuan klien kami nyetél PVS-Studio lamun aya kasusah timbul. Sumawona, aya kasus nalika urang sorangan ngaleungitkeun peringatan palsu sareng ngalereskeun kasalahan []. Bisi waé, kuring mutuskeun pikeun disebatkeun yén pilihan ieu pikeun kerjasama anu diperpanjang ogé mungkin :).
Métode ratchet
Aya pendekatan metot séjén pikeun laun ningkatkeun kualitas kode ku ngaleungitkeun peringatan analyzer statik. Dasarna nyaéta jumlah peringatan ngan ukur tiasa ngirangan.
Jumlah peringatan anu dikaluarkeun ku analisa statik dirékam. Gerbang kualitas dikonpigurasi ku cara anu ayeuna anjeun ngan ukur tiasa ngalebetkeun kode anu henteu nambahan jumlah operasi. Hasilna, prosés laun-laun ngirangan jumlah alarm dimimitian ku nyaluyukeun analisa sareng koréksi kasalahan.
Malah lamun hiji jalma hayang curang saeutik sarta mutuskeun pikeun lulus Gerbang kualitas teu ngaleungitkeun warnings dina kode anyar na, tapi ku ngaronjatkeun kodeu pihak-katilu heubeul, ieu teu pikasieuneun. Sadayana sami, ratchet puteran dina hiji arah, sareng laun-laun jumlah cacad bakal ngirangan. Malah lamun hiji jalma teu hayang ngalereskeun defects anyar sorangan, anjeunna masih kudu ningkatkeun hal dina kode tatangga. Dina sababaraha waktos, cara anu gampang pikeun ngirangan jumlah peringatan mungkas, sareng aya titik nalika bug nyata bakal dibenerkeun.
Metodologi ieu dijelaskeun dina leuwih jéntré dina artikel pisan metot ku Ivan Ponomarev "", anu kuring nyarankeun maca ka saha waé anu resep ningkatkeun kualitas kode.
Panulis tulisan ogé gaduh laporan ngeunaan topik ieu: "".
kacindekan
Abdi ngarepkeun saatos tulisan ieu, pamiarsa bakal langkung nampi alat analisis statik sareng hoyong nerapkeunana kana prosés pangwangunan. Mun anjeun mibanda patalékan, kami salawasna siap pamaké analyzer statik kami PVS-Studio tur mantuan kalawan palaksanaan na.
Aya mamang has sejenna ngeunaan naha analisis statik bener bisa merenah tur mangpaat. Kuring diusahakeun dispel lolobana mamang ieu dina publikasi "Alesan pikeun ngawanohkeun PVS-Studio kode statik analyzer kana prosés ngembangkeun" [].
Hatur nuhun kana perhatosanana sareng sumping jeung cobaan PVS-Studio analyzer.
Tumbu tambahan
- Andrey Karpov.
- Wikipedia. .
- Andrey Karpov, Victoria Khanieva. .
- PVS-Studio. Dokuméntasi. .
- Andrey Karpov. .
- PVS-Studio. Dokuméntasi. .
- Ivan Andryashin. .
- Pavel Eremeev, Svyatoslav Razmyslov. .
- Andrey Karpov. .
Upami anjeun hoyong ngabagikeun tulisan ieu ka pamiarsa anu nyarios basa Inggris, mangga nganggo tautan tarjamahan: Andrey Karpov. .
sumber: www.habr.com