Pengelompokan bug dalam kode sumber

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?

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.

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.

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.

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".