Ada buku bagus yang saya baca tentang topik ini yang disebut Why Programs Fail , yang menguraikan berbagai strategi untuk menemukan bug mulai dari menerapkan metode ilmiah untuk mengisolasi dan menyelesaikan bug, hingga delta debugging. Bagian menarik lainnya dari buku ini adalah bahwa ia menghilangkan istilah 'bug'. Pendekatan Zeller adalah:
(1) Seorang programmer membuat cacat pada kode. (2) Cacat menyebabkan infeksi (3) Infeksi menjalar (4) Infeksi menyebabkan kegagalan.
Jika Anda ingin meningkatkan keterampilan debug Anda, saya sangat merekomendasikan buku ini.
Dalam pengalaman pribadi saya, saya telah menemukan banyak bug dalam aplikasi kami, tetapi manajemen cukup menekan kami untuk mengeluarkan fitur baru. Saya sering mendengar "Kami menemukan bug ini sendiri dan klien belum menyadarinya, jadi biarkan saja sampai mereka menemukannya". Saya pikir menjadi reaktif menentang proaktif dalam memperbaiki bug adalah ide yang sangat buruk karena ketika tiba saatnya untuk benar-benar memperbaiki, Anda memiliki masalah lain yang perlu diselesaikan dan lebih banyak fitur manajemen ingin keluar secepatnya, sehingga Anda ketahuan. dalam lingkaran setan yang dapat menyebabkan banyak stres dan terbakar dan akhirnya, sistem cacat ditunggangi.
Komunikasi juga merupakan faktor lain ketika bug ditemukan. Mengirimkan email atau mendokumentasikannya di pelacak bug semuanya baik-baik saja, tetapi menurut pengalaman saya sendiri, pengembang lain menemukan bug yang sama dan alih-alih menggunakan kembali solusi yang Anda buat untuk memperbaiki kode (karena mereka sudah lupa semua tentangnya ), mereka menambahkan versi mereka sendiri, jadi Anda punya 5 solusi berbeda dalam kode Anda dan hasilnya terlihat lebih membengkak dan membingungkan. Jadi, ketika Anda memperbaiki bug, pastikan beberapa orang meninjau perbaikan dan memberi Anda umpan balik seandainya mereka telah memperbaiki sesuatu yang serupa dan menemukan strategi yang baik untuk mengatasinya.
Limist menyebut buku itu, The Pragmatic Programmer yang memiliki beberapa materi menarik tentang cara memperbaiki bug. Dengan menggunakan contoh yang saya berikan pada paragraf sebelumnya, saya akan melihat ini: Entropi Perangkat Lunak , di mana analogi janda rusak digunakan. Jika dua jendela yang pecah muncul, tim Anda mungkin menjadi apatis untuk memperbaikinya, kecuali jika Anda bersikap proaktif.