Kiat untuk debugging dengan sedikit info? [Tutup]

Saya telah mewarisi proyek dengan basis kode yang cukup besar, dan pengembang asli jarang, jika pernah, membalas email. Ada banyak cara berbeda untuk melakukan beberapa hal di dalamnya, dan saya tidak tahu semuanya. Banyak kode duplikat di sepanjang jalur ini (daripada fungsi yang disertakan oleh, katakanlah, 5 halaman yang melakukan hal yang relatif sama, kode itu disalin di 5 halaman), dan beberapa masalah halus dalam database (kita semua pernah mendengar kode spaghetti , tetapi apakah Anda pernah mendengar tentang database spaghetti?)

Semua ini saya dapat menangani sebagian besar waktu tanpa masalah.

Masalahnya adalah ketika klien menemukan bug di suatu tempat. Mereka biasanya akan mengirim tangkapan layar masalah yang berakhir, dan berkata, "Bisakah Anda melihat ini?" sambil menyoroti hal tertentu pada halaman yang salah, dan kadang-kadang apa yang diharapkan. Sangat sedikit informasi yang diberikan, dan mencoba berbicara dengan mereka dan mendapatkan lebih banyak (seperti apa yang mereka lakukan untuk mendapatkan hasilnya) seperti mencabut gigi.

Pada dasarnya, intinya adalah:

• Basis kode besar dan kompleks yang tidak saya kenal 100%
• Banyak hal bisa salah
• Sangat sedikit informasi tentang bagaimana bug muncul

Adakah yang punya tips, trik, saran, dll. Tentang cara men-debug hal semacam ini?

Ketika saya mendapatkan sesuatu seperti itu, saya biasanya meminta lebih banyak informasi. Tidak yakin bagaimana tempat Anda bekerja, tetapi di sini jika saya tidak memiliki informasi yang cukup untuk mereproduksi masalah secara lokal, saya dapat mengirim tiket kembali bertanda Can't Reproduce, dengan permintaan untuk informasi lebih lanjut, dan mereka tahu bahwa tidak ada yang diperbaiki sampai Saya bisa mematahkannya pada saya.

Jika klien Anda mengalami kesulitan dengan menjelaskan langkah-langkah, minta mereka untuk video screencap. Ada beberapa produk gratis yang dapat membuatnya, seperti Jing. Itu membuatnya jauh lebih mudah ketika Anda bisa menonton apa yang mereka lakukan.

EDIT: Jing adalah ide yang bagus ketika saya menulis ini beberapa tahun yang lalu. Sejak itu, mereka telah memodifikasi pemasang mereka untuk memuat sistem Anda dengan crapware "bonus" yang tidak pernah Anda minta, jadi saya tidak bisa lagi merekomendasikannya. Ada banyak perekam layar yang layak di sekitar.

Awal yang baik mungkin buku ini .

Saya menggunakan definisi di bawah ini karena sepertinya pengembang tidak ada untuk mendukungnya lagi.

Kode lama adalah kode sumber yang terkait dengan yang tidak lagi didukung.

Saya memiliki masalah yang sama beberapa tahun yang lalu dan dorongan terbesar untuk produktivitas dan pembersihan kode adalah mengintegrasikan pelacakan bug ke dalam sistem.

Kami menggunakan Fogbugz (saya berasumsi mereka masih melakukan Fogcreek!) Dan kami dapat membangun mekanisme penanganan pengecualian di mana pengguna dapat menekan tombol setiap kali pengecualian dinaikkan dan itu akan segera masuk ke sistem kami - tidak ada lagi panggilan dan tidak ada lagi tangkapan layar. Dengan opsi ini, Anda mengambil informasi yang Anda butuhkan alih-alih mencoba mengekstraknya dari pengguna. Kedengarannya seperti varian akan ada gunanya bagi Anda, terutama dengan opsi tangkapan layar.

Hal lain yang ingin Anda mulai lakukan adalah mulai menambahkan pencatatan. Anda mungkin ingin melangkah sejauh mencatat setiap pemanggilan metode dengan nilai argumen. Karena sepertinya Anda bekerja dengan kode lawas (kode tanpa tes), pencatatan ini akan membantu Anda menambahkan tes unit yang sesuai sehingga Anda tidak mengulangi masalah apa pun.

Saran saya yang paling sungguh-sungguh adalah mulai refactoring di mana Anda bisa. Saya tidak dapat menghitung berapa kali saya melihat salinan fungsionalitas hanya untuk mengetahui bahwa itu bukan 100% salinan lengkap. Itu 99,9% salinan dan 1 kesalahan kecil, kecil yang mengakibatkan bug. Mulailah menambahkan tes unit ke semuanya dan jika Anda memiliki departemen QA, cobalah untuk membuat beberapa skrip pengujian otomatis untuk bagian-bagian dari kode yang Anda kerjakan.

Di sisi lain, lihat berapa banyak logging yang dapat disuntikkan ke dalam kode. Yaitu, jika tidak memiliki banyak cara login Anda dapat menambahkan bendera ke kode untuk mulai mengambil lebih banyak logging verbose untuk keperluan debugging Anda sendiri. Ini adalah sesuatu yang Anda dapat mengaktifkan dan mematikan pengguna jika Anda bisa menjalankan dialog. Ini membantu saya lebih banyak daripada yang bisa saya hitung. Saya biasanya mendapatkan "itu tidak berhasil" tanpa gambaran masalah. Saya hanya mengatakan "kirimi saya file log."

Mulailah dengan menulis tes unit. Pilih kelas atau fungsi dan tulis satu set tes yang sesuai dengan bagaimana Anda pikir itu harus bekerja. Jika tes gagal, cari tahu alasannya. Jika itu bug - perbaiki. Jika harapan Anda ternyata salah, cari tahu apa yang sebenarnya dilakukan dan modifikasi tes yang sesuai.

Setelah Anda memiliki serangkaian tes unit kerja yang layak, Anda memiliki jaring pengaman untuk melakukan beberapa refactoring untuk membuat kode lebih bersih.

Terus iterasi sampai Anda memahami basis kode.

Tak perlu dikatakan, ini adalah sesuatu yang harus Anda lakukan sebelumnya, bukan sebagai respons terhadap laporan bug.