Gampang nyoba penganalisa kode statis. Nanging kanggo ngleksanakake, utamane ing pangembangan proyek lawas sing gedhe, mbutuhake skill. Yen rampung salah, analisa bisa nambah karya, alon pembangunan, lan demotivate tim. Ayo ngobrol kanthi ringkes babagan cara pendekatan integrasi analisis statis menyang proses pangembangan kanthi bener lan miwiti nggunakake minangka bagean saka CI / CD.
Pambuka
Bubar iki perhatianku ditarik menyang publikasi "". Ing tangan siji, iki artikel apik sing worth njupuk kenalan karo. Ing tangan liyane, misale jek kula sing isih ora nyedhiyani jawaban lengkap babagan carane painlessly ngleksanakake analisis statis ing project karo kathah. saka kode warisan Artikel ngandika sing Sampeyan bisa nampa utang technical lan bisa mung ing kode anyar, nanging ora ana jawaban apa apa karo utang technical iki mengko.
Tim PVS-Studio nawakake tampilan babagan topik iki. Ayo katon ing carane masalah ngleksanakake analyzer kode statis muncul ing Panggonan pisanan, carane ngatasi masalah iki, lan carane painlessly mboko sithik ngilangke utang technical.
Masalah
Biasane ora angel diluncurake lan ndeleng cara kerja penganalisa statis []. Sampeyan bisa uga ndeleng kesalahan sing menarik utawa malah kerentanan potensial sing medeni ing kode kasebut. Sampeyan bisa malah ndandani soko, nanging banjur akeh programer nyerah.
Kabeh analisa statis ngasilake positip palsu. Iki minangka fitur saka metodologi analisis kode statis, lan ora ana sing bisa ditindakake. Ing kasus umum, iki minangka masalah sing ora bisa dipecahake, kaya sing dikonfirmasi dening teorema Rice []. Algoritma pembelajaran mesin ora bakal mbantu []. Sanajan ana wong ora bisa ngerti manawa iki utawa kode kasebut salah, mula sampeyan ora bisa nyana program kasebut :).
Positif palsu ora dadi masalah yen analisa statis wis dikonfigurasi:
- Pateni set aturan sing ora cocog;
- Sawetara diagnostik sing ora cocog wis dipateni;
- Yen kita ngomong babagan C utawa C ++, banjur ditandhani macro sing ngemot konstruksi tartamtu sing nyebabake bebaya sing ora ana gunane katon ing saben panggonan sing digunakake macro kasebut;
- Fungsi dhewe ditandhani sing nindakake tumindak sing padha karo fungsi sistem (analoge dhewe memcpy utawa printf) [];
- Positif palsu khusus dipateni nggunakake komentar;
- Lan liyane.
Ing kasus iki, kita bisa nyana tingkat positif palsu kurang saka 10-15% []. Kanthi tembung liyane, 9 saka 10 peringatan analisa bakal nuduhake masalah nyata ing kode kasebut, utawa paling ora "kode sing mambu kuat." Setuju, skenario iki banget nyenengake, lan analisa minangka kanca nyata programmer.
Ing kasunyatan, ing proyek gedhe, gambar awal bakal beda banget. Analisa ngetokake atusan utawa ewu bebaya kanggo kode warisan. Ora mungkin kanthi cepet ngerti endi saka bebaya kasebut sing cocog lan sing ora. Iku ora klebu nalar kanggo njagong mudhun lan miwiti dealing with kabeh bebaya iki, amarga karya utama ing kasus iki bakal mandheg kanggo dina utawa minggu. Biasane, tim ora bisa mbayar skenario kasebut. Ana uga akeh bedane sing ngrusak sejarah owah-owahan. Lan panyuntingan massal kanthi cepet saka akeh pecahan ing kode mesthi bakal nyebabake kesalahan ketik lan kesalahan anyar.
Lan sing paling penting, prestasi kasebut ing perang nglawan peringatan ora ana gunane. Setuju yen proyek kasebut wis sukses nganti pirang-pirang taun, akeh kesalahan kritis sing wis didandani. Ya, koreksi kasebut larang banget, kudu di-debug, nampa umpan balik pangguna negatif babagan bug, lan liya-liyane. Analisa statis bakal mbantu ndandani akeh kesalahan kasebut ing tahap coding, kanthi cepet lan murah. Nanging ing wayahe, salah siji cara utawa liyane, kasalahan iki wis didandani, lan analyzer utamanΓ© ndeteksi kasalahan non-kritis ing kode lawas. Kode iki bisa uga ora digunakake, bisa digunakake arang banget, lan kesalahan bisa uga ora mimpin kanggo jalaran ngelingke. Mbok ing endi wae bayangan saka tombol iku werna salah, nanging iki ora ngganggu sapa nggunakake produk.
Mesthine, sanajan kesalahan cilik isih dadi kesalahan. Lan kadhangkala kesalahan bisa ndhelikake kerentanan sing nyata. Nanging, nyerah kabeh lan mbuwang dina / minggu kanggo ngatasi cacat sing meh ora katon kaya ide sing ora bisa dipercaya.
Programer katon, katon, ndeleng kabeh bebaya iki babagan kode kerja lawas ... Lan padha mikir: kita bisa nindakake tanpa analisis statis. Ayo nulis sawetara fungsi migunani anyar.
Ing cara dhewe, padha bener. Dheweke mikir yen pisanan kudu nyingkirake kabeh bebaya kasebut. Mung banjur bakal bisa entuk manfaat saka nggunakake biasa saka kode analyzer. Yen ora, bebaya anyar mung bakal klelep ing sing lawas, lan ora ana sing bakal nggatekake.
Iki analogi sing padha karo bebaya kompiler. Iku ora tanpa alesan sing padha menehi saran supaya nomer bebaya compiler ing 0. Yen ana 1000 bebaya, banjur nalika ana 1001, ora ana siji bakal mbayar manungsa waΓ© kanggo, lan iku ora cetha ngendi kanggo nggoleki bebaya Newest iki.
Bab sing paling ala ing crita iki yaiku yen ana wong saka ndhuwur ing wektu iki meksa sampeyan nggunakake analisis kode statis. Iki mung bakal ngrusak tim kasebut, amarga saka sudut pandange, bakal ana kerumitan birokrasi tambahan sing mung ana ing dalan. Ora ana sing bakal ndeleng laporan analisa, lan kabeh panggunaan bakal mung "ing kertas". Sing. Secara resmi, analisis dibangun ing proses DevOps, nanging ing praktik iki ora entuk manfaat kanggo sapa wae. Kita krungu crita rinci ing booth saka peserta konferensi. Pengalaman kasebut bisa nyuda programer nggunakake alat analisis statis kanggo wektu sing suwe, yen ora ing salawas-lawase.
Ngleksanakake lan ngilangi utang teknis
Nyatane, ora ana sing angel utawa medeni babagan ngenalake analisis statis sanajan ing proyek lawas sing gedhe.
CI / CD
Kajaba iku, analisa bisa langsung dadi bagean saka proses pangembangan sing terus-terusan. Contone, distribusi PVS-Studio ngemot keperluan kanggo gampang ndeleng laporan ing format sing dibutuhake, lan kabar kanggo pangembang sing nulis bagean kode masalah. Kanggo sing luwih kasengsem ngluncurake PVS-Studio saka sistem CI / CD, aku nyaranake sampeyan sinau babagan sing cocog. dokumentasi lan seri artikel:
Nanging ayo bali menyang masalah akeh positip palsu ing tahap pisanan ngleksanakake alat analisis kode.
Ndandani utang teknis sing ana lan nangani bebaya anyar
Analisa statis komersial modern ngidini sampeyan sinau mung bebaya anyar sing katon ing kode anyar utawa diganti. Implementasine mekanisme iki beda-beda, nanging intine padha. Ing penganalisa statis PVS-Studio, fungsi iki dileksanakake kaya ing ngisor iki.
Kanggo miwiti nggunakake analisis statis kanthi cepet, disaranake pangguna PVS-Studio nggunakake mekanisme kanggo nyegah peringatan massal []. Ide umum ing ngisor iki. Pangguna ngluncurake analisa lan nampa akeh bebaya. Wiwit proyek sing wis dikembangake nganti pirang-pirang taun isih urip, ngembangake lan entuk dhuwit, mula kemungkinan ora ana akeh bebaya ing laporan sing nuduhake cacat kritis. Ing tembung liyane, kewan omo kritis wis didandani kanthi cara sing luwih larang utawa amarga umpan balik saka pelanggan. Mulane, kabeh sing ana analisa saiki bisa dianggep utang technical, kang ora praktis kanggo nyoba kanggo mbusak langsung.
Sampeyan bisa ngomong PVS-Studio kanggo nimbang bebaya iki ora salaras kanggo saiki (nyimpen utang technical mengko), lan ora bakal nuduhake maneh. Analisa nggawe file khusus sing nyimpen informasi babagan kesalahan sing durung menarik. Lan saiki PVS-Studio bakal ngetokake bebaya mung kanggo kode anyar utawa diganti. Kajaba iku, kabeh iki ditindakake kanthi pinter. Yen, umpamane, baris kosong ditambahake ing wiwitan file kode sumber, banjur analisa ngerti yen, nyatane, ora ana sing owah, lan bakal terus meneng. File markup iki bisa dilebokake ing sistem kontrol versi. File kasebut gedhe, nanging iki ora dadi masalah, amarga ora ana gunane kanggo nyimpen asring.
Saiki kabeh programer bakal weruh bebaya mung ana hubungane karo kode anyar utawa diganti. Mangkono, sampeyan bisa miwiti nggunakake analyzer, minangka padha ngomong, saka dina sabanjurΓ©. Lan sampeyan bisa bali menyang utang technical mengko, lan mboko sithik mbenerake kasalahan lan ngatur analyzer.
Dadi, masalah pisanan karo implementasine analyzer ing proyek lawas gedhe wis ditanggulangi. Saiki ayo dipikirake apa sing kudu ditindakake karo utang teknis.
Ndandani bug lan refactorings
Sing paling gampang lan paling alami yaiku nyisihake sawetara wektu kanggo nganalisa peringatan analisa sing ditindhes sacara massal lan mboko sithik ngatasi. Nang endi wae sampeyan kudu ndandani kesalahan ing kode, nang endi wae sampeyan kudu refactor marang analyzer sing kode ora masalah. Tuladha prasaja:
if (a = b)Paling C ++ compiler lan analyzers sambat babagan kode kuwi, wiwit ana kemungkinan dhuwur sing bener wanted kanggo nulis (a == b). Nanging ana persetujuan sing ora diucapake, lan iki biasane dicathet ing dokumentasi, yen ana tanda kurung tambahan, mula dianggep programmer sengaja nulis kode kasebut, lan ora perlu sumpah. Contone, ing dokumentasi PVS-Studio kanggo diagnostik wis ditulis kanthi cetha yen baris ing ngisor iki bakal dianggep bener lan aman:
if ((a = b))Conto liyane. Apa lali ing kode C ++ iki? break utawa ora?
case A:
foo();
case B:
bar();
break;Analisa PVS-Studio bakal menehi bebaya ing kene . Iki bisa uga dudu kesalahan, mula sampeyan kudu menehi tandha parser kanthi nambah atribut kasebut utawa contone __atribut__((gagal)):
case A:
foo();
[[fallthrough]];
case B:
bar();
break;Bisa diarani owah-owahan kode kasebut ora ndandani bug kasebut. Ya, iki bener, nanging nindakake rong perkara sing migunani. Kaping pisanan, laporan analisa ngilangi positip palsu. Kapindho, kode kasebut dadi luwih dingerteni kanggo wong sing melu perawatan. Lan iki penting banget! Iki waΓ©, iku worth nindakake refactorings suntingan kanggo nggawe kode bening lan luwih gampang kanggo njaga. Wiwit analisa ora ngerti apa "break" perlu utawa ora, iku uga ora cetha kanggo fellow programmer.
Saliyane mbecike bug lan refactorings, sampeyan bisa nyegah peringatan analisa sing jelas palsu. Sawetara diagnostik sing ora cocog bisa dipateni. Contone, ana sing nganggep bebaya ora ana gunane babagan mbandhingake float / nilai pindho. Lan sawetara nggolongake minangka penting lan layak kanggo sinau []. Bebaya endi sing dianggep relevan lan sing ora gumantung ing tim pangembangan kanggo mutusake.
Ana cara liya kanggo nyuda tandha palsu. Contone, markup makro wis kasebut sadurunge. Kabeh iki diterangake luwih rinci ing dokumentasi. Ingkang paling penting yaiku mangertos yen sampeyan kanthi bertahap lan sistematis nyedhaki nggarap positip palsu, ora ana sing salah. Akèh-akèhé saka bebaya uninteresting ilang sawise konfigurasi, lan mung panggonan sing tenan mbutuhake sinau ati-ati lan sawetara owah-owahan ing kode tetep.
Kajaba iku, kita mesthi mbantu para klien nyiyapake PVS-Studio yen ana alangan. Kajaba iku, ana kasus nalika awake dhewe ngilangi bebaya palsu lan mbenerake kesalahan []. Mung ing kasus, aku mutusakΓ© kanggo sebutno pilihan iki kanggo kerjasama lengkap uga bisa :).
Metode ratchet
Ana pendekatan liyane sing menarik kanggo nambah kualitas kode kanthi bertahap kanthi ngilangi bebaya penganalisa statis. Ing ngisor iki yaiku jumlah bebaya mung bisa nyuda.
Jumlah bebaya sing ditanggepi dening penganalisa statis direkam. Gerbang kualitas dikonfigurasi kanthi cara sing saiki sampeyan mung bisa ngetik kode sing ora nambah jumlah operasi. AkibatΓ©, proses ngurangi jumlah weker kanthi bertahap diwiwiti kanthi nyetel analisa lan mbenerake kesalahan.
Malah yen wong pengin ngapusi sethitik lan mutusakΓ© kanggo pass gapura kualitas ora mbusak bebaya ing kode anyar, nanging nambah kode saka pihak katelu lawas, iki ora medeni. Kabeh padha, ratchet muter ing siji arah, lan mboko sithik jumlah cacat bakal suda. Malah yen wong ora pengin ndandani cacat anyar dhewe, iku isih kudu nambah soko ing kode tetanggan. Ing sawetara titik, cara sing gampang kanggo nyuda jumlah bebaya wis rampung, lan ana titik nalika bug nyata bakal didandani.
Metodologi iki diterangake kanthi luwih rinci ing artikel sing menarik banget dening Ivan Ponomarev "", sing dakkarepake maca kanggo sapa wae sing kepengin ningkatake kualitas kode.
Penulis artikel uga duwe laporan babagan topik iki: "".
kesimpulan
Muga-muga sawise artikel iki, para pamaca bakal luwih nrima alat analisis statis lan pengin ngetrapake ing proses pangembangan. Yen sampeyan duwe pitakonan, kita tansah siyap kedhaftar analyzer statis PVS-Studio lan bantuan karo implementasine.
Ana keraguan khas liyane babagan apa analisis statis pancen trep lan migunani. Aku nyoba ngilangi sebagian besar keraguan kasebut ing publikasi "Alasan kanggo ngenalake penganalisa kode statis PVS-Studio menyang proses pangembangan" [].
Matur nuwun kanggo perhatian lan teka lan nyoba analyzer PVS-Studio.
pranala tambahan
- Andrey Karpov.
- Wikipedia. .
- Andrey Karpov, Victoria Khanieva. .
- PVS-Studio. Dokumentasi. .
- Andrey Karpov. .
- PVS-Studio. Dokumentasi. .
- Ivan Andryashin. .
- Pavel Eremeev, Svyatoslav Razmyslov. .
- Andrey Karpov. .
Yen sampeyan pengin nuduhake artikel iki karo pamirsa sing nganggo basa Inggris, gunakake tautan terjemahan: Andrey Karpov. .
Source: www.habr.com