😯 🥣 📸 Alasan untuk memperkenalkan analisa kode statis PVS-Studio ke dalam proses pengembangan 🎟️ 🤳🏾 🥨

Alasan untuk memperkenalkan analisis data statistik PVS-Studio ke dalam proses pengembangan

PVS-Studio adalah alat untuk menemukan kesalahan dan kerentanan potensial dalam kode sumber program yang ditulis dalam C, C ++, C # atau Java. PVS-Studio termasuk dalam kelas alat untuk pengujian keamanan aplikasi statis (Static Application Security Testing, SAST). Alat analisis difokuskan pada praktik integrasi berkelanjutan (CI) dan memungkinkan Anda untuk mengidentifikasi kesalahan pada tahap paling awal ketika memperbaikinya hampir tidak ada biaya.

Analisis kode statis

Proyek perangkat lunak dalam proses pengembangannya menjadi semakin banyak. Contoh:

Kernel Linux 1.0.0: 176.000 baris kode
Kernel Linux 5.0: 26.000.000 baris kode
Photoshop 1.0: 128.000 baris kode
Photoshop CS 6: 10.000.000 baris kode

Sebagai proyek tumbuh dalam ukuran, kompleksitasnya tumbuh lebih cepat daripada linear. Untuk alasan ini, ketika ukuran basis kode bertambah, demikian juga kepadatan kesalahan. Salah satu cara untuk mengimbangi kompleksitas yang berkembang adalah dengan menggunakan alat analisis kode statis.

Penganalisa statis adalah program asisten programmer yang melakukan tinjauan awal kode dan menunjukkan fragmen kode yang lebih cenderung mengandung kesalahan. Berkat ini, banyak kesalahan dapat diperbaiki pada tahap awal ketika biaya memperbaikinya minimal.

Analisis statis tidak menggantikan, tetapi melengkapi metodologi deteksi cacat lainnya, seperti tinjauan kode, uji unit, analisis kode dinamis, uji regresi, pengujian manual, dan sebagainya.

Misalnya, jika kita berbicara tentang ulasan kode , jauh lebih baik jika program mendeteksi kesalahan sederhana. Kemudian programmer yang meninjau kode akan dapat fokus pada pemeriksaan tingkat tinggi yang lebih bermanfaat dari algoritma, dan tidak akan dipaksa untuk membaca fungsi perbandingan . Selain itu, seperti yang diperlihatkan oleh praktik , banyak kesalahan sangat sulit untuk dicari “dengan mata Anda” dan mereka sangat mungkin melewati fase peninjauan kode tanpa disadari.

Keuntungan lain dari alat analisis statis adalah keberadaan database kaya pola kesalahan. Mereka dapat menemukan masalah keberadaan yang mungkin tidak disadari oleh programmer. Beberapa contoh: V698 , V718 , V1023 .

PVS-Studio

Kami merekomendasikan penerapan penganalisa kode statis PVS-Studio yang kami kembangkan dalam proses pengembangan. Produk ini berjalan pada sistem 64-bit pada Windows, Linux, dan macOS dan dapat menganalisis kode yang ditujukan untuk platform ARM 32-bit, 64-bit, dan tertanam.

Pada saat publikasi artikel ini, penganalisis mendukung bahasa dan kompiler berikut:

Windows Visual Studio 2010-2019 C, C ++, C ++ / CLI, C ++ / CX (WinRT), C #
Windows IAR Embedded Workbench, C / C ++ Compiler untuk ARM C, C ++
Windows QNX Momentics, QCC C, C ++
Windows / Linux Keil μVision, DS-MDK, ARM Compiler 5/6 C, C ++
Windows / Linux Studio Komposer Kode Texas Instruments, Alat Pembuatan Kode ARM C, C ++
Windows / Linux / macOS. GNU Arm Embedded Toolchain, kompiler GCC Arm Embedded, C, C ++
Windows / Linux / macOS. Dentang C, C ++
Linux / macOS. GCC C, C ++
Windows MinGW C, C ++
Windows / Linux / macOS. Jawa

Alat analisis memiliki dokumentasi terperinci dalam bahasa Inggris dan Rusia. Deskripsi aturan diagnostik berisi contoh kode yang benar dan salah, serta tautan ke contoh kesalahan nyata yang ditemukan dalam proyek sumber terbuka.

Untuk kenyamanan spesialis yang akan menggunakan PVS-Studio sebagai alat SAST , penganalisis menampilkan peringatannya pada Pencacahan Kelemahan Umum, Standar Pengodean CERT SEI dan standar MISRA. Tabel kepatuhan diagnosa PVS-Studio dengan berbagai standar:

Alat analisis ini dapat digunakan baik secara independen dan berintegrasi dengan Visual Studio dan IntelliJ IDEA. Selain itu, baru-baru ini sejumlah pelanggan kami telah menggunakan PVS-Studio sebagai bagian dari SonarQube. PVS-Studio, yang terhubung sebagai plug-in ke SonarQube, adalah sumber tambahan pesan diagnostik.

Berbagai skenario integrasi dalam CI telah dikerjakan. Pertimbangan semua skenario berada di luar cakupan artikel ini dan lebih baik berkonsultasi dengan dokumentasi. Berikut ini hanya beberapa tautan sehingga pembaca dapat membuat kesan umum:

Penganalisa PVS-Studio secara efektif mendeteksi berbagai kesalahan, dari kesalahan ketik hingga kebocoran memori . Ini dimungkinkan berkat analisis aliran data, eksekusi simbolis, pencocokan pola, anotasi metode (termasuk otomatis). Anda dapat mempelajari lebih lanjut tentang prinsip-prinsip operasi dari artikel " Teknologi yang Digunakan dalam Analyzer Kode PVS-Studio untuk Menemukan Kesalahan dan Kerentanan Potensial ".

Mengapa Anda harus menggunakan PVS-Studio

Dengan memperkenalkan penganalisis kode statis PVS-Studio ke dalam proses pengembangan, Anda akan mengurangi biaya memperbaiki banyak kesalahan. Ini membebaskan waktu untuk mengimplementasikan fungsionalitas baru atau untuk pengujian tingkat tinggi yang lebih menyeluruh.

Dengan penggunaan analisa yang teratur, kode tersebut akan secara bertahap menjadi lebih baik, yang akan memudahkan pemeliharaannya. Koreksi kesalahan sistematis dan praktik penulisan kode berkualitas tinggi akan mengurangi kemungkinan mendeteksi kerentanan nol hari dalam proyek. Topik ini dibahas secara lebih rinci dalam artikel " Bagaimana PVS-Studio dapat membantu dalam mencari kerentanan? "

Menggunakan alat PVS-Studio bermanfaat dalam tim yang terdiri dari lima orang atau lebih. Anda dapat berkenalan dengan metode penghitungan efisiensi penggunaan alat analisa dalam artikel " PVS-Studio ROI ".

Untuk proyek yang dikembangkan oleh satu atau dua penggemar, penganalisa PVS-Studio kemungkinan besar akan berlebihan. Namun, ini juga dapat digunakan dalam proyek kecil seperti itu, terutama karena kami menyediakan beberapa opsi lisensi gratis untuk siswa, proyek sumber terbuka, dll.

Paling sering, pada awalnya, pelanggan kami memperoleh lisensi selama satu tahun. Setelah satu tahun, ketika mereka yakin bahwa kemampuan penganalisa dan dukungan mereka sepenuhnya puas, mereka memperbarui lisensi untuk dua atau tiga tahun sekaligus. Ini memungkinkan mereka untuk mendapatkan diskon besar. Anda dapat meminta harga dan berkonsultasi tentang masalah lisensi di sini .

Menjadi pelanggan kami Menggunakan PVS-Studio, Anda akan meningkatkan kematangan proses pengembangan, menghemat uang dalam memerangi bug, dan membuat perangkat lunak yang lebih baik.

Kami akan memberi Anda dukungan cepat dan berkualitas. Pertanyaan-pertanyaan dijawab langsung oleh para programmer yang mengembangkan modul-modul tempat pertanyaan tersebut muncul. Ini membantu mendapatkan jawaban bahkan dalam situasi sulit. Salah satu contoh komunikasi tersebut adalah " Positif palsu di PVS-Studio: seberapa dalam lubang kelinci ."

Balasan Keberatan

Kadang-kadang programmer negatif memahami ide memperkenalkan analisis kode statis ke dalam proses pengembangan, mengkritik metodologi analisis statis secara keseluruhan atau khusus alat PVS-Studio. Ketika diskusi dimulai, ternyata kritik itu tidak dibuktikan dan hanya berasal dari keengganan untuk mengubah sesuatu dalam proses pembangunan yang ditetapkan. Pertimbangkan argumen khas untuk tidak mengubah apa pun, dan apa kelemahan mereka.

“Analisis statis akan mengambil bagian dari waktu kerja”

Pernyataan "analisis statis akan mengambil bagian dari waktu kerja" dalam isolasi dari konteksnya adalah benar. Meninjau secara teratur peringatan penganalisa statis yang dikeluarkan untuk kode baru atau yang diubah benar-benar membutuhkan waktu. Namun, pemikiran itu harus dilanjutkan: tetapi waktu yang dihabiskan untuk ini jauh lebih sedikit daripada biaya mengidentifikasi kesalahan dengan metode lain.

Dari mana pendapat tentang perlunya meluangkan waktu untuk memperingatkan penganalisa kode statis?

Pemrogram masih belum terbiasa dengan metodologi analisis kode yang mengacaukan tes berjalan dan penggunaan reguler. Pada permulaan pertama, setiap analis memberikan daftar besar peringatan, banyak di antaranya palsu. Alasannya adalah bahwa penganalisa belum dikonfigurasi. Analyzer yang disetel menghasilkan sejumlah kecil kesalahan positif selama peluncuran reguler. Dengan kata lain, dengan penggunaan reguler, sebagian besar peringatan akan mendeteksi cacat nyata atau kode bau. Hanya penting untuk membuat pengaturan ini.

Topik ini dijelaskan secara lebih rinci dalam artikel " Bekerja dengan Keberatan: Analisis Statis Akan Mengambil Bagian dari Waktu Kerja ".

"Penganalisis statis sangat bising (menghasilkan banyak positif palsu)"

Seperti disebutkan di atas, kesimpulan ini dibuat menggunakan penganalisa kode yang tidak dikonfigurasi. Setelah menyiapkan PVS-Studio, Anda dapat mengharapkan bahwa persentase positif palsu akan 10-20%. Artinya, dengan lima peringatan yang dikeluarkan, empat akan menunjukkan kesalahan nyata atau kode yang kemungkinan menyebabkan kesalahan di masa depan. Contoh pengaturan seperti itu dapat dilihat pada artikel " Spesifikasi penganalisa PVS-Studio menggunakan contoh EFL Core Libraries, 10-15% dari false positive ".

Alasan lain yang mendistorsi gagasan penganalisa, adalah keinginan untuk memasukkan sebanyak mungkin peringatan, tanpa memahami tujuannya. Misalnya, jika Anda mengaktifkan aturan MISRA yang difokuskan pada sistem tertanam untuk aplikasi Windows klasik, penganalisis menghasilkan ratusan ribu peringatan. Tidak akan ada arti praktis di dalamnya. Terutama diagnostik yang tidak perlu mengganggu pada tahap perkenalan dengan alat dan membentuk kesalahpahaman tentang kemampuan diagnostiknya. Artikel " Bagaimana cara cepat melihat peringatan menarik bahwa alat analisa PVS-Studio untuk kode C dan C ++? " Membantu untuk menghindari ini.

“Memperkenalkan analisis statis ke dalam proses pengembangan sangat sulit, panjang dan mahal”

Sangat baik, kekhawatiran ini tercermin dalam komentar ini:

Sayangnya, analisa statis itu sendiri tidak lebih dari mainan. Memperkenalkan mereka ke dalam alur kerja adalah pekerjaan yang sangat berat, Anda harus memilih individu untuk memproses dan memfilter hasilnya. Upaya mengalihkan tugas-tugas ini ke pundak pengembang biasa biasanya tidak menghasilkan apa-apa.

Tidak begitu menakutkan. Setidaknya ada tiga pendekatan yang memungkinkan Anda menerapkan analisis statis dengan susah payah bahkan dalam proyek-proyek besar yang lama.

Pendekatan pertama. "Metode Ratchet", yang Ivan Ponomarev berbicara dengan baik dalam laporannya " Analisis Kode Statis Berkelanjutan ".

Pendekatan kedua. Untuk mulai menggunakan analisis statis dengan cepat, kami menawarkan pelanggan PVS-Studio untuk menggunakan " markup base ". Ide umumnya adalah sebagai berikut. Pengguna memulai penganalisa dan menerima banyak peringatan. Karena sebuah proyek yang telah dikembangkan selama bertahun-tahun, masih hidup, berkembang dan membawa uang, maka kemungkinan besar tidak akan ada banyak peringatan dalam laporan yang mengindikasikan cacat kritis. Dengan kata lain, bug kritis telah diperbaiki dengan satu atau lain cara dengan cara yang lebih mahal atau berkat umpan balik dari pelanggan. Karenanya, segala sesuatu yang ditemukan oleh penganalisa sekarang dapat dianggap sebagai hutang teknis, yang tidak praktis untuk segera dihilangkan.

Anda dapat memberi tahu PVS-Studio untuk mempertimbangkan peringatan ini sebagai tidak relevan (menunda utang teknis untuk nanti), dan tidak menunjukkannya lagi. Penganalisis membuat file khusus di mana ia menyimpan informasi tentang kesalahan yang tidak menarik sejauh ini. Dan sekarang PVS-Studio akan mengeluarkan peringatan hanya pada kode baru atau yang diubah. Apalagi semua ini diimplementasikan dengan cerdas. Jika, misalnya, baris kosong ditambahkan ke awal file .cpp tertentu, maka penganalisa memahami bahwa, pada kenyataannya, tidak ada yang berubah, dan akan tetap diam. File markup ini dapat disematkan dalam sistem kontrol versi. File ini besar, tetapi tidak menakutkan, karena sering kali tidak masuk akal untuk meletakkannya.

Sekarang semua programmer akan melihat peringatan yang terkait dengan kode baru atau yang diubah. Dengan demikian, penganalisa dapat mulai menggunakan apa yang disebut hari berikutnya. Dan akan mungkin untuk kembali ke hutang teknis nanti, dan secara bertahap memperbaiki kesalahan dan mengkonfigurasi analisa.

Pendekatan ketiga. Anda dapat menyimpulkan kontrak dengan kami dan mendelegasikan kepada tim kami pekerjaan mengatur dan mengintegrasikan analisis statis. Contoh praktik ini: " Bagaimana tim PVS-Studio meningkatkan kode Unreal Engine ."

"Kami meluncurkan penganalisa dan tidak menemukan sesuatu yang menarik"

Ini sepenuhnya mungkin, tetapi ini tidak berarti bahwa alat analisa tidak akan berguna. Masalahnya adalah bahwa kesalahan diperbaiki dengan metode yang lebih mahal. Ini adalah cara mengambil teks buku, sudah dibaca oleh beberapa korektor, dan melihat apa yang bisa ditemukan pemeriksa ejaan dalam Microsoft Word. Sedikit kesalahan akan ditemukan, tetapi tidak mengikuti dari sini bahwa fungsi cek di Word tidak akan berguna ketika menulis teks baru.

Topik ini dibahas secara lebih rinci dalam artikel " Filsafat Analisis Kode Statis: kami memiliki 100 programmer, penganalisa menemukan beberapa kesalahan, apakah itu tidak berguna? ".

“Alat analisis statis itu mahal, lebih baik untuk menyewa programmer / tester lain”

Bahkan, ini berarti Anda tidak ingin mengubah apa pun. Memang, sebelum tim tumbuh dan diisi ulang dengan programmer dan penguji baru. Namun, ini tidak mengarah pada peningkatan signifikan dalam kematangan proses pembangunan. Meskipun demikian, mari kita periksa keberatan ini secara lebih rinci.

Pertama, mengajak orang tambahan untuk mencari kesalahan jauh lebih mahal daripada mulai menggunakan penganalisa kode. Hitung dana gaji seseorang untuk tahun itu. Tambahkan pajak dan pengaturan tempat kerja. Argumen bahwa lisensi itu mahal tidak lagi menjadi argumen. Dan tetap saja penganalisa statis, tidak seperti orang itu, tidak pergi berlibur, tidak sakit dan tidak pergi. Jika kita berbicara tentang tim besar, misalnya, 100 orang, maka untuk mendapatkan efek, Anda perlu merekrut beberapa orang. Kesenjangan dalam mendukung analisa statis melebar.

Kedua, efek terbesar dicapai karena sinergi menggunakan berbagai teknik pencarian kesalahan. Beberapa kesalahan terdeteksi dengan baik oleh unit test, beberapa dengan pengujian manual, dan sebagainya. Bayangkan situasinya. Proyek ini memiliki 10 programmer, banyak tes unit ditulis, tetapi tidak ada penguji. Kualitas proyek tidak sesuai dengan pengguna dan idenya adalah membuka pekerjaan sebagai penguji. Tetapi ini tidak dilakukan dengan dalih “lebih baik untuk merekrut programmer lain”, biarlah ada lebih banyak unit test! Setuju, ini keputusan yang salah. Jelas, proses penjaminan kualitas satu sisi dan penambahan pengujian manual akan membawa manfaat yang jauh lebih besar. Situasi yang sama dengan analisis statis.

"Analisis dinamis lebih efisien daripada statis."

Analisis statis menemukan beberapa kesalahan dengan baik. Beberapa di antaranya adalah penganalisis dinamis. Alat-alat ini saling melengkapi satu sama lain dan tidak masuk akal untuk memilih satu hal.

Misalnya, penganalisis dinamis tidak dapat menemukan banyak kesalahan ketik atau mendeteksi kode yang tidak dapat dijangkau. Dalam artikel " Memvalidasi Valgrind Dynamic Analyzer Code Menggunakan Static Analyzer ", Anda mungkin menemukan beberapa kesalahan ini.

“Tes unit lebih efisien daripada analisis kode statis”

Jika Anda memilih antara menulis unit test dan analisis statis, maka mungkin tes akan lebih penting dan bermanfaat. Tetapi tidak ada pilihan yang harus dibuat. Penting untuk menggunakan kedua tes unit dan analisis kode statis. Metodologi pencarian kesalahan ini saling melengkapi dengan sempurna.

Analisis statis akan melengkapi pengujian unit karena alasan berikut:

Tidak ada yang menguji tes itu sendiri dan mereka sering mengandung kesalahan. Dalam artikel kami, kami telah berulang kali mengutip contoh kesalahan dalam kode uji unit. Dengan demikian, analisis statis dapat menemukan kesalahan dalam tes, yang, pada gilirannya, dapat menemukan kesalahan dalam kode aplikasi utama.
Tes sangat sulit untuk mencakup semua kode. Terutama ketika datang ke kode untuk menangani situasi darurat. Analisis statis memeriksa semua kode.
Beberapa kesalahan tidak mungkin atau sangat sulit dideteksi dengan unit test. Contoh: V597 (CWE-14) .
Beberapa kesalahan muncul hanya ketika memproses sejumlah besar data, dan uji unit tidak praktis untuk memodelkan situasi seperti itu. Contohnya adalah overflow variabel 32-bit dalam program 64-bit ( V108 , V127 ).
Lebih mudah dan lebih cepat untuk menemukan kesalahan dengan menjalankan analisis statis daripada men-debug kode ketika ternyata tidak berhasil pada unit test. Tentu saja, unit test akan menemukan lebih banyak kesalahan, tetapi jika beberapa dari mereka dapat ditemukan dengan cara yang lebih murah (analisis statis), mengapa tidak menggunakannya.
Kami menemukan sejumlah besar kesalahan dalam berbagai proyek. Banyak dari proyek ini dicakup oleh tes, tetapi seperti yang Anda lihat, ini tidak membantu. Jadi tidak ada alasan untuk tidak memulai, selain tes unit, juga menggunakan analisis kode statis, sehingga meningkatkan kualitas dan keamanannya.

« , PVS-Studio»

, , , . , , PVS-Studio.

PVS-Studio:

.
( ).
.

, PVS-Studio. . , . , " 31 ".

, . , PVS-Studio :

PS

, PVS-Studio, .

Tautan yang bermanfaat

, : Andrey Karpov. Why You Should Choose the PVS-Studio Static Analyzer to Integrate into Your Development Process .

Alasan untuk memperkenalkan analisa kode statis PVS-Studio ke dalam proses pengembangan