Aku dijaluk nulis artikel iki kanthi akeh materi babagan analisis statis sing saya tambah akeh. Kaping pisanan, iki , sing aktif promosi dhewe ing Habré kanthi bantuan review kesalahan sing ditemokake dening alat kasebut ing proyek sumber terbuka. Bubar PVS-studio dipun ginakaken , lan, mesthine, pangembang IntelliJ IDEA, sing analisa sing dibangun bisa uga paling maju kanggo Jawa saiki, .
Nalika maca review kasebut, sampeyan bisa ngrasa yen kita ngomong babagan elixir ajaib: pencet tombol kasebut, lan ing kene ana - dhaptar cacat sadurunge mata. Kayane nalika analisa nambah, luwih akeh kewan omo bakal ditemokake kanthi otomatis, lan produk sing dipindai dening robot kasebut bakal dadi luwih apik lan luwih apik, tanpa gaweyan apa wae.
Nanging ora ana elixir ajaib. Aku pengin ngomong babagan apa sing biasane ora diomongake ing kiriman kaya "kene apa sing bisa ditemokake robot kita": apa sing ora bisa ditindakake dening penganalisis, apa peran lan panggonan sing nyata ing proses pangiriman piranti lunak, lan cara ngetrapake kanthi bener .
Ratchet (sumber: ).
Apa analis statis ora bisa nindakake
Apa analisis kode sumber, saka sudut pandang praktis? Kita nyedhiyakake sawetara kode sumber minangka input, lan minangka output, ing wektu sing cendhak (luwih cendhek tinimbang tes sing mlaku) entuk sawetara informasi babagan sistem kita. Watesan dhasar lan ora bisa diatasi kanthi matematis yaiku yen kita mung bisa entuk kelas informasi sing cukup sempit kanthi cara iki.
Conto paling misuwur saka masalah sing ora bisa ditanggulangi nggunakake analisis statis : Iki minangka teorema sing mbuktekake manawa ora bisa ngembangake algoritma umum sing bisa nemtokake saka kode sumber program apa bakal daur ulang utawa mungkasi ing wektu sing winates. Tambahan saka teorema iki yaiku , sing nyatakake yen kanggo sembarang properti non-trivial saka fungsi komputasi, nentokake apa program kasepakatan ngevaluasi fungsi karo properti kuwi masalah algorithmically intractable. Contone, ora bisa nulis analisa sing bisa nemtokake saka kode sumber apa program sing dianalisis minangka implementasi saka algoritma sing ngitung, umpamane, kuadrat integer.
Mangkono, fungsi analisa statis duwe watesan sing ora bisa diatasi. Analisa statis ora bakal bisa ndeteksi ing kabeh kasus kayata, contone, kedadeyan "null pointer exception" ing basa sing ngidini nilai null, utawa ing kabeh kasus kanggo nemtokake kedadeyan " atribut ora ditemokake" ing basa sing diketik kanthi dinamis. Kabeh sing bisa ditindakake dening penganalisa statis sing paling maju yaiku nyorot kasus khusus, sing nomer kasebut, ing antarane kabeh masalah sing bisa ditindakake karo kode sumber sampeyan, tanpa exaggeration, gulung ing samodra.
Analisis statis ora babagan nemokake bug
Saka ndhuwur, kesimpulan kasebut: analisis statis ora minangka sarana kanggo nyuda jumlah cacat ing program. Aku bakal ngomong: nalika ditrapake ing proyek sampeyan kanggo pisanan, bakal nemokake panggonan "menarik" ing kode kasebut, nanging, paling kamungkinan, ora bakal nemokake cacat sing mengaruhi kualitas program sampeyan.
Conto cacat sing ditemokake kanthi otomatis dening penganalisa pancen apik banget, nanging aja lali manawa conto kasebut ditemokake kanthi mindhai sakumpulan basis kode gedhe. Kanthi prinsip sing padha, peretas sing duwe kesempatan kanggo nyoba sawetara sandhi sing prasaja ing akeh akun pungkasane nemokake akun kasebut sing duwe tembung sandhi sing prasaja.
Apa iki tegese analisis statis ora kudu digunakake? Mesthi ora! Lan kanthi alesan sing padha, kudu dipriksa saben tembung sandhi anyar kanggo mesthekake yen kalebu ing dhaptar mandeg tembung sandhi "prasaja".
Analisis statis luwih saka nemokake bug
Nyatane, masalah sing ditanggulangi kanthi cara analisis luwih akeh. Sawise kabeh, umume, analisis statis yaiku verifikasi kode sumber sing ditindakake sadurunge diluncurake. Ing ngisor iki sawetara perkara sing bisa ditindakake:
- Priksa gaya coding ing pangertèn sing paling jembar. Iki kalebu mriksa formatting, nggoleki panggunaan kurung kosong / ekstra, nyetel ambang ing metrik kaya jumlah garis / kerumitan cyclomatic saka sawijining metode, lan sapiturute - apa wae sing bisa ngalangi keterbaca lan keterpeliharaan kode kasebut. Ing Jawa, alat kasebut yaiku Checkstyle, ing Python - flake8. Program kelas iki biasane disebut "linters."
- Ora mung kode eksekusi sing bisa dianalisis. File sumber daya kayata JSON, YAML, XML, .properties bisa (lan kudu!) Dipriksa kanthi otomatis kanggo validitas. Sawise kabeh, luwih becik ngerteni manawa struktur JSON rusak amarga sawetara kuotasi sing ora dipasangake ing tahap awal verifikasi Panjaluk Tarik otomatis tinimbang sajrone eksekusi tes utawa wektu mbukak? Piranti sing cocog kasedhiya: f.eks. , .
- Kompilasi (utawa parsing kanggo basa pemrograman dinamis) uga minangka jinis analisis statis. Umumé, compiler bisa ngasilake bebaya sing nuduhake masalah karo kualitas kode sumber lan ora kudu diabaikan.
- Kadhangkala kompilasi luwih saka mung kompilasi kode eksekusi. Contone, yen sampeyan duwe dokumentasi ing format , banjur ing wayahe ngowahi dadi HTML/PDF panangan AsciiDoctor () bisa ngetokake bebaya, contone, babagan pranala internal sing rusak. Lan iki minangka alesan sing apik kanggo ora nampa Panjaluk Tarik kanthi owah-owahan dokumentasi.
- Priksa ejaan uga minangka jinis analisis statis. Utilitas bisa mriksa ejaan ora mung ing dokumentasi, nanging uga ing kode sumber program (komentar lan literal) ing macem-macem basa program, kalebu C / C ++, Java lan Python. Kesalahan ejaan ing antarmuka pangguna utawa dokumentasi uga cacat!
- Tes konfigurasi (babagan apa - deleng. и laporan), sanajan dieksekusi ing runtime test unit kayata pytest, nyatane uga minangka jinis analisis statis, amarga ora nglakokake kode sumber sajrone eksekusi.
Kaya sing sampeyan ngerteni, nggoleki bug ing dhaptar iki nduweni peran sing paling ora penting, lan kabeh liyane kasedhiya kanthi nggunakake alat open source gratis.
Endi saka jinis analisis statis iki sing kudu sampeyan gunakake ing proyek sampeyan? Mesthi, luwih akeh luwih apik! Sing utama yaiku ngetrapake kanthi bener, sing bakal dibahas luwih lanjut.
Pipa pangiriman minangka saringan multi-tataran lan analisis statis minangka tataran kapisan
Metafora klasik kanggo integrasi terus-terusan yaiku saluran pipa sing owah-owahan, saka owah-owahan kode sumber nganti pangiriman menyang produksi. Urutan tahapan standar ing pipa iki katon kaya iki:
- analisis statis
- kompilasi
- tes unit
- tes integrasi
- tes UI
- mriksa manual
Owah-owahan sing ditolak ing tahap N saka pipa ora ditransfer menyang tahap N +1.
Yagene persis kaya iki lan ora liya? Ing bagean tes pipa, penguji bakal ngerteni piramida tes sing kondhang.
Tes piramida. Sumber: Martin Fowler.
Ing ngisor piramida iki ana tes sing luwih gampang ditulis, luwih cepet dieksekusi, lan ora cenderung gagal. Mulane, kudu luwih akeh, kudu nutupi luwih akeh kode lan dieksekusi dhisik. Ing sisih ndhuwur piramida, kosok balene, mula jumlah integrasi lan tes UI kudu dikurangi dadi minimal sing dibutuhake. Wong ing rantai iki minangka sumber daya sing paling larang, alon lan ora bisa dipercaya, mula dheweke ana ing pungkasan lan mung nindakake pakaryan yen tahap sadurunge ora nemokake cacat. Nanging, prinsip sing padha digunakake kanggo mbangun pipa ing bagean sing ora ana hubungane langsung karo tes!
Aku pengin menehi analogi ing wangun sistem filtrasi banyu multi-tataran. Banyu reged (owah-owahan karo cacat) diwenehake menyang input; ing output kita kudu nampa banyu resik, ing ngendi kabeh rereged sing ora dikarepake wis diilangi.
Filter multi-tataran. Sumber:
Kaya sing sampeyan ngerteni, saringan reresik dirancang supaya saben kaskade sabanjure bisa nyaring pecahan rereged sing luwih apik. Ing wektu sing padha, cascades pemurnian coarser duwe throughput sing luwih dhuwur lan biaya sing luwih murah. Ing analogi kita, iki tegese gerbang kualitas input luwih cepet, mbutuhake kurang gaweyan kanggo miwiti, lan dhewe luwih unpretentious ing operasi - lan iki urutan kang dibangun. Peran analisis statis, sing saiki kita ngerti, mung bisa ngilangi cacat sing paling gedhe, yaiku peran kothak "lumpur" ing wiwitan cascade filter.
Analisis statis dhewe ora nambah kualitas produk pungkasan, kaya "filter lumpur" ora nggawe banyu bisa diombe. Nanging, ing magepokan karo unsur liyane saka pipeline, wigati iku ketok. Senajan ing multi-tataran Filter orane tumrap sekolah output duweni potensi saged njupuk kabeh sing orane tumrap sekolah input, iku cetha apa jalaran bakal kasil saka nyoba kanggo nindakake karo orane tumrap sekolah nggoleki-pemurnian piyambak, tanpa orane tumrap sekolah input.
Tujuan saka "jebakan lendhut" iku kanggo ngredhakaké cascades sakteruse saka nyekel cacat banget reged. Contone, paling ora, wong sing nindakake review kode ora kena diganggu dening kode format sing salah lan nglanggar standar kode sing wis ditetepake (kayata kurung ekstra utawa cabang sing akeh banget). Kewan omo kaya NPE kudu dicekel dening tes unit, nanging sanajan sadurunge tes, analisa nuduhake manawa ana bug bakal kelakon, iki bakal nyepetake ndandani.
Aku pracaya iku saiki cetha kok analisis statis ora nambah kualitas produk yen digunakake sok-sok, lan kudu digunakake terus-terusan kanggo nyaring metu owah-owahan karo cacat reged. Pitakonan apa nggunakake analisa statis bakal ningkatake kualitas produk sampeyan kira-kira padha karo takon, "Apa banyu sing dijupuk saka blumbang sing reged bakal nambah kualitas ngombe yen dilewati liwat colander?"
Implementasi menyang proyek warisan
Pitakonan praktis sing penting: carane ngleksanakake analisis statis menyang proses integrasi sing terus-terusan minangka "gerbang kualitas"? Ing kasus tes otomatis, kabeh wis jelas: ana set tes, kegagalan saka salah sawijining alesan sing cukup kanggo percaya yen perakitan kasebut ora ngliwati gerbang kualitas. Usaha kanggo nginstal gapura kanthi cara sing padha adhedhasar asil analisis statis gagal: ana akeh banget bebaya analisis ing kode warisan, sampeyan ora pengin nglirwakake kabeh, nanging uga ora bisa mandheg ngirim produk. mung amarga ngemot bebaya analyzer.
Nalika pisanan digunakake, analisa ngasilake akeh bebaya babagan proyek apa wae, sing paling akeh ora ana gandhengane karo fungsi produk sing tepat. Ora bisa mbenerake kabeh komentar kasebut bebarengan, lan akeh sing ora perlu. Sawise kabeh, kita ngerti manawa produk kita kanthi sakabehe bisa digunakake, sanajan sadurunge ngenalake analisis statis!
Akibaté, akeh diwatesi kanggo nggunakake sok-sok analisis statis, utawa nggunakake mung ing mode informasi, nalika laporan analyzer mung ditanggepi sak perakitan. Iki padha karo ora ana analisis apa wae, amarga yen kita wis duwe akeh bebaya, mula kedadeyan liyane (ora ketompo carane serius) nalika ngganti kode kasebut ora digatekake.
Cara ing ngisor iki kanggo ngenalake gerbang kualitas dikenal:
- Nyetel watesan jumlah bebaya utawa jumlah bebaya dibagi karo nomer baris kode. Iki ora bisa digunakake, amarga gapura kasebut kanthi bebas ngidini owah-owahan kanthi cacat anyar, anggere watesan kasebut ora ngluwihi.
- Ndandani, ing wayahe tartamtu, kabeh bebaya lawas ing kode minangka digatèkaké, lan nolak kanggo mbangun nalika bebaya anyar kedaden. fungsi iki diwenehake dening PVS-studio lan sawetara sumber online, Contone, Codacy. Aku ora duwe kesempatan kanggo bisa ing PVS-studio, minangka kanggo pengalaman karo Codacy, masalah utama sing nemtokake apa "lawas" lan apa "anyar" kesalahan - algoritma rada Komplek sing ora tansah bisa. bener, utamané yen file akeh banget diowahi utawa diganti jeneng. Ing pengalaman, Codacy bisa nglirwakake bebaya anyar ing panjalukan narik, nalika ing wektu sing padha ora ngliwati panjalukan narik amarga bebaya sing ora ana hubungane karo owah-owahan ing kode PR sing diwenehake.
- Miturut pendapatku, solusi sing paling efektif yaiku sing diterangake ing buku kasebut "metode ratcheting". Ing idea dhasar iku nomer bebaya analisis statis properti saben release, lan mung owah-owahan sing diijini ora nambah jumlah bebaya.
Ratchet
Kerjane kaya iki:
- Ing tahap wiwitan, rekaman digawe ing metadata babagan rilis jumlah bebaya ing kode sing ditemokake dening penganalisis. Dadi, nalika sampeyan mbangun hulu, manajer repositori sampeyan ora mung nulis "rilis 7.0.2", nanging "rilis 7.0.2 sing ngemot 100500 bebaya checkstyle." Yen sampeyan nggunakake manajer repositori canggih (kayata Artifactory), nyimpen metadata kasebut babagan rilis sampeyan gampang.
- Saiki saben panjaluk narik, nalika dibangun, mbandhingake jumlah bebaya sing diasilake karo jumlah bebaya sing kasedhiya ing rilis saiki. Yen PR ndadékaké kanggo nambah nomer iki, kode ora pass gapura kualitas kanggo analisis statis. Yen jumlah bebaya suda utawa ora owah, banjur liwati.
- Ing rilis sabanjure, jumlah bebaya sing diitung maneh bakal direkam maneh ing metadata rilis.
Dadi sithik-sithik nanging ajeg (kaya nalika ratchet dianggo), jumlah bebaya bakal nol. Mesthi, sistem bisa diapusi dening ngenalke bebaya anyar, nanging mbenerake wong liya. Iki normal, amarga ing jarak sing adoh menehi asil: bebaya didandani, minangka aturan, ora kanthi individu, nanging ing klompok jinis tartamtu bebarengan, lan kabeh bebaya sing gampang dicopot diilangi kanthi cepet.
Grafik iki nuduhake jumlah total bebaya Checkstyle kanggo nem sasi operasi saka kuwi "ratchet" ing . Jumlah bebaya wis suda kanthi urutan gedhene, lan iki kedadeyan kanthi alami, sejajar karo pangembangan produk!
Aku nggunakake versi modifikasi saka metode iki, kanthi kapisah ngetung bebaya kanthi modul proyek lan alat analisis, ngasilake file YAML kanthi metadata mbangun sing katon kaya iki:
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
Ing sistem CI canggih apa wae, ratchet bisa dileksanakake kanggo alat analisis statis tanpa ngandelake plugin lan alat pihak katelu. Saben analisa ngasilake laporan dhewe ing teks utawa format XML sing gampang dianalisis. Kabeh sing isih ana yaiku nulis logika sing dibutuhake ing skrip CI. Sampeyan bisa ndeleng carane iki dileksanakake ing proyek open source adhedhasar Jenkins lan Artifactory utawa . Loro-lorone conto gumantung ing perpustakaan : metode countWarnings() counts xml tags ing file kui dening Checkstyle lan Spotbugs ing cara biasanipun, lan compareWarningMaps() ngleksanakake ratchet padha, mbuwang kesalahan nalika nomer bebaya ing samubarang kategori mundhak.
Implementasi menarik saka "ratchet" bisa kanggo nganalisa ejaan komentar, literals teks lan dokumentasi nggunakake aspell. Kaya sing sampeyan ngerteni, nalika mriksa ejaan, ora kabeh tembung sing ora dingerteni ing kamus standar ora bener; bisa ditambahake ing kamus pangguna. Yen sampeyan nggawe bagean kamus khusus saka kode sumber proyek, gerbang kualitas ejaan bisa dirumusake kanthi cara iki: mlaku aspell kanthi kamus standar lan khusus. ora nemokake kesalahan ejaan.
Babagan pentinge ndandani versi analyzer
Kesimpulane, titik sing kudu dicathet yaiku ora ketompo carane sampeyan ngleksanakake analisis menyang pipa pangiriman sampeyan, versi analisa kudu didandani. Yen sampeyan ngidini analisa nganyari kanthi spontan, banjur nalika ngumpulake panjaluk tarik sabanjure, cacat anyar bisa uga "muncul" sing ora ana gandhengane karo owah-owahan kode, nanging ana gandhengane karo kasunyatan manawa analisa anyar mung bisa nemokake cacat liyane - lan iki bakal ngrusak proses sampeyan nampa panjaluk tarik. Nganyarke analyzer kudu tumindak sadar. Nanging, fiksasi kaku saka versi saben komponèn Déwan umume syarat perlu lan topik kanggo diskusi kapisah.
temonan
- Analisis statis ora bakal nemokake bug kanggo sampeyan lan ora bakal nambah kualitas produk minangka asil saka aplikasi siji. Efek positif ing kualitas mung bisa digayuh kanthi nggunakake terus-terusan sajrone proses pangiriman.
- Nemokake kewan omo dudu tugas utama analisis; akeh fungsi sing migunani kasedhiya ing alat opensource.
- Ngleksanakake gerbang kualitas adhedhasar asil analisis statis ing tahap pisanan saka pipa pangiriman, nggunakake "ratchet" kanggo kode warisan.
referensi
- laporan babagan macem-macem cara analisis kode (ora mung statis!)
Source: www.habr.com