👆🏿 👩🏼‍🚒 🆖 Mengapa Anda Harus Memilih Penganalisis Statis PVS-Studio untuk Diintegrasikan ke dalam Proses Pengembangan Anda 🐰 🖤 🤴🏻

PVS-Studio adalah alat untuk mendeteksi bug dan kerentanan potensial dalam kode sumber program yang ditulis dalam C, C ++, C #, atau Java, dan juga merupakan alat Pengujian Keamanan Aplikasi Statis (SAST). Ini dimaksudkan untuk digunakan sebagai bagian dari praktik CI dan memungkinkan pengguna untuk mendeteksi bug pada tahap pengembangan paling awal, di mana mereka hampir tidak memerlukan biaya apa pun untuk memperbaikinya.

Analisis kode statis

Ketika proyek perangkat lunak berkembang, mereka tumbuh dalam ukuran. Bandingkan:

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

Seiring pertumbuhan proyek, kerumitannya tumbuh lebih cepat daripada linear. Ini menjelaskan mengapa kepadatan kesalahan tumbuh bersama dengan basis kode. Salah satu cara untuk menebus kompleksitas yang semakin meningkat adalah dengan menggunakan alat analisis kode statis.

Analisis statis adalah alat perangkat lunak yang melakukan peninjauan kode awal dan menunjukkan fragmen kode yang sangat mungkin mengandung kesalahan. Ini memungkinkan pengembang untuk memperbaiki sebagian besar bug pada tahap pengembangan paling awal, di mana mereka paling murah untuk memperbaikinya.

Analisis statis tidak menggantikan - tetapi lebih melengkapi - praktik pendeteksi bug lainnya seperti tinjauan kode, pengujian unit, analisis dinamis, pengujian regresi, pengujian manual, dan sebagainya.

Ambil ulasan kode , misalnya. Skenario yang jauh lebih baik adalah membuat penganalisa perangkat lunak menemukan bug paling sepele untuk Anda sehingga Anda bisa fokus pada pemeriksaan tingkat tinggi yang lebih bermanfaat dari algoritma daripada mencari tahu fungsi perbandingan - terlebih lagi, karena pengalaman kami membuktikan, mata manusia buruk dalam memperhatikan banyak bug dan mereka sangat mungkin diabaikan selama peninjauan kode.

Keuntungan lain dari alat analisis statis adalah basis pola kesalahan yang luas. Mereka dapat menemukan cacat yang tidak diketahui oleh banyak programmer, seperti V698 , V718 , V1023 .

PVS-Studio

Kami merekomendasikan memilih PVS-Studio, sebuah penganalisa kode statis yang dikembangkan oleh tim kami. Ini berjalan pada sistem Windows, Linux, dan macOS 64-bit dan dapat memeriksa kode sumber program untuk platform ARM 32-bit, 64-bit, dan tertanam.

Pada tulisan 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 dilengkapi dengan dokumentasi terperinci dalam bahasa Inggris dan Rusia. Deskripsi aturan diagnostik mencakup contoh kode yang benar dan salah. Mereka juga menyertakan tautan ke cuplikan kode dari program sumber terbuka nyata.

Untuk para spesialis yang akan menggunakan PVS-Studio sebagai alat SAST , diagnostik dipetakan ke Pencacahan Kelemahan Umum, Standar Pengodean CERT SEI, dan standar MISRA. Berikut adalah tabel pemetaan diagnostik PVS-Studio dengan berbagai standar:

Alat analisis dapat digunakan baik sebagai alat mandiri dan sebagai plugin untuk Visual Studio dan IntelliJ IDEA. Beberapa pelanggan kami juga telah menggunakan PVS-Studio sebagai bagian dari SonarQube belakangan ini. Saat digunakan sebagai plugin untuk SonarQube, penganalisis menyediakan pesan diagnostik tambahan.

Kami telah mengembangkan sejumlah skenario menggunakan PVS-Studio dengan sistem CI. Karena mengamati semua skenario di luar ruang lingkup artikel ini, silakan lihat dokumentasi. Berikut ini beberapa tautan untuk memberi Anda gambaran umum:

PVS-Studio secara efektif mendeteksi berbagai kekurangan dari kesalahan ketik hingga kebocoran memori . Ini dimungkinkan berkat analisis aliran data, eksekusi simbolis, pencocokan pola, dan anotasi metode (termasuk anotasi otomatis). Untuk mempelajari lebih lanjut tentang prinsip kerja di balik alat analisis, lihat artikel " Teknologi yang digunakan dalam alat analisis kode PVS-Studio untuk menemukan bug dan potensi kerentanan ".

Mengapa Anda harus menggunakan PVS-Studio

Mengintegrasikan PVS-Studio ke dalam proses pengembangan Anda akan membuat banyak bug lebih murah untuk diperbaiki, sehingga membantu menghemat waktu, yang dapat Anda investasikan untuk mengimplementasikan fitur baru atau melakukan pengujian tingkat tinggi yang lebih menyeluruh.

Jika digunakan secara teratur, alat analisa pada akhirnya akan membantu Anda meningkatkan kualitas kode Anda, sehingga memudahkan pemeliharaan. Memperbaiki bug secara teratur dan praktik penulisan kode berkualitas tinggi akan membuatnya lebih rentan terhadap kerentanan Zero-day. Subjek ini dibahas secara lebih rinci dalam artikel " Bagaimana PVS-Studio Dapat Membantu dalam Deteksi Kerentanan? ".

PVS-Studio paling hemat biaya bila digunakan oleh tim beranggotakan lima orang dan lebih banyak. Perkiraan ROI diberikan dalam artikel " PVS-Studio ROI ".

Mengintegrasikan PVS-Studio ke dalam proyek-proyek yang dikembangkan oleh beberapa penggemar mungkin tidak praktis, tetapi bahkan proyek-proyek kecil dapat mengambil manfaat darinya - terlebih lagi karena kami menyediakan opsi lisensi gratis untuk siswa, pengembang open-source, dan sebagainya.

Pelanggan baru kami biasanya akan membeli lisensi satu tahun. Saat kedaluwarsa, mereka sudah senang dengan kemampuan penganalisa kami dan layanan dukungan pengguna dan akan memperbarui lisensi selama dua atau tiga tahun, yang jauh lebih murah daripada lisensi satu tahun. Anda dapat meminta harga dan meminta saran tentang lisensi di sini .

Jadilah klien kami dan biarkan PVS-Studio membuat proses pengembangan Anda lebih matang, memperbaiki bug lebih murah, dan kode Anda lebih baik.

Pada gilirannya, kami akan memberi Anda dukungan cepat dan kompeten. Pertanyaan Anda akan ditanggapi langsung oleh programmer yang mengembangkan modul tertentu yang bersangkutan. Ini menjamin mendapatkan jawaban bahkan dalam situasi yang paling rumit. Inilah salah satu contohnya: " Positif Salah dalam PVS-Studio: Seberapa Jauh Lubang Kelincinya ."

Menanggapi kritik

Programmer kadang-kadang negatif tentang gagasan memasukkan analisis kode statis ke dalam proses pengembangan mereka dan mengkritik metode analisis statis secara umum atau PVS-Studio pada khususnya. Ketika Anda mulai menggali lebih dalam, ternyata kritik mereka tidak berdasar dan hanyalah produk dari keengganan mereka untuk mengubah apa pun dalam proses pembangunan yang telah ditetapkan. Mari kita lihat argumen khas apa untuk tidak mengubah situasi yang mereka pilih dan apa yang salah dengan mereka.

"Analisis statis akan mengambil sejumlah waktu kerja Anda"

Di luar konteks, pernyataan "analisis statis akan mengambil sejumlah waktu kerja Anda" adalah benar. Dibutuhkan waktu untuk secara teratur memeriksa keluaran peringatan oleh penganalisa untuk kode yang baru ditulis atau dimodifikasi. Tetapi gagasan itu perlu dilanjutkan: "tapi itu akan memakan waktu jauh lebih sedikit daripada metode pendeteksi bug lainnya."

Mengapa orang percaya bahwa memeriksa laporan analisa statis memakan waktu?

Programmer yang belum terbiasa dengan metode analisis kode membingungkan tes berjalan satu kali dan penggunaan biasa. Ketika dijalankan untuk beberapa kali pertama, analis mana pun akan menampilkan daftar besar peringatan, dengan tingkat positif palsu yang tinggi. Ini terjadi karena alat belum dikustomisasi. Dengan pengaturan yang disesuaikan untuk memenuhi kebutuhan Anda yang sebenarnya, Anda tidak akan melihat banyak kesalahan positif jika Anda menjalankan analisa secara teratur. Dengan kata lain, dengan penggunaan reguler, sebagian besar diagnostik analis akan mendeteksi kesalahan asli atau kode berbau. Anda hanya perlu melakukan tweaking itu.

Artikel " Menangani Keberatan: Analisis Statis Akan Mengambil Bagian dari Waktu Kerja " menguraikan masalah ini.

“Analisis statis menghasilkan terlalu banyak noise (yaitu terlalu banyak false positive)”

Sekali lagi, pernyataan ini benar ketika Anda belum menyesuaikan alat dengan benar. Setelah Anda men-tweak pengaturan PVS-Studio sesuai kebutuhan, Anda dapat mengharapkan tingkat positif palsu turun ke 10-20%. Artinya, dari setiap lima peringatan, empat akan menunjuk bug asli atau kode yang sangat mungkin menjadi sumber bug di masa depan. Artikel " Karakteristik Analyzer PVS-Studio dengan Contoh EFL Core Libraries, 10-15% False Positive " menunjukkan contoh kustomisasi analyzer.

Sumber kesalahpahaman lain adalah godaan untuk menghidupkan sebanyak mungkin diagnosa, tanpa mengetahui tujuan pastinya. Misalnya, jika Anda mengaktifkan set aturan MISRA, yang dirancang untuk sistem tertanam, saat memeriksa aplikasi Windows klasik, penganalisis akan menghasilkan ratusan ribu peringatan, tidak ada yang akan berguna bagi Anda. Diagnostik yang tidak relevan sangat berbahaya bila Anda baru memulai dengan alat ini karena Anda mungkin mendapat kesan yang salah tentang kemampuan diagnostiknya. Artikel " Cara cepat memeriksa peringatan menarik yang diberikan oleh alat analisa PVS-Studio untuk kode C dan C ++? " Akan membantu Anda menghindari kekecewaan.

"Mengintegrasikan analisis statis ke dalam proses pengembangan terlalu mahal dalam hal upaya, waktu, dan uang"

Kekhawatiran ini dengan jelas diilustrasikan oleh komentar berikut:

Sayangnya, analisa statis itu sendiri tidak lebih dari mainan. Pekerjaan yang sangat berat mencoba menjadikan mereka bagian dari proses kerja rutin Anda, dan mengharuskan beberapa staf untuk memeriksa dan menyaring hasil analisis. Setiap upaya untuk menempatkan beban ini pada pengembang biasa biasanya tidak berhasil.

Tidak terlalu mengerikan. Setidaknya ada tiga praktik untuk mengintegrasikan analisis statis dengan lancar bahkan ke proyek-proyek lama yang besar.

Praktek 1. "Ratcheting", yang dijelaskan dengan baik oleh Ivan Ponomarev dalam artikelnya " Perkenalkan Analisis Statis dalam Proses, Jangan Hanya Mencari Bug dengan Itu ".

Praktik 2. Untuk membantu pengguna kami memulai dengan cepat, kami sarankan menggunakan " basis penindasan ". Singkatnya, idenya adalah bahwa Anda menjalankan analisa dan mendapatkan banyak peringatan. Karena proyek ini telah dikembangkan selama bertahun-tahun dan masih hidup, berkembang, dan menguntungkan, Anda tidak akan mendapatkan banyak peringatan yang menunjukkan cacat kritis. Dengan kata lain, sebagian besar bug kritis telah diperbaiki dengan menggunakan cara lain - lebih mahal - atau sebagai tanggapan atas umpan balik pengguna. Dalam hal itu, bug apa pun yang ditemukan selama pemeriksaan pertama, mereka dapat dilihat sebagai utang teknis, yang tidak masuk akal untuk segera diperbaiki.

Anda dapat memberitahu PVS-Studio untuk memperlakukan peringatan ini sebagai tidak relevan (sehingga menunda penyelesaian hutang teknis sampai nanti) dan tidak menunjukkannya lagi. Penganalisis akan membuat file khusus yang menyimpan informasi tentang bug yang saat ini tidak relevan dan akan mengeluarkan peringatan hanya untuk kode yang baru ditulis atau dimodifikasi. Mekanismenya cukup cerdas. Misalnya, jika Anda menambahkan baris kosong di awal beberapa file .cpp, penganalisa akan memahami bahwa baris ini tidak membuat perbedaan, dan tetap diam. File penindasan dapat dikontrol versi. Ini besar, tetapi tidak masalah karena Anda tidak perlu sering-sering mengontrol versi.

Setelah itu, setiap programmer di tim Anda hanya akan mendapatkan peringatan yang dipicu oleh kode yang baru ditulis atau dimodifikasi. Mulai hari berikutnya, Anda akan dapat menggunakan alat analisis sebagai bagian dari pekerjaan rutin Anda. Sedangkan untuk utang teknis, Anda akan dapat melakukannya nanti dan secara bertahap memperbaiki bug dan menyesuaikan pengaturan penganalisa sesuai kebutuhan.

Praktek 3. Anda dapat mendelegasikan tugas mengatur dan mengintegrasikan PVS-Studio ke tim kami dengan membuat kontrak dengan kami. Salah satu contoh praktik ini dijelaskan dalam artikel " Bagaimana Tim PVS-Studio Meningkatkan Kode Mesin Unreal ".

"Kami menjalankan analisa tetapi tidak menemukan hal yang menarik"

Skenario ini sangat mungkin tetapi masih tidak berarti bahwa penganalisa tidak akan berguna. Masalahnya adalah bahwa bug telah ditemukan dan diperbaiki menggunakan cara lain yang lebih mahal. Ini seperti memberi makan teks yang sudah diperiksa oleh sekelompok pengoreksi ke Microsoft Word untuk melihat apakah pemeriksaan ejaan bawaannya dapat menemukan sesuatu. Ini akan menemukan beberapa kesalahan, jika ada, tetapi itu tidak berarti spell check Word tidak berguna ketika menulis teks baru.

Subjek ini dibahas secara lebih rinci dalam artikel " Filsafat Analisis Kode Statis: Kami Memiliki 100 Pengembang, Penganalisa Ditemukan Beberapa Bug, Apakah Penganalisis Tidak Berguna? ".

"Alat analisa statis adalah alat yang mahal; lebih baik kita menyewa programmer / tester tambahan »

Apa yang sebenarnya dikatakan argumen ini adalah bahwa orang tersebut tidak ingin mengubah apa pun. Bagaimanapun, tim mereka telah tumbuh dan mempekerjakan programmer dan penguji baru untuk beberapa waktu, tetapi itu tidak membantu untuk mencapai proses pengembangan yang lebih matang. Karena itu, kita harus menguraikan argumen ini.

Pertama, mempekerjakan orang lain untuk mencari bug jauh lebih mahal daripada membeli penganalisa statis. Hitung saja gaji tahunan karyawan baru dan tambahkan pajak dan pengeluaran untuk menyiapkan ruang kerja baru. Mempertimbangkan angka-angka yang dihasilkan, argumen tentang penganalisa perangkat lunak yang terlalu mahal sepertinya tidak ada argumen sama sekali. Selain itu, penganalisa statis, tidak seperti manusia, tidak akan mengambil liburan atau pergi cuti sakit atau meninggalkan perusahaan sama sekali. Untuk tim besar, katakanlah, 100 orang, Anda harus merekrut bukan hanya satu tetapi beberapa karyawan baru untuk mencapai hasil yang nyata. Dalam hal itu, membeli penganalisa statis menjadi solusi yang lebih menguntungkan.

Kedua, hasil terbaik dicapai melalui sinergi antara berbagai teknik pendeteksi bug yang digunakan dalam kombinasi. Beberapa bug lebih baik didiagnosis melalui pengujian unit, lainnya melalui pengujian manual, dan sebagainya. Bayangkan memiliki 10 programmer yang mengerjakan suatu proyek, dengan banyak unit test tetapi bukan tester tunggal. Para pengguna tidak puas dengan kualitas proyek, sehingga terpikir oleh Anda untuk menyewa seorang penguji, tetapi Anda tidak melakukannya karena "kita sebaiknya menyewa seorang programmer tambahan, biar ada lebih banyak lagi unit test!" bisa disebut keputusan yang bijaksana, bukan? Dalam skenario ini, proses QA jelas berkaki satu dan hanya akan mendapatkan dengan menambahkan pengujian manual. Hal yang sama berlaku untuk analisis statis.

"Analisis dinamis lebih baik daripada analisis statis"

Beberapa bug lebih baik didiagnosis oleh analisis statis, lainnya oleh analisis dinamis. Jenis alat ini saling melengkapi , jadi Anda tidak harus memilih hanya satu.

Misalnya, penganalisis dinamis tidak dapat mendeteksi kode yang tidak dapat dijangkau dan banyak bug yang disebabkan oleh kesalahan pengetikan. Beberapa jenis analisis dinamik bug mengalami kesulitan menemukan yang dijelaskan dalam artikel " Memeriksa kode penganalisa dinamis Valgrind oleh penganalisa statis ".

"Pengujian unit lebih baik daripada analisis statis"

Jika Anda memilih antara tes unit menulis dan menggunakan analisis statis, saya akan mengatakan tes lebih penting dan berharga. Tetapi Anda tidak harus memilih; Anda harus menggunakan pengujian unit dan analisis statis. Teknik-teknik ini bekerja sangat baik bersama.

Berikut adalah argumen untuk menggunakan analisis statis bersama dengan pengujian unit:

Tes itu sendiri tidak diuji dan sering mengandung kesalahan. Dalam artikel kami, kami menunjukkan banyak contoh bug yang ditemukan dalam pengujian unit dalam proyek nyata. Analisis statis dapat menemukan bug dalam tes, yang, pada gilirannya, dapat menemukan bug dalam kode utama.
Sulit untuk menutupi seluruh kode dengan tes, terutama bagian-bagian yang berhubungan dengan penanganan pengecualian. Tidak seperti mereka, analisa statis memeriksa seluruh kode.
Beberapa bug sangat sulit, jika memungkinkan, untuk dideteksi melalui unit test. V597 (CWE-14) adalah salah satu contohnya.
Beberapa bug memanifestasikan diri mereka hanya ketika program bekerja dengan sejumlah besar data, jadi tidak praktis untuk mensimulasikan situasi seperti itu dalam tes unit. Salah satu contohnya adalah melimpah variabel 32-bit dalam program 64-bit ( V108 , V127 ).
Ketika tes tidak lulus, kesalahan dapat ditemukan lebih mudah dan cepat dengan menjalankan analisa statis daripada dengan debugging. Tentu, unit test akan menemukan lebih banyak bug tetapi ketika Anda dapat menangkapnya menggunakan teknik yang lebih murah (yaitu analisis statis), mengapa tidak melakukannya?
Kami menemukan tumpukan bug di berbagai proyek. Banyak dari mereka sangat tertutup dengan tes tetapi, seperti yang Anda lihat, mereka tidak banyak membantu. Jadi tidak ada alasan mengapa Anda tidak boleh mengadopsi analisis statis selain pengujian unit untuk meningkatkan kualitas dan keandalan kode Anda.

"Kompiler gratis kontemporer dapat menemukan bug yang sama dengan PVS-Studio"

Tentu, kompiler berevolusi dan mendapatkan peringatan baru, yang dapat mendeteksi bug. Tetapi Anda tidak dapat berharap banyak dari kompiler dibandingkan dengan solusi berpemilik profesional seperti PVS-Studio.

Alasan memilih PVS-Studio:

Dukungan pengguna yang efisien
Infrastruktur yang sangat berkembang (integrasi dengan produk lain)
Kemampuan diagnostik yang kuat

Dua alasan pertama sudah cukup untuk mengarahkan skala ke arah memilih PVS-Studio, tetapi mari kita bicara tentang diagnostik juga. Kami terus meningkatkan produk kami untuk tetap di depan vendor lainnya. Misalnya, alat kami dapat mendeteksi bug menarik yang dijelaskan dalam artikel " 31 Februari ".

Menyadari bahwa semua yang dikatakan di atas tidak cukup untuk membuat orang yang skeptis berubah pikiran, kami memeriksa kompiler sesekali untuk menunjukkan bahwa mereka juga memiliki bug, yang dapat dideteksi oleh PVS-Studio:

PS

Jika Anda masih ragu apakah Anda harus menggunakan PVS-Studio, lihat saja daftar bug yang ditemukan di berbagai proyek .

Mengapa Anda Harus Memilih Penganalisis Statis PVS-Studio untuk Diintegrasikan ke dalam Proses Pengembangan Anda