Pengelompokan bug dalam kode sumber


8

Ada banyak klaim tentang adanya kelompok bug atau cacat. Pencarian sederhana mengungkapkan banyak hasil, misalnya: 1 , 2 , 3 , 4 , 5 .

Namun, semua bukti yang dikutip adalah anekdotal dan saya tidak dapat menemukan data konkret untuk mendukungnya. Sementara pengalaman saya sendiri tidak bertentangan dengan klaim ini, orang suka melihat pola bahkan ketika tidak ada (bahkan distribusi bug yang seragam akan menghasilkan cluster, dan mungkin lebih mudah diingat ketika Anda harus memperbaiki 10 bug di satu tempat daripada 10 hal-hal yang tidak berhubungan di seluruh basis kode).

Saya benar-benar ingin tahu apakah fenomena ini memang ada, tetapi saya tidak dapat menemukan sumber objektif atau semi-objektif (seperti dalam tes, eksperimen, studi, dll.) Yang akan menunjukkan bahwa pengelompokan cacat benar-benar terjadi.

Tentu saja, saya baik-baik saja dengan mengasumsikan hipotesis pengelompokan bug sebagai praktik yang baik (bahkan jika itu salah, itu tidak akan terlalu menyakitkan). Di sisi lain, data konkret bisa menjelaskan mengapa itu terjadi. Apakah karena hari-hari itu orang sakit kepala parah (untuk alasan apa pun)? Atau mungkin karena beberapa bagian dari kode itu keras dan yang lainnya mudah? Atau mungkin itu adalah tempat tanggung jawab kedua insinyur yang tidak saling menyukai?

Pertanyaan saya: Apakah efek clustering cacat memang ada? Apakah ada data konkret non-anekdot yang paling baik dijelaskan oleh hipotesis ini?


Alasannya adalah karena satu bug dapat membiakkan bug lainnya, ini terjadi karena kode saling terkait, jadi sementara tester merasa senang menemukan banyak bug kadang-kadang mereka tidak tahu bahwa programmer hanya perlu memperbaiki satu bug dan poof semua bug lainnya hilang.
kirie

Saya akan setuju dengan @ padang di sini, bahwa bug dalam satu fungsi biasanya memiliki efek kaskade pada fungsionalitas lainnya. Penguji mungkin berpikir mereka adalah bug yang berbeda, tetapi mereka benar-benar bersumber dari satu masalah. Selain itu, manusia dirancang dengan baik untuk menemukan pola, itulah sebabnya kami melakukannya dalam segala hal.
Marshall Tigerus

Sangat jarang saya memiliki bug yang dapat menimpa sedikit informasi acak, di mana saja. Dengan bug semacam itu dalam kode sumber, perangkat lunak dapat berperilaku tidak pantas dengan cara yang mungkin ada.
gnasher729

2
Saya pikir ini adalah pertanyaan yang valid dan tidak ingin melihatnya ditutup, karena OP secara spesifik meminta "data konkret non-anekdotal". Namun, jawaban yang diberikan sejauh ini tidak memberikan ini. Saya lebih suka melihatnya terlindungi dan jawaban tanpa tautan ke riset turun memberi suara.
mattnz

@ gnasher729 Saya tidak tahu apa yang menimpa sedikit informasi yang Anda sebutkan, tetapi ini umum ketika Anda menggunakan prinsip KERING pada tahap awal ketika banyak fungsi belum sepenuhnya diuji namun sudah digunakan berkali-kali.
kirie

Jawaban:


3

Saya tidak memiliki data apa pun, tetapi saya cukup yakin hipotesis pengelompokan itu benar. Tebakan terbaik saya adalah dua kasus ini terjadi lebih sering atau lebih jarang:

  • sepotong kode atau algoritma itu kompleks (mungkin implementasinya lebih kompleks daripada yang diperlukan) dan programmer asli tidak sepenuhnya memahami apa yang mungkin dilakukan kodenya karena kompleksitasnya.

  • kode tidak diuji dengan baik

Dan - tentu saja - kombinasi keduanya. Pengujian sulit, tetapi pengujian kode kompleks jauh lebih sulit dengan urutan besarnya. Dan dengan meningkatnya kompleksitas, terutama ketika kode tidak diuji dengan baik, dalam pengalaman saya, jumlah bug potensial dalam sepotong kode meningkat secara tidak proporsional.

Jadi, jika Anda menemukan beberapa bug di bagian kode tertentu, kemungkinan besar kode yang diuji sangat kompleks, yang memberi Anda peluang besar untuk menemukan lebih banyak bug di area yang sama.


2

Studi formal seperti ini jarang ada dalam pengembangan perangkat lunak, mungkin karena pemrograman (terlepas dari hubungannya dengan mesin) terutama merupakan upaya manusia, bukan mesin.

Kemarin saya memperbaiki bug dalam pernyataan SQL yang melibatkan dua pernyataan SELECT dan UNION. Kedua SELECT mengembalikan hasil yang sama karena kesalahan sederhana dalam GABUNG. Memperbaiki masalah, namun, menemukan bug lain yang sedang ditutup oleh bug pertama.


2

Dalam pengalaman saya:

Clustering terjadi ketika pekerjaan terganggu. Katakanlah seseorang dipindahkan dari proyek sehingga pekerjaannya tidak sepenuhnya diuji, atau bahkan mungkin selesai, dan / atau hasilnya tidak sepenuhnya dipahami.

Clustering juga terjadi karena masalah "programmer buruk". Katakanlah 5 orang mengerjakan sesuatu dan salah satunya di bawah standar. Bug akan dikaitkan dengan karyanya.

Prinsip Pareto berlaku (alias aturan 80/20). Sekitar 80% efek berasal dari 20% penyebabnya. https://en.wikipedia.org/wiki/Pareto_principle Perhatikan observasi ini berasal dari sebelum komputer.


0

Tidak ada paradoks dalam pengelompokan bug. Dan bias kognitif kita mengipasi api di sekitar.

Menurut distribusi normal pada waktu tertentu, beberapa bagian basis kode secara signifikan lebih buggy daripada yang lain. Setiap bug baru lebih mungkin ditemukan di bagian kereta.
Jadi orang yang akan Anda perbaiki sudah dikutuk dengan peluang bagus untuk memiliki perusahaan.

Itu sama dengan "kemalangan tidak pernah datang sendiri-sendiri".


1
Saya tidak yakin distribusi normal memungkinkan kami membuat kesimpulan seperti yang Anda sarankan. Saya berasumsi kita sedang menganalisis kepadatan cacat per unit kode. Untuk setiap distribusi probabilitas non-seragam, kita dapat melihat bahwa beberapa unit akan lebih kereta daripada yang lain. Untuk distribusi simetris seperti distribusi normal, tepat setengah dari semua modul akan memiliki kepadatan cacat di atas rata-rata! Tentu saja, itu adalah konsekuensi dari asumsi risiko bug yang konstan di semua unit — tetapi bukankah itu kebalikan dari pertanyaan ini, bahwa bug menghasilkan lebih banyak bug? Mungkin saya salah paham jawaban ini.
amon

"tepat setengah dari ..." ya, tetapi tidak memiliki nilai dalam konteks saat ini. Maaf, saya tidak mengerti Anda Amon. Saya tidak setuju dengan frasa persis "bug menghasilkan lebih banyak bug". Maksud saya adalah bug yang ditemukan adalah [dengan kemungkinan kita tidak bisa mengabaikannya] yang ditakdirkan untuk menjadi salah satu di antara yang lainnya.
Vlad
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.