Sangat mudah untuk mencoba penganalisis kode statis. Namun untuk melaksanakannya, terutama pada pengembangan proyek besar yang lama, membutuhkan keterampilan. Jika dilakukan secara tidak benar, penganalisis dapat menambah pekerjaan, memperlambat pengembangan, dan menurunkan motivasi tim. Mari kita bahas secara singkat tentang cara melakukan pendekatan yang tepat terhadap integrasi analisis statis ke dalam proses pengembangan dan mulai menggunakannya sebagai bagian dari CI/CD.
pengenalan
Baru-baru ini perhatian saya tertuju pada publikasi "". Di satu sisi, ini adalah artikel bagus yang patut untuk dibaca. Di sisi lain, menurut saya artikel ini masih belum memberikan jawaban lengkap tentang bagaimana menerapkan analisis statis tanpa rasa sakit dalam sebuah proyek dengan banyak dari kode warisan Artikel tersebut mengatakan bahwa Anda dapat menerima utang teknis dan hanya mengerjakan kode baru, tetapi tidak ada jawaban tentang apa yang harus dilakukan dengan utang teknis ini nanti.
Tim PVS-Studio kami menawarkan pandangannya mengenai topik ini. Mari kita lihat bagaimana masalah penerapan penganalisis kode statis muncul, bagaimana mengatasi masalah ini, dan bagaimana menghilangkan utang teknis secara bertahap tanpa rasa sakit.
Bermasalah
Biasanya tidak sulit untuk meluncurkan dan melihat cara kerja penganalisis statis []. Anda mungkin melihat kesalahan menarik atau bahkan potensi kerentanan yang menakutkan dalam kode. Anda bahkan dapat memperbaiki sesuatu, tetapi kemudian banyak pemrogram yang menyerah.
Semua penganalisis statis menghasilkan positif palsu. Ini adalah fitur metodologi analisis kode statis, dan tidak ada yang dapat dilakukan untuk mengatasinya. Dalam kasus umum, ini adalah masalah yang tidak dapat dipecahkan, sebagaimana ditegaskan oleh teorema Rice []. Algoritme pembelajaran mesin juga tidak akan membantu []. Sekalipun seseorang tidak selalu dapat mengetahui apakah kode ini atau itu salah, Anda tidak boleh mengharapkan ini dari program :).
Positif palsu tidak menjadi masalah jika penganalisis statis sudah dikonfigurasi:
- Menonaktifkan kumpulan aturan yang tidak relevan;
- Beberapa diagnostik yang tidak relevan telah dinonaktifkan;
- Jika kita berbicara tentang C atau C++, maka makro diberi markup yang berisi konstruksi spesifik yang menyebabkan munculnya peringatan tidak berguna di setiap tempat di mana makro tersebut digunakan;
- Fungsi sendiri ditandai yang melakukan tindakan yang mirip dengan fungsi sistem (analognya sendiri memcpy ΠΈΠ»ΠΈ Printf) [];
- Positif palsu secara khusus dinonaktifkan menggunakan komentar;
- Dan seterusnya.
Dalam hal ini, kita dapat mengharapkan tingkat positif palsu yang rendah, yaitu sekitar 10-15% []. Dengan kata lain, 9 dari 10 peringatan penganalisis akan menunjukkan masalah nyata dalam kode, atau setidaknya βkode berbau menyengatβ. Setuju, skenario ini sangat menyenangkan, dan penganalisa adalah teman sejati programmer.
Pada kenyataannya, dalam proyek besar, gambaran awalnya akan sangat berbeda. Penganalisis mengeluarkan ratusan atau ribuan peringatan untuk kode lama. Sulit untuk memahami dengan cepat peringatan mana yang relevan dan mana yang tidak. Tidak masuk akal untuk duduk dan mulai menangani semua peringatan ini, karena pekerjaan utama dalam kasus ini akan berhenti selama berhari-hari atau berminggu-minggu. Biasanya, sebuah tim tidak mampu menghadapi skenario seperti itu. Juga akan ada banyak perbedaan yang merusak sejarah perubahan. Dan pengeditan massal yang cepat terhadap begitu banyak fragmen kode pasti akan menghasilkan kesalahan ketik dan kesalahan baru.
Dan yang paling penting, upaya melawan peringatan seperti itu tidak masuk akal. Setuju bahwa karena proyek ini telah berjalan dengan sukses selama bertahun-tahun, sebagian besar kesalahan kritis di dalamnya telah diperbaiki. Ya, perbaikan ini sangat mahal, harus di-debug, menerima masukan negatif dari pengguna tentang bug, dan sebagainya. Penganalisis statis akan membantu memperbaiki banyak kesalahan ini pada tahap pengkodean, dengan cepat dan murah. Namun saat ini, dengan satu atau lain cara, kesalahan ini telah diperbaiki, dan penganalisis terutama mendeteksi kesalahan non-kritis dalam kode lama. Kode ini mungkin tidak digunakan, mungkin sangat jarang digunakan, dan kesalahan di dalamnya mungkin tidak menimbulkan konsekuensi yang nyata. Mungkin bayangan dari tombol memiliki warna yang salah, namun hal ini tidak mengganggu penggunaan produk oleh siapa pun.
Tentu saja, kesalahan kecil sekalipun tetaplah kesalahan. Dan terkadang kesalahan bisa menyembunyikan kerentanan yang nyata. Namun, menyerahkan segalanya dan menghabiskan waktu berhari-hari/berminggu-minggu menangani cacat yang hampir tidak terlihat tampak seperti ide yang meragukan.
Pemrogram melihat, melihat, melihat semua peringatan tentang kode kerja lama... Dan mereka berpikir: kita dapat melakukannya tanpa analisis statis. Mari kita menulis beberapa fungsi baru yang berguna.
Dalam pandangan mereka sendiri, mereka benar. Mereka berpikir bahwa pertama-tama mereka harus menghilangkan semua peringatan ini. Hanya dengan cara ini mereka dapat memperoleh manfaat dari penggunaan penganalisis kode secara rutin. Jika tidak, peringatan baru akan tenggelam dalam peringatan lama, dan tidak ada yang akan memperhatikannya.
Ini adalah analogi yang sama dengan peringatan kompiler. Bukan tanpa alasan mereka menyarankan agar jumlah peringatan compiler tetap 0. Jika ada 1000 peringatan, maka ketika ada 1001, tidak ada yang akan memperhatikannya, dan tidak jelas di mana mencari peringatan terbaru ini.
Hal terburuk dalam cerita ini adalah jika seseorang dari atas saat ini memaksa Anda untuk menggunakan analisis kode statis. Hal ini hanya akan menurunkan motivasi tim, karena dari sudut pandang mereka akan ada tambahan kerumitan birokrasi yang hanya akan menghambat. Tidak ada yang akan melihat laporan penganalisis, dan semua penggunaan hanya akan dilakukan βdi atas kertasβ. Itu. Secara formal, analisis dimasukkan ke dalam proses DevOps, namun dalam praktiknya hal ini tidak menguntungkan siapa pun. Kami mendengar cerita rinci di stan dari peserta konferensi. Pengalaman seperti itu dapat membuat pemrogram enggan menggunakan alat analisis statis untuk waktu yang lama, atau bahkan selamanya.
Menerapkan dan menghilangkan utang teknis
Faktanya, tidak ada yang sulit atau menakutkan dalam memperkenalkan analisis statis bahkan ke dalam proyek lama yang besar.
CI / CD
Selain itu, penganalisis dapat segera dijadikan bagian dari proses pengembangan berkelanjutan. Misalnya, distribusi PVS-Studio berisi utilitas untuk memudahkan melihat laporan dalam format yang Anda perlukan, dan pemberitahuan kepada pengembang yang menulis bagian kode yang bermasalah. Bagi mereka yang lebih tertarik untuk meluncurkan PVS-Studio dari sistem CI/CD, saya sarankan Anda membiasakan diri dengan yang sesuai dokumentasi dan serangkaian artikel:
Namun mari kita kembali ke masalah banyaknya kesalahan positif pada tahap pertama penerapan alat analisis kode.
Memperbaiki utang teknis yang ada dan menangani peringatan baru
Penganalisis statis komersial modern memungkinkan Anda mempelajari hanya peringatan baru yang muncul dalam kode baru atau yang diubah. Penerapan mekanisme ini berbeda-beda, namun esensinya sama. Dalam penganalisis statis PVS-Studio, fungsi ini diimplementasikan sebagai berikut.
Untuk mulai menggunakan analisis statis dengan cepat, kami menyarankan pengguna PVS-Studio menggunakan mekanisme untuk menekan peringatan secara massal []. Ide umumnya adalah sebagai berikut. Pengguna meluncurkan penganalisis dan menerima banyak peringatan. Karena proyek yang telah dikembangkan selama bertahun-tahun masih hidup, berkembang, dan menghasilkan uang, kemungkinan besar tidak akan ada banyak peringatan dalam laporan yang menunjukkan cacat kritis. Dengan kata lain, bug kritis telah diperbaiki dengan cara apa pun menggunakan metode yang lebih mahal atau berkat umpan balik dari pelanggan. Oleh karena itu, segala sesuatu yang saat ini ditemukan oleh penganalisis dapat dianggap sebagai hutang teknis, yang tidak praktis untuk segera dihilangkan.
Anda dapat memberitahu PVS-Studio untuk menganggap peringatan ini tidak relevan untuk saat ini (simpan hutang teknis untuk nanti), dan peringatan tersebut tidak akan ditampilkan lagi. Penganalisis membuat file khusus yang menyimpan informasi tentang kesalahan yang belum menarik. Dan sekarang PVS-Studio akan mengeluarkan peringatan hanya untuk kode baru atau yang diubah. Apalagi semua ini dilaksanakan dengan cerdik. Jika, misalnya, baris kosong ditambahkan ke awal file kode sumber, maka penganalisis memahami bahwa sebenarnya tidak ada yang berubah, dan akan terus diam. File markup ini dapat dimasukkan ke dalam sistem kontrol versi. Filenya besar, tapi ini tidak menjadi masalah, karena tidak ada gunanya sering menyimpannya.
Sekarang semua pemrogram akan melihat peringatan hanya terkait dengan kode baru atau kode yang diubah. Dengan demikian, Anda dapat mulai menggunakan penganalisis, seperti yang mereka katakan, mulai hari berikutnya. Dan Anda dapat kembali ke hutang teknis nanti, dan secara bertahap memperbaiki kesalahan dan mengkonfigurasi penganalisis.
Jadi, masalah pertama dengan implementasi penganalisis dalam proyek besar yang lama telah terpecahkan. Sekarang mari kita cari tahu apa yang harus dilakukan dengan utang teknis.
Perbaikan bug dan pemfaktoran ulang
Hal paling sederhana dan paling alami adalah meluangkan waktu untuk menganalisis peringatan penganalisis yang disembunyikan secara besar-besaran dan menanganinya secara bertahap. Di suatu tempat Anda harus memperbaiki kesalahan dalam kode, di suatu tempat Anda harus melakukan refaktorisasi untuk memberi tahu penganalisis bahwa kode tersebut tidak bermasalah. Contoh sederhana:
if (a = b)Kebanyakan kompiler dan penganalisis C++ mengeluh tentang kode tersebut, karena kemungkinan besar mereka benar-benar ingin menulis (sebuah == b). Namun ada kesepakatan yang tidak terucapkan, dan hal ini biasanya dicatat dalam dokumentasi, bahwa jika ada tambahan tanda kurung, maka dianggap programmer sengaja menulis kode tersebut, dan tidak perlu bersumpah. Misalnya, dalam dokumentasi PVS-Studio untuk diagnostik tertulis dengan jelas bahwa baris berikut akan dianggap benar dan aman:
if ((a = b))Contoh lain. Apakah ada yang terlupakan dalam kode C++ ini? istirahat atau tidak?
case A:
foo();
case B:
bar();
break;Penganalisis PVS-Studio akan mengeluarkan peringatan di sini . Ini mungkin bukan kesalahan, dalam hal ini Anda harus memberikan petunjuk kepada parser dengan menambahkan atribut atau misalnya __atribut__((kegagalan)):
case A:
foo();
[[fallthrough]];
case B:
bar();
break;Dapat dikatakan bahwa perubahan kode seperti itu tidak memperbaiki bug. Ya, ini benar, tapi ada dua manfaatnya. Pertama, laporan penganalisis menghilangkan positif palsu. Kedua, kode tersebut menjadi lebih mudah dipahami oleh orang-orang yang terlibat dalam pemeliharaannya. Dan ini sangat penting! Untuk hal ini saja, ada baiknya melakukan pemfaktoran ulang kecil untuk membuat kode lebih jelas dan mudah dipelihara. Karena penganalisis tidak memahami apakah "break" diperlukan atau tidak, hal ini juga tidak jelas bagi sesama pemrogram.
Selain perbaikan bug dan pemfaktoran ulang, Anda dapat secara khusus menyembunyikan peringatan penganalisis yang jelas-jelas salah. Beberapa diagnostik yang tidak relevan dapat dinonaktifkan. Misalnya, seseorang menganggap peringatan tidak ada gunanya tentang membandingkan nilai float/double. Dan ada pula yang mengklasifikasikannya sebagai penting dan layak dipelajari []. Peringatan mana yang dianggap relevan dan mana yang tidak, terserah pada tim pengembangan untuk memutuskan.
Ada cara lain untuk menekan peringatan palsu. Misalnya, markup makro telah disebutkan sebelumnya. Semua ini dijelaskan secara lebih rinci dalam dokumentasi. Hal yang paling penting adalah memahami bahwa jika Anda secara bertahap dan sistematis mendekati penanganan positif palsu, tidak ada yang salah dengan hal tersebut. Sebagian besar peringatan yang tidak menarik hilang setelah konfigurasi, dan hanya tempat yang benar-benar memerlukan studi cermat dan beberapa perubahan kode yang tersisa.
Selain itu, kami selalu membantu klien kami menyiapkan PVS-Studio jika ada kesulitan. Selain itu, ada kalanya kami sendiri menghilangkan peringatan palsu dan memperbaiki kesalahan []. Untuk berjaga-jaga, saya memutuskan untuk menyebutkan bahwa opsi untuk kerjasama yang lebih luas juga dimungkinkan :).
Metode roda gigi
Ada pendekatan lain yang menarik untuk meningkatkan kualitas kode secara bertahap dengan menghilangkan peringatan penganalisis statis. Intinya adalah jumlah peringatan hanya bisa berkurang.
Jumlah peringatan yang dikeluarkan oleh penganalisis statis dicatat. Gerbang kualitas dikonfigurasi sedemikian rupa sehingga sekarang Anda hanya dapat memasukkan kode yang tidak menambah jumlah operasi. Hasilnya, proses pengurangan jumlah alarm secara bertahap dimulai dengan penyesuaian alat analisa dan koreksi kesalahan.
Bahkan jika seseorang ingin sedikit curang dan memutuskan untuk melewati gerbang kualitas bukan dengan menghilangkan peringatan di kode barunya, tetapi dengan memperbaiki kode pihak ketiga yang lama, ini tidak menakutkan. Meski begitu, ratchet berputar ke satu arah, dan secara bertahap jumlah cacat akan berkurang. Sekalipun seseorang tidak ingin memperbaiki kekurangan barunya, dia masih harus memperbaiki sesuatu pada kode tetangganya. Pada titik tertentu, cara mudah untuk mengurangi jumlah peringatan akan berakhir, dan ada saatnya bug yang sebenarnya akan diperbaiki.
Metodologi ini dijelaskan lebih rinci dalam artikel yang sangat menarik oleh Ivan Ponomarev "", yang saya rekomendasikan untuk dibaca oleh siapa saja yang tertarik untuk meningkatkan kualitas kode.
Penulis artikel juga memiliki laporan tentang topik ini: "".
Kesimpulan
Saya berharap setelah artikel ini, pembaca akan lebih menerima alat analisis statis dan ingin menerapkannya ke dalam proses pengembangan. Jika Anda memiliki pertanyaan, kami selalu siap pengguna penganalisa statis PVS-Studio kami dan membantu implementasinya.
Ada keraguan umum lainnya tentang apakah analisis statis benar-benar nyaman dan berguna. Saya mencoba menghilangkan sebagian besar keraguan ini dalam publikasi βAlasan memperkenalkan penganalisis kode statis PVS-Studio ke dalam proses pengembanganβ [].
Terima kasih atas perhatiannya dan datanglah dan coba penganalisa PVS-Studio.
Tautan tambahan
- Andrey Karpov.
- Wikipedia. .
- Andrey Karpov, Victoria Khanieva. .
- PVS-Studio. Dokumentasi. .
- Andrey Karpov. .
- PVS-Studio. Dokumentasi. .
- Ivan Andryashin. .
- Pavel Eremeev, Svyatoslav Razmyslov. .
- Andrey Karpov. .
Jika Anda ingin membagikan artikel ini kepada audiens berbahasa Inggris, silakan gunakan tautan terjemahan: Andrey Karpov. .
Sumber: www.habr.com