Menangani Keberatan: Analisis Statis Akan Menghabiskan Waktu Kerja

Berbicara kepada orang-orang di konferensi dan dalam komentar untuk artikel, kami menghadapi keberatan berikut: analisis statis mengurangi waktu untuk mendeteksi kesalahan, tetapi memakan waktu programmer, yang meniadakan manfaat menggunakannya dan bahkan memperlambat proses pengembangan. Mari kita luruskan keberatan ini dan mencoba menunjukkan bahwa itu tidak berdasar.

Pernyataan "analisis statis akan menghilangkan sebagian waktu kerja" yang diambil dari konteksnya adalah benar. Jelas diperlukan beberapa waktu untuk secara teratur meninjau peringatan penganalisa, dikeluarkan untuk kode baru atau yang dimodifikasi. Namun, kita harus melanjutkan gagasan itu: tetapi waktu yang dihabiskan untuk ini jauh lebih sedikit daripada waktu yang dibutuhkan untuk menemukan kesalahan dengan metode lain. Lebih buruk lagi untuk mengetahui tentang kesalahan dari pengguna.

Unit test dapat menjadi analogi yang sangat bagus di sini. Tes unit juga membutuhkan waktu dari pengembang, tetapi bukan alasan untuk tidak menggunakannya. Manfaat kode yang lebih aman dengan kualitas yang lebih baik saat menggunakan tes unit lebih besar daripada biaya penulisan mereka.

Analogi lain: peringatan kompiler. Ini umumnya topik yang sangat dekat, karena peringatan alat analisis statis dapat dianggap sebagai perpanjangan dari peringatan kompiler sampai batas tertentu. Tentu saja, ketika seorang programmer melihat peringatan kompiler, ia meluangkan waktu untuk menanganinya. Dia harus mengubah kode atau dengan jelas menghabiskan waktu menekan peringatan, misalnya, menggunakan #pragma. Namun, komitmen waktu ini tidak pernah menjadi alasan untuk menonaktifkan peringatan kompiler. Dan jika seseorang melakukan itu, itu akan secara tegas ditafsirkan oleh orang lain sebagai saksi profesional.

Namun, dari mana rasa takut membuang-buang waktu untuk peringatan dari penganalisa kode statis berasal?

Jawabannya sangat sederhana. Programmer yang belum terbiasa dengan metodologi ini membingungkan peluncuran uji coba dan penggunaan reguler. Pada tahap pertama, setiap analis memberikan daftar peringatan yang besar, yang bahkan menakutkan untuk dilihat. Alasannya adalah bahwa penganalisa belum dikonfigurasi. Sedangkan penganalisa yang terkonfigurasi mengeluarkan sejumlah kecil kesalahan positif yang digunakan secara teratur. Dengan kata lain, sebagian besar peringatan menunjukkan cacat nyata atau bau kode. Hanya penting untuk melakukan konfigurasi ini. Ini adalah trik yang mengubah penganalisa statis dari kejahatan yang menghabiskan waktu menjadi teman dan asisten.

Setiap penganalisa statis pertama-tama akan mengeluarkan banyak positif palsu. Ada banyak alasan untuk ini, dan topik ini layak mendapat artikel terpisah. Secara alami, baik pengembang analis lain maupun tim kami berjuang melawan positif palsu. Tetapi masih akan ada banyak peringatan, jika Anda hanya mengambil dan menjalankan alat analisis pada proyek untuk pertama kalinya. Omong-omong, situasi yang sama adalah dengan peringatan kompiler. Misalkan, Anda memiliki proyek besar yang selalu Anda buat, misalnya, dengan kompiler Visual C ++. Katakanlah, proyek secara ajaib ternyata portabel dan dikompilasi menggunakan GCC. Meski begitu, Anda akan mendapatkan banyak peringatan dari GCC. Orang-orang yang telah mengalami perubahan kompiler dalam proyek besar memahami apa yang saya bicarakan.

Namun, tidak ada yang memaksa Anda untuk terus menggali tumpukan peringatan setelah mengubah kompilator atau setelah menjalankan penganalisa. Langkah selanjutnya yang jelas adalah mengatur compiler atau analyzer. Mereka yang mengatakan "analisis peringatan memakan waktu" menilai kompleksitas mengadopsi alat, hanya memikirkan semua peringatan ini yang perlu diatasi di awal, tetapi jangan berpikir tentang penggunaan rutin yang tidak tergesa-gesa.

Menyiapkan analis, juga kompiler, tidak sesulit dan sekuat tenaga seperti yang ingin dilakukan oleh programmer. Jika Anda seorang manajer, jangan dengarkan mereka. Mereka hanya malas. Programmer dapat dengan bangga memberi tahu bagaimana dia mencari bug yang ditemukan oleh tester / klien selama 3 hari. Dan itu baik baginya. Namun, dari sudut pandangnya, tidak dapat diterima untuk menghabiskan satu hari menyiapkan alat, setelah itu kesalahan seperti itu akan terdeteksi sebelum masuk ke sistem kontrol versi.

Ya, positif palsu akan muncul setelah pengaturan. Namun jumlah mereka dibesar-besarkan. Sangat mungkin untuk membuat analisa sehingga persentase positif palsu adalah 10% -15%. Artinya, untuk 9 cacat yang ditemukan, hanya 1 peringatan akan membutuhkan penindasan sebagai salah. Jadi di mana "buang-buang waktu" di sini? Pada saat yang sama, 15% adalah nilai yang sangat nyata; Anda dapat membaca lebih lanjut tentang itu di artikel ini.

Masih ada satu hal lagi. Seorang programmer mungkin keberatan:

Nah, katakanlah analisis statis biasa berjalan sangat efektif. Tapi apa yang harus saya lakukan dengan kebisingan yang saya dapatkan pertama kali? Pada proyek besar kami, kami tidak akan dapat mengatur alat untuk 1 hari yang dijanjikan. Hanya kompilasi ulang untuk memeriksa kumpulan pengaturan berikutnya yang membutuhkan waktu beberapa jam. Kami belum siap menghabiskan beberapa minggu untuk ini.

Dan ini bukan masalah, tetapi upaya untuk menemukan alasan untuk tidak memperkenalkan sesuatu yang baru. Tentu saja, dalam proyek besar, semuanya selalu sulit. Tetapi pertama-tama, kami memberikan dukungan dan kami membantu mengintegrasikan PVS-Studio ke dalam proses pengembangan. Dan kedua, tidak perlu untuk segera mulai memilah-milah semua peringatan.

Jika aplikasi Anda berfungsi, maka bug yang ada di sana, tidak terlalu kritis dan mungkin hidup dalam kode yang jarang digunakan. Kesalahan serius yang serius telah ditemukan dan diperbaiki menggunakan metode yang lebih lambat dan lebih mahal. Saya akan menulisnya di bawah di catatan . Bukan itu yang sangat penting sekarang. Tidak ada gunanya melakukan pengeditan besar-besaran dalam kode, mengoreksi banyak kesalahan yang tidak signifikan. Dengan refactoring sebesar itu, mudah untuk memecahkan sesuatu dan kerugiannya akan lebih baik.

Lebih baik mempertimbangkan peringatan utang teknis yang ada. Anda dapat kembali ke hutang nanti dan secara bertahap bekerja dengan peringatan lama. Dengan menggunakan mekanisme penindasan peringatan massal, Anda dapat mulai menggunakan PVS-Studio dengan cepat dalam proyek besar. Berikut deskripsi singkat tentang apa yang terjadi:

1. Anda mengecualikan direktori yang jelas berlebihan (perpustakaan pihak ketiga) dari analisis. Anda sebaiknya melakukannya di awal untuk mengurangi waktu analisis.
2. Anda mencoba PVS-Studio dan menyelidiki peringatan paling menarik . Anda menyukai hasilnya, dan Anda menunjukkan alat itu kepada kolega dan bos. Tim memutuskan untuk mulai menggunakannya secara teratur.
3. Proyek sedang diperiksa. Semua peringatan yang ditekan dinonaktifkan menggunakan mekanisme penindasan massal. Dengan kata lain, semua peringatan yang Anda miliki pada saat ini sekarang dianggap sebagai hutang teknis yang dapat direvisi nanti.
4. File yang dihasilkan dengan peringatan yang ditekan masuk ke sistem kontrol versi. File ini besar, tetapi tidak apa-apa. Anda melakukan tindakan ini hanya sekali (atau, setidaknya, sangat jarang). Dan sekarang semua pengembang akan memiliki file ini.
5. Sekarang semua pengembang melihat peringatan yang hanya terkait dengan kode baru atau yang dimodifikasi. Sejak saat itu, tim mulai mendapat manfaat dari analisis statis. Selanjutnya, Anda secara bertahap mengatur alat analisis dan berurusan dengan utang teknis.

Omong-omong, sistem penyimpanan untuk peringatan yang tidak menarik cukup cerdas. Hash disimpan untuk saluran dengan potensi kesalahan, serta untuk baris sebelumnya dan berikutnya. Akibatnya, jika Anda menambahkan baris di awal salah satu file, tidak ada yang tersesat dan penganalisa akan tetap diam untuk kode, yang dianggap sebagai hutang teknis.

Saya harap, saya berhasil menghilangkan salah satu prasangka tentang analisis statis. Ayo, unduh dan coba analisa kode statis PVS-Studio kami. Ini akan mendeteksi banyak kesalahan pada tahap awal dan membuat kode Anda secara umum lebih dapat diandalkan dan lebih baik.

Catatan

Saat mengembangkan proyek apa pun, kesalahan baru terus muncul dan diperbaiki. Kesalahan tidak ditemukan "menetap" dalam kode untuk waktu yang lama, dan kemudian banyak dari mereka dapat dideteksi ketika analisis kode statis diterapkan. Ini terkadang memberikan kesan yang salah bahwa analisa statis hanya menemukan beberapa kesalahan yang tidak menarik pada potongan kode yang jarang digunakan. Ya benar - kalau-kalau Anda menggunakan alat analisa secara tidak benar dan menjalankannya hanya dari waktu ke waktu, misalnya, sesaat sebelum rilis. Lebih lanjut tentang topik ini ditulis di sini . Ya, kami sendiri melakukan satu kali pemeriksaan proyek sumber terbuka saat menulis artikel. Tetapi kami memiliki tujuan yang berbeda. Kami fokus pada mendemonstrasikan kemampuan penganalisa kode untuk mendeteksi cacat. Secara umum, tugas ini tidak ada hubungannya dengan meningkatkan kualitas kode proyek dan mengurangi biaya memperbaiki kesalahan.

Tautan Tambahan

1. ROI PVS-Studio .
2. Mengapa Analisis Statis Dapat Meningkatkan Kompleks Kode C ++ .
3. Ivan Ponomarev. Perkenalkan Analisis Statis dalam Prosesnya, Jangan Hanya Mencari Bug dengannya .