Bekerja dengan keberatan: analisis statis akan mengambil bagian dari waktu kerja

Berkomunikasi dengan orang-orang di konferensi dan dalam komentar untuk artikel, kami menemukan keberatan berikut: analisis statis mengurangi waktu yang dihabiskan untuk menemukan kesalahan, tetapi memakan waktu dari programmer, yang menghilangkan manfaat penggunaannya dan bahkan memperlambat proses pengembangan. Mari kita menganalisis keberatan ini dan menunjukkan bahwa itu tidak berdasar.

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 yang dihabiskan untuk mengidentifikasi kesalahan dengan metode lain. Lebih buruk lagi adalah belajar tentang bug dari klien.

Di sini, tes unit bisa menjadi analogi yang sangat bagus. Tes unit juga membutuhkan waktu untuk pengembang, tetapi ini bukan alasan untuk tidak menggunakannya. Manfaat menulis kode yang lebih baik dan lebih dapat diandalkan saat menggunakan tes unit melebihi biaya penulisan mereka.

Analogi lain: peringatan kompiler. Ini umumnya topik yang sangat dekat, karena peringatan alat analisis statis dapat dilihat sebagai perkiraan pertama sebagai perpanjangan dari peringatan kompiler. Secara alami, ketika seorang programmer melihat peringatan kompiler, ia menghabiskan waktu untuk itu. Entah itu harus mengubah kode, atau secara eksplisit menghabiskan waktu menekan peringatan, misalnya, menggunakan #pragma. Namun, kali ini bukan alasan untuk menonaktifkan peringatan kompiler. Dan jika seseorang melakukan ini, itu akan secara jelas ditafsirkan oleh orang lain sebagai ketidakcocokan profesional.

Namun demikian, dari mana ketakutan akan perlunya menghabiskan waktu memperingatkan penganalisa kode statis?

Semuanya sangat sederhana. Programmer yang masih baru dalam metodologi ini mengacaukan tes berjalan dan penggunaan reguler. Pada permulaan pertama, setiap analis memberikan daftar besar peringatan, yang bahkan menakutkan untuk dilihat. Alasannya adalah bahwa penganalisa belum dikonfigurasi. Analyzer yang disetel menghasilkan sejumlah kecil kesalahan positif selama peluncuran reguler. Dengan kata lain, sebagian besar peringatan mengungkapkan cacat nyata atau kode bau. Hanya penting untuk membuat pengaturan ini. Ini adalah keseluruhan trik yang mengubah penganalisa statis dari kejahatan, yang membutuhkan waktu, menjadi teman dan penolong.

Setiap penganalisa statis pertama-tama akan menghasilkan banyak positif palsu. Ada banyak alasan untuk ini, dan topik ini layak mendapat artikel terpisah. Secara alami, kami dan pengembang analis lain berjuang dengan positif palsu. Tetapi masih akan ada banyak hal positif jika, tanpa persiapan, Anda tiba-tiba mengambil dan menjalankan alat analisis pada beberapa proyek. Gambar yang sama, omong-omong, dengan peringatan kompiler. Misalkan Anda memiliki proyek besar yang selalu Anda buat, misalnya, menggunakan kompiler Visual C ++. Misalkan proyek secara ajaib portabel dan dikompilasi menggunakan GCC. Meski begitu, Anda akan menerima segunung peringatan dari GCC. Siapa pun yang telah mengalami perubahan kompiler dalam proyek besar memahami apa ini.

Namun, tidak ada yang memaksa untuk terus menggali di pegunungan sampah dari peringatan setelah mengubah kompilator atau setelah memulai penganalisa. Langkah alami berikutnya adalah mengkonfigurasi kompiler atau analisa. Mereka yang mengatakan “analisis peringatan itu menyita waktu” menilai kompleksitas penerapan alat ini, hanya memikirkan semua peringatan yang perlu diatasi di awal, tetapi jangan berpikir tentang tenangnya penggunaan rutin.

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

Ya, alarm palsu akan muncul setelah penyetelan. Namun jumlah mereka dibesar-besarkan. Sangat mungkin untuk mengkonfigurasi analisa sehingga persentase positif palsu adalah 10% -15%. Yaitu 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, yang dapat ditemukan lebih detail dalam artikel ini.

Masih ada satu hal lagi. Programmer dapat mengajukan keberatan:

Nah, misalkan menjalankan analisis statis teratur sangat efektif. Tapi apa yang harus dilakukan dengan kebisingan awal? Pada proyek besar kami, kami tidak akan dapat mengkonfigurasi alat untuk 1 hari yang dijanjikan. Hanya satu kompilasi ulang untuk memeriksa kumpulan pengaturan berikutnya yang membutuhkan waktu beberapa jam. Kami belum siap untuk menghabiskan beberapa minggu untuk semua ini.

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

Karena aplikasi Anda berfungsi, itu berarti bahwa kesalahan di sana tidak begitu kritis dan kemungkinan besar hidup dalam kode yang jarang digunakan. Kesalahan terbuka yang serius telah ditemukan dan diperbaiki menggunakan metode yang lebih lambat dan lebih mahal. Tetapi tentang hal itu di bawah ini dalam sebuah catatan . Sekarang sesuatu yang penting bagi kami. Tidak masuk akal untuk melakukan pengeditan besar-besaran dalam kode, memperbaiki banyak kesalahan kecil. Dengan begitu banyak refactoring, sesuatu mudah rusak dan akan ada lebih banyak ruginya daripada kebaikan.

Lebih baik menganggap peringatan yang ada sebagai utang teknis. Dimungkinkan untuk kembali ke hutang nanti dan bekerja dengan peringatan lama secara bertahap. Menggunakan mekanisme penindasan lansiran massa , Anda dapat mulai dengan cepat menggunakan PVS-Studio dalam proyek besar. Secara singkat, ini terjadi seperti ini:

1. Anda mengecualikan direktori berlebihan berlebihan (perpustakaan pihak ketiga) dari analisis. Bagaimanapun, pengaturan ini paling baik dilakukan di awal untuk mengurangi waktu analisis.
2. Anda mencoba PVS-Studio dan mempelajari peringatan paling menarik . Anda menyukai hasilnya, dan Anda menunjukkan alat itu kepada kolega dan atasan. Tim memutuskan untuk memulai penggunaan regulernya.
3. Proyek sedang diverifikasi. Semua peringatan yang ditemukan dinonaktifkan menggunakan mekanisme penindasan massal. Dengan kata lain, semua peringatan yang tersedia saat ini sekarang dianggap sebagai hutang teknis, yang dapat dikembalikan kemudian.
4. File yang dihasilkan dengan peringatan yang ditekan diletakkan di sistem kontrol versi. File ini besar, tetapi tidak menakutkan. Anda melakukan operasi ini satu kali (atau, setidaknya, Anda akan melakukannya sangat jarang). Dan sekarang file ini akan muncul di semua pengembang.
5. Sekarang semua pengembang melihat peringatan yang hanya berlaku untuk kode baru atau yang diubah. Mulai saat ini, tim mulai mendapat manfaat dari analisis statis. Secara bertahap mengatur analisa dan melakukan hutang teknis.

Omong-omong, sistem untuk menyimpan peringatan yang tidak menarik cukup pintar. Hash disimpan untuk string dengan potensi kesalahan, serta untuk yang sebelumnya dan berikutnya. Karena ini, jika sebuah baris ditambahkan ke awal salah satu file, maka tidak ada yang akan "menimbulkan korosi" dan penganalisa akan tetap diam pada kode yang dianggap sebagai tugas teknis.

Saya harap kami bisa menghilangkan salah satu prasangka mengenai 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 keseluruhan lebih dapat diandalkan dan berkualitas tinggi.

Catatan

Ketika mengembangkan proyek apa pun, kesalahan baru terus muncul dan diperbaiki. Kesalahan yang tidak terdeteksi "menetap" dalam kode untuk waktu yang lama, dan kemudian banyak dari mereka dapat dideteksi ketika menjalankan analisis kode statis. Karena itu, kadang-kadang ada perasaan salah bahwa analis statis hanya menemukan beberapa kesalahan yang tidak menarik di bagian kode yang jarang digunakan. Tentu saja, ini masalahnya jika Anda menggunakan analisa secara tidak benar dan menjalankannya hanya dari waktu ke waktu, misalnya, sesaat sebelum rilis rilis. Lebih lanjut tentang topik ini di sini . Ya, saat menulis artikel, kami sendiri melakukan satu kali pemeriksaan proyek terbuka. Tetapi kami memiliki tujuan yang berbeda. Kami ingin menunjukkan kemampuan penganalisa kode untuk mendeteksi cacat. Tugas ini tidak ada hubungannya dengan meningkatkan kualitas kode proyek secara keseluruhan dan mengurangi biaya yang terkait dengan koreksi kesalahan.

Tautan tambahan:

1. ROI PVS-Studio .
2. Analisis statis akan meningkatkan basis kode proyek C ++ yang kompleks .
3. Heisenbug 2019. Laporan oleh Ivan Ponomarev " Analisis Kode Statis Berkelanjutan ".
4. Ivan Ponomarev. Sematkan analisis statis ke dalam proses, bukan cari bug dengan itu .

Jika Anda ingin berbagi artikel ini dengan audiens yang berbahasa Inggris, silakan gunakan tautan ke terjemahan: Andrey Karpov. Menangani Keberatan: Analisis Statis Akan Menghabiskan Waktu Kerja .