Laksanakeun analisa statik kana prosésna, tinimbang nganggo éta pikeun mendakan bug

Kuring dipenta pikeun nulis artikel ieu ku jumlah badag bahan dina analisis statik nu beuki datang ka perhatian kuring. Anu mimiti, ieu PVS-studio blog, anu aktip ngamajukeun diri dina Habré kalayan bantosan ulasan kasalahan anu dipendakan ku alatna dina proyék open source. Nembe PVS-studio dilaksanakeun rojongan Java, sareng, tangtosna, pamekar IntelliJ IDEA, anu analisa diwangun-di sigana anu paling maju pikeun Java ayeuna, teu bisa ngajauhan.

Nalika maca ulasan sapertos kitu, anjeun nampi rarasaan yén urang ngobrolkeun ngeunaan elixir sihir: pencét tombol, sareng di dieu éta - daptar cacad sateuacan panon anjeun. Sigana yén nalika analisa ningkat, beuki seueur bug bakal otomatis kapendak, sareng produk anu diseken ku robot ieu bakal langkung saé sareng langkung saé, tanpa aya usaha ti pihak urang.

Tapi teu aya elixirs magic. Abdi hoyong ngobrol ngeunaan naon anu biasana henteu diomongkeun dina tulisan sapertos "di dieu hal-hal anu tiasa dipendakan ku robot urang": naon anu teu tiasa dilakukeun ku analisa, naon peran sareng tempatna anu nyata dina prosés pangiriman parangkat lunak, sareng kumaha nerapkeunana leres. .

Ratchet (sumber: Wikipedia).

Naon anu tiasa dilakukeun ku analisa statik

Naon analisis kode sumber, tina sudut pandang praktis? Urang nyadiakeun sababaraha kode sumber salaku input, jeung salaku kaluaran, dina waktu anu singget (leuwih pondok ti ngajalankeun tés) urang ménta sababaraha émbaran ngeunaan sistem urang. Watesan dasar sareng sacara matematis teu tiasa diatasi nyaéta yén urang ngan ukur tiasa nampi kelas inpormasi anu cukup sempit ku cara ieu.

Conto anu paling kasohor tina masalah anu henteu tiasa direngsekeun nganggo analisis statik nyaéta masalah shutdown: Ieu téoréma nu ngabuktikeun yén mustahil pikeun ngembangkeun hiji algoritma umum nu bisa nangtukeun tina kode sumber program naha éta bakal loop atanapi nungtungan dina jangka waktu nu tangtu. Perluasan téoréma ieu nyaéta Téoréma béas, nu nyebutkeun yén pikeun sagala sipat non-trivial tina fungsi komputasi, nangtukeun naha hiji program sawenang ngaevaluasi hiji fungsi mibanda sipat misalna hiji masalah algorithmically intractable. Salaku conto, mustahil pikeun nyerat analisa anu tiasa nangtoskeun tina kode sumber mana waé naha program anu dianalisis mangrupikeun palaksanaan algoritma anu ngitung, sebutkeun, kuadrat integer.

Ku kituna, pungsionalitas analis statik boga watesan insurmountable. Analis statik moal pernah tiasa ngadeteksi dina sagala hal sapertos, contona, kajadian "null pointer pengecualian" dina basa anu ngamungkinkeun nilai nol, atanapi dina sadaya kasus pikeun nangtukeun lumangsungna " atribut teu kapanggih" dina basa diketik dinamis. Sadaya anu tiasa dilakukeun ku analisa statik anu paling maju nyaéta nyorot kasus khusus, jumlahna, diantara sadaya masalah anu mungkin sareng kode sumber anjeun, nyaéta, tanpa kaleuleuwihan, serelek di sagara.

Analisis statik sanes ngeunaan milarian bug

Ti luhur, kacindekan kieu: analisis statik sanes sarana ngurangan jumlah defects dina program. Abdi badé nyarios: nalika diterapkeun kana proyék anjeun pertama kalina, éta bakal mendakan tempat anu "menarik" dina kodeu, tapi, paling dipikaresep, éta moal mendakan cacad anu mangaruhan kualitas program anjeun.

Conto-conto cacad anu otomatis dipendakan ku analisa pikaresepeun, tapi urang henteu kedah hilap yén conto-conto ieu dipendakan ku nyeken sakumpulan kodeu ageung ageung. Ku prinsip anu sarua, hacker anu boga kasempetan pikeun nyobaan sababaraha kecap akses basajan dina sajumlah badag akun ahirna manggihan eta akun nu boga sandi basajan.

Naha ieu hartosna yén analisis statik henteu kedah dianggo? Nya kantenan henteu! Sareng pikeun alesan anu sami yén éta patut pariksa unggal kecap konci énggal pikeun mastikeun yén éta kalebet dina daptar eureun kecap konci "basajan".

Analisis statik langkung seueur tibatan milarian bug

Kanyataanna, masalah praktis direngsekeun ku analisis leuwih lega. Barina ogé, sacara umum, analisa statik mangrupikeun verifikasi kode sumber anu dilakukeun sateuacan diluncurkeun. Ieu sababaraha hal anu anjeun tiasa laksanakeun:

• Mariksa gaya coding dina rasa anu paling lega. Ieu kalebet mariksa pormat, milarian panggunaan kurung kosong / tambahan, netepkeun ambang dina métrik sapertos jumlah garis / pajeulitna cyclomatic sahiji metodeu, sareng sajabana - naon waé anu berpotensi ngahalangan kabacaan sareng mertahankeun kodeu. Dina Java, alat sapertos Checkstyle, dina Python - flake8. Program kelas ieu biasana disebut "linters".
• Henteu ngan ukur kode anu tiasa dieksekusi tiasa dianalisis. file sumberdaya kayaning JSON, YAML, XML, .properties tiasa (jeung kedah!) Dipariksa otomatis pikeun validitas. Barina ogé, éta hadé pikeun manggihan yén struktur JSON pegat alatan sababaraha tanda petik unpaired di hiji tahap awal otomatis Tarik Request verifikasi ti salila palaksanaan test atawa ngajalankeun waktos? Alat anu cocog sayogi: f.eks. YAMLlint, JSONLint.
• Kompilasi (atanapi parsing pikeun basa program dinamis) ogé mangrupikeun jinis analisis statik. Sacara umum, kompiler sanggup ngahasilkeun peringatan anu nunjukkeun masalah sareng kualitas kode sumber sareng teu kedah dipaliré.
• Kadang kompilasi langkung seueur tibatan ngan ukur nyusun kode anu tiasa dieksekusi. Contona, upami anjeun gaduh dokuméntasi dina format AsciiDoctor, teras dina momen ngarobahna kana HTML/PDF panangan AsciiDoctor (plugin Maven) tiasa ngaluarkeun peringatan, contona, ngeunaan tautan internal anu rusak. Sareng ieu mangrupikeun alesan anu saé pikeun henteu nampi Paménta Tarik kalayan parobihan dokuméntasi.
• Mariksa éjahan ogé mangrupikeun jinis analisis statik. Utiliti aspell nyaéta bisa mariksa éjahan teu ukur dina dokuméntasi, tapi ogé dina kode sumber program (komentar jeung literal) dina sagala rupa basa programming, kaasup C / C ++, Java jeung Python. Kasalahan éjahan dina antarmuka pangguna atanapi dokuméntasi ogé cacad!
• Tés konfigurasi (ngeunaan naon éta - tingali. ieu и ieu laporan), sanajan dieksekusi dina runtime test Unit kayaning pytest, dina kanyataanana oge tipe analisis statik, sabab teu ngaéksekusi kode sumber salila palaksanaan maranéhanana.

Sakumaha anjeun tiasa tingali, milarian bug dina daptar ieu maénkeun peran anu paling henteu penting, sareng sadaya anu sanésna sayogi nganggo alat open source gratis.

Mana tina jenis analisis statik ieu anu anjeun kedah dianggo dina proyék anjeun? Tangtosna, langkung seueur langkung saé! Hal utama nyaéta pikeun nerapkeun éta leres, anu bakal dibahas salajengna.

Pipa pangiriman salaku saringan multi-tahap sareng analisa statik salaku tahap kahijina

Métafora klasik pikeun integrasi kontinyu nyaéta jalur pipa anu ngalirkeun parobahan, tina parobahan kode sumber kana pangiriman ka produksi. Urutan tahapan standar dina pipa ieu sapertos kieu:

1. analisis statik
2. kompilasi
3. tés unit
4. tés integrasi
5. tés UI
6. cék manual

Parobahan ditolak dina tahap Nth tina pipa teu dipindahkeun ka tahap N +1.

Naha persis cara kieu teu disebutkeun? Dina bagian nguji pipa, testers bakal ngakuan piramida nguji well-dipikawanoh.

Uji piramida. Sumber: artikel Martin Fowler.

Di handapeun piramida ieu aya tés anu langkung gampang ditulis, langkung gancang dieksekusi, sareng henteu gaduh kacenderungan gagal. Ku alatan éta, kudu aya leuwih ti eta, maranéhanana kudu nutupan leuwih kode jeung dieksekusi kahiji. Di luhureun piramida, sabalikna bener, jadi jumlah integrasi jeung UI tés kudu diréduksi jadi minimum diperlukeun. Jalma anu aya dina ranté ieu mangrupikeun sumber anu paling mahal, laun sareng teu tiasa dipercaya, janten anjeunna di tungtung sareng ngan ukur ngalaksanakeun padamelan upami tahap sateuacana henteu mendakan cacad. Nanging, prinsip anu sami dianggo pikeun ngawangun pipa dina bagian anu henteu langsung aya hubunganana sareng uji!

Abdi hoyong nawiskeun analogi dina bentuk sistem filtrasi cai multi-tahap. Cai kotor (robah sareng cacad) disayogikeun ka input; dina kaluaran urang kedah nampi cai bersih, dimana sadaya rereged anu teu dihoyongkeun parantos ngaleungitkeun.

saringan multi-tahap. Sumber: Wikimedia Commons

Sakumaha anjeun terang, saringan beberesih dirancang supados unggal kaskade salajengna tiasa nyaring fraksi rereged anu langkung saé. Dina waktos anu sami, cascades of purification coarser gaduh throughput anu langkung luhur sareng biaya anu langkung handap. Dina analogi urang, ieu ngandung harti yén gerbang kualitas input leuwih gancang, merlukeun kirang usaha pikeun ngamimitian, sarta sorangan leuwih unpretentious dina operasi - sarta ieu runtuyan nu aranjeunna diwangun. Peran analisis statik, nu, sakumaha ayeuna urang ngartos, sanggup weeding kaluar ukur defects grossest, nyaeta peran grid "leutak" dina pisan awal cascade filter.

Analisis statik sorangan henteu ningkatkeun kualitas produk ahir, sapertos "saringan leutak" henteu ngajantenkeun cai tiasa diinum. Na acan, ditéang jeung elemen séjén tina pipa, pentingna atra. Sanajan dina saringan multistage tahap kaluaran berpotensi bisa nangkep sagalana yén tahap input ngalakukeun, eta jelas konsékuansi naon bakal hasil tina usaha sangkan do kalawan tahapan-purifikasi rupa nyalira, tanpa tahap input.

Tujuan tina "bubu leutak" nyaéta pikeun ngagentos kaskade salajengna tina nyekel cacad anu parah pisan. Contona, sahenteuna, jalma nu ngalakukeun review kode teu matak kacau ku kode salah formatna jeung palanggaran standar coding ngadegkeun (kawas kurung tambahan atawa cabang teuing deeply nested). Bug sapertos NPE kedah ditéwak ku tés unit, tapi upami sateuacan ujian, analisa nunjukkeun ka urang yén bug pasti kajantenan, ieu bakal nyepetkeun perbaikanna.

Kuring yakin éta ayeuna jelas naha analisis statik teu ngaronjatkeun kualitas produk lamun dipaké kalana, sarta kudu dipake terus pikeun nyaring kaluar parobahan kalawan defects kotor. Patarosan naha ngagunakeun analisa statik bakal ningkatkeun kualitas produk anjeun kasarna sami sareng naroskeun, "Naha cai anu dicandak tina balong kotor bakal ningkat dina kualitas nginum upami dialirkeun kana colander?"

Palaksanaan kana proyék warisan

Patarosan praktis penting: kumaha nerapkeun analisis statik kana prosés integrasi kontinyu salaku "gerbang kualitas"? Dina hal tés otomatis, sagalana jelas: aya sakumpulan tés, kagagalan salah sahiji aranjeunna alesan cukup pikeun yakin yén assembly teu lulus Gerbang kualitas. Usaha pikeun masang gerbang dina cara anu sami dumasar kana hasil analisa statik gagal: seueur teuing peringatan analisa dina kode warisan, anjeun henteu hoyong leres-leres teu malire aranjeunna, tapi ogé teu mungkin pikeun ngeureunkeun pengiriman produk. ngan sabab ngandung warnings analyzer.

Nalika dianggo pertama kalina, analisa ngahasilkeun sajumlah ageung peringatan dina proyék naon waé, anu seuseueurna henteu aya hubunganana sareng fungsina produk anu leres. Teu mungkin pikeun ngabenerkeun sadaya koméntar ieu sakaligus, sareng seueur anu henteu diperyogikeun. Barina ogé, urang terang yén produk urang sacara gembleng tiasa dianggo, bahkan sateuacan ngenalkeun analisa statik!

Hasilna, loba anu dugi ka pamakéan occasional analisis statik, atawa make eta ukur dina modeu informasi, nalika hiji laporan analyzer ngan dikaluarkeun salila assembly. Ieu sarua jeung henteuna analisis wae, sabab lamun urang geus boga loba warnings, lajeng lumangsungna sejen (euweuh urusan kumaha serius) nalika ngarobah kode mana unnoticed.

Métode di handap ieu pikeun ngenalkeun gerbang kualitas dipikanyaho:

• Netepkeun wates dina total jumlah warnings atawa jumlah warnings dibagi jumlah garis kode. Ieu jalan kirang, sabab Gerbang misalna kalawan bébas ngamungkinkeun parobahan kalawan defects anyar ngaliwatan, salami wates maranéhanana teu ngaleuwihan.
• Ngalereskeun, dina momen nu tangtu, sagala warnings heubeul dina kode sakumaha dipaliré, sarta nampik ngawangun nalika warnings anyar lumangsung. fungsionalitas ieu disadiakeun ku PVS-studio sarta sababaraha sumber online, Contona, Codacy. Kuring teu boga kasempetan pikeun digawé di PVS-studio, sakumaha keur pangalaman kuring jeung Codacy, masalah utama maranéhanana nyaéta yén nangtukeun naon "heubeul" jeung naon kasalahan "anyar" - algoritma rada kompléks nu teu salawasna jalan. bener, utamana lamun file anu beurat dirobah atawa diganti ngaranna. Dina pangalaman abdi, Codacy bisa malire warnings anyar dina pamundut tarikan, bari dina waktos anu sareng teu lulus pamundut tarikan alatan warnings nu teu patali jeung parobahan kode tina PR dibikeun.
• Dina pamanggih kuring, solusi anu paling efektif nyaéta anu dijelaskeun dina buku Pangiriman kontinyu "metode ratcheting". Gagasan dasar éta jumlah warnings analisis statik mangrupakeun milik unggal release, sarta ngan parobahan diwenangkeun nu teu nambahan jumlah total warnings.

Ratchet

Gawéna sapertos kieu:

1. Dina tahap awal, rékaman dijieun dina metadata ngeunaan sékrési jumlah warnings dina kode kapanggih ku analis. Janten, nalika anjeun ngawangun hulu, manajer gudang anjeun nyerat sanés ngan ukur "ngaleupaskeun 7.0.2", tapi "ngaleupaskeun 7.0.2 anu ngandung 100500 peringatan gaya cek." Upami anjeun nganggo manajer gudang canggih (sapertos Artifactory), gampang nyimpen metadata sapertos pelepasan anjeun.
2. Ayeuna unggal pamundut tarikan, nalika diwangun, ngabandingkeun jumlah warnings hasilna kalawan jumlah warnings sadia dina release ayeuna. Lamun PR ngabalukarkeun kanaékan jumlah ieu, kode nu teu lulus Gerbang kualitas pikeun analisis statik. Upami jumlah peringatan ngirangan atanapi henteu robih, maka éta pas.
3. Dina sékrési salajengna, jumlah peringatan anu diitung deui bakal dirékam deui dina metadata sékrési.

Janten sakedik-sakedik tapi ajeg (sapertos nalika ratchet jalan), jumlah peringatan bakal nol. Tangtu, sistem bisa deceived ku ngawanohkeun warning anyar, tapi koréksi batur. Ieu normal, sabab dina jarak jauh méré hasil: warnings dilereskeun, sakumaha aturan, teu individual, tapi dina grup tina tipe nu tangtu sakaligus, sarta sakabeh warnings gampang removable ngaleungitkeun rada gancang.

grafik ieu nembongkeun jumlah total warnings Checkstyle salila genep bulan operasi sapertos "ratchet" dina salah sahiji proyék OpenSource kami. Jumlah warnings geus turun ku hiji urutan gedena, sarta ieu lumangsung sacara alami, dina paralel jeung ngembangkeun produk!

Kuring make versi dirobah tina metoda ieu, misah cacah warnings ku modul proyék jeung alat analisis, hasilna file YAML kalawan ngawangun metadata nu kasampak kawas kieu:

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

Dina sagala sistem CI canggih, ratchet bisa dilaksanakeun pikeun sagala parabot analisis statik tanpa ngandelkeun plugins sarta parabot pihak-katilu. Unggal analisa ngahasilkeun laporan sorangan dina téks basajan atanapi format XML anu gampang dianalisis. Sadaya anu tetep nyaéta nyerat logika anu diperyogikeun dina naskah CI. Anjeun tiasa ningali kumaha ieu dilaksanakeun dina proyék open source kami dumasar kana Jenkins sareng Artifactory di dieu atawa di dieu. Duanana conto gumantung kana perpustakaan ratchetlib: métode countWarnings() cacah tag XML dina file dihasilkeun ku Checkstyle na Spotbugs dina cara biasa, jeung compareWarningMaps() implements ratchet sarua, ngalungkeun kasalahan nalika Jumlah warnings dina salah sahiji kategori naek.

Palaksanaan anu pikaresepeun tina "ratchet" tiasa waé pikeun nganalisa éjahan koméntar, literal téks sareng dokuméntasi nganggo aspell. Sakumaha anjeun terang, nalika mariksa éjahan, henteu sadayana kecap anu teu dipikanyaho ku kamus standar henteu leres; aranjeunna tiasa ditambihkeun kana kamus pangguna. Upami anjeun ngadamel kamus khusus bagian tina kode sumber proyék, maka gerbang kualitas éjahan tiasa dirumuskeun ku cara kieu: ngajalankeun aspell sareng kamus standar sareng adat. teu kedah teu manggihan kasalahan éjahan.

Ngeunaan pentingna ngalereskeun versi analyzer

Kasimpulanana, anu kedah diperhatoskeun nyaéta henteu paduli kumaha anjeun ngalaksanakeun analisa kana pipa pangiriman anjeun, versi analisa kedah dibenerkeun. Upami anjeun ngijinkeun analisa sacara spontan ngamutahirkeun, teras nalika ngarakit pamundut tarik salajengna, cacad énggal tiasa "muncul" anu henteu aya hubunganana sareng parobihan kode, tapi aya hubunganana sareng kanyataan yén analisa énggal ngan ukur tiasa mendakan langkung seueur cacad - sareng ieu bakal ngarecah prosés anjeun nampi paménta tarik. Ngaronjatkeun analisa kedah janten tindakan sadar. Sanajan kitu, fiksasi kaku tina versi unggal komponén assembly umumna sarat diperlukeun tur topik pikeun sawala misah.

papanggihan

• Analisis statik moal mendakan bug pikeun anjeun sareng moal ningkatkeun kualitas produk anjeun salaku hasil tina hiji aplikasi. Pangaruh positip kana kualitas ngan ukur tiasa dihontal ku panggunaan konstan salami prosés pangiriman.
• Milarian bug sanés mangrupikeun tugas utama pikeun analisa; seuseueurna fungsi anu kapaké sayogi dina alat opensource.
• Nerapkeun Gerbang kualitas dumasar kana hasil analisis statik dina tahap pisan mimiti pipa pangiriman, ngagunakeun "ratchet" pikeun kode warisan.

rujukan

1. Pangiriman kontinyu
2. A. Kudryavtsev: Analisis program: kumaha ngarti yén anjeun hiji programmer alus ngalaporkeun ngeunaan métode analisis kode anu béda (henteu ngan statik!)

sumber: www.habr.com