Cara meningkatkan kemampuan Anda untuk men-debug kode yang ada [ditutup]
29
Tugas umum di dunia kerja adalah berurusan dengan kode yang ada, tetapi bermasalah. Apa saja kiat untuk meningkatkan keterampilan Anda sebagai debugger?
Sering tergoda untuk hanya mengatakan "oh, saya tahu apa yang dilakukan kode ini, tidak apa-apa". Jangan lakukan itu. Uji setiap asumsi dan melangkahi segala sesuatu dengan cermat.
+1. Benar. Bersiaplah untuk kagum dengan bagaimana beberapa hal, Anda pikir Anda tahu, akan mempermainkan Anda.
aufather
bekerja untuk saya :)
setzamora
3
Men-debug kode orang lain adalah pemborosan waktu yang sangat besar, pembunuh produktivitas, tetapi begitulah adanya. Satu-satunya saat ketika benar-benar masuk akal untuk memperbaiki bug orang lain adalah ketika mereka telah pergi. Apa yang saya BENCI BENCI BENCI sedang mengalami beberapa kode jelek secara obyektif oleh seorang programmer senior, kemudian harus mengajukan pertanyaan untuk membuat kemajuan tepat waktu, dan mendapatkan kuliah tentang peningkatan keterampilan saya dalam mempelajari basis kode yang ada. Tidak seperti mempelajari sifat ibu, memecahkan masalah yang disebabkan oleh manusia tidak menyenangkan. Setidaknya saya mendapatkan jawaban saya. Situasi sebaliknya tidak akan terjadi, karena saya hanya lebih baik dan meninggalkan lebih sedikit bug.
Ayub
1
@ Pekerjaan: ... oke? Apakah Anda bermaksud meninggalkan komentar ini di pos, mungkin? :)
Adam Lear
Ini! Adalah konyol untuk secara buta mempercayai sedikit pun kode Anda jika Anda men-debug masalah aneh dan kode itu tampak baik-baik saja.
Dan
7
Pengujian secara bertahap .
Masuk lebih dulu ke dalam kode Anda dan ujilah dari modul terkecil yang naik secara bertahap. Dengan cara ini, Anda tidak terlalu stres ketika mencoba mencari tahu di mana masalahnya sebenarnya.
Ini juga berarti bahwa itu mempengaruhi kode lebih sedikit pada satu waktu karena Anda bergerak secara bertahap..sekali saya memiliki masalah di mana saya memperbaiki sesuatu dan yang menyebabkan banyak hal lainnya rusak. Saya memberikan pujian kepada bos saya untuk ini karena dia mengajari saya ini ketika saya bermain-main.
Membagi dan menaklukkan adalah pendekatan yang baik. Cobalah untuk mengidentifikasi beberapa input yang terlihat (input pengguna / peristiwa jaringan ...) dan output (log, output ke pengguna, pesan jaringan keluar ...) di antara masalah yang ada. Coba letakkan cetakan pada potongan yang cukup besar atau titik-titik penting di antara mereka dan cobalah untuk mempersempit di mana bug berada dalam kode.
Membagi dan menaklukkan juga dapat bekerja dengan sangat baik jika terjadi regresi atas kode yang dikendalikan versi. Temukan dua build - satu di mana ia bekerja seperti yang diharapkan, yang lain dengan regresi. Persempit celah sampai Anda dibiarkan dengan sekelompok checkin sebagai tersangka potensial.
Daripada memotong bug biner, tulis tes dalam formulir
Diberikan ...
Kapan...
Mengharapkan...
Untuk memverifikasi apa yang sebenarnya Anda ketahui benar tentang fungsi aplikasi versus apa yang Anda anggap benar.
Sebagian besar IDE memudahkan untuk mengekstrak metode dan menghasilkan potongan pengujian xUnit. Manfaatkan itu.
Mengapa tidak menaburkan debugs? Karena setelah Anda selesai, Anda mungkin harus membatalkan sebagian besar pekerjaan itu dan menghapus sejumlah besar debug tersebut. Saat Anda menulis tes, debugging Anda akan membantu dalam pencegahan dan deteksi bug di masa depan.
Debugging sepenuhnya dalam seni itu sendiri, terutama debugging kode orang lain.
Gratzy
2
Seperti orang lain katakan - jangan menganggap apa pun. Ini terutama benar jika kodenya sudah Anda tulis. Saat men-debug kode orang lain, Anda cenderung memperlambat karena kode itu baru bagi Anda atau Anda tidak mempercayai pembuat kode. Ketika men-debug kode Anda sendiri terlalu mudah untuk menganggap Anda menulisnya dengan benar, memperlambat!
Untuk proses debugging aktual:
Tulis tes unit jika belum ada.
Tambahkan pencatatan yang sesuai jika belum ada.
Kemudian gunakan debugging.
Menambahkan unit test dan logging terlebih dahulu lebih efisien daripada menggunakan debugger terlebih dahulu. Anda juga mendapatkan keuntungan tambahan dari memiliki unit test untuk membantu tidak memperkenalkan bug di masa depan dan pencatatan akan membantu sesi debugging di masa depan.
Sebelum melangkah lebih dari satu potongan kecil kode, lihat apakah Anda dapat menentukan hasilnya secara akurat. Ini memang cenderung terbang dalam menghadapi jangan menganggap apa-apa (yang saya pilih BTW) tetapi ketika Anda mendapatkan pengalaman, itu dapat membantu mempersempit ke mana harus mencari.
Ini mungkin terdengar sepele, tetapi pelajari nuansa debugger Anda dan pelajari tombol pintasnya. Terkadang debugger bisa cukup lambat sehingga pikiran Anda bertanya-tanya ketika Anda melangkah. Jika Anda bisa mengimbangi mesin dan tidak berkeliaran, itu bisa membantu.
Jika Anda dapat mengubah kode saat debug:
pertimbangkan untuk menyatakan sebelum dan sesudah kondisi. Kadang-kadang Anda kemudian dapat melangkah, alih-alih ke dalam kode.
karena jika pernyataan dengan ekspresi yang rumit, pertimbangkan sesuatu (beberapa mungkin mengernyit tetapi ini bekerja untuk saya)
seperti:
bool isLessThan5 = a < 5;
bool isGreaterThan10 = a > 10;
if ( isLessThan5 || isGreaterThan10 )
{
// more code here
}
dari pada:
if ( a < 5 || a > 10 )
{
// more code here
}
Untuk kasus Anda tidak dapat men-debug semuanya, untuk alasan apa pun, belajar untuk "bebek karet" dengan rekan kerja. Kadang-kadang tindakan menjelaskan menjelaskan. (ok, mungkin ini tidak persis dalam tema pertanyaan, tapi saya pikir itu cukup dekat untuk menjamin disebutkan)
Penamaan subkondisi membutuhkan langkah lebih lanjut, yaitu refactoring nama ketika Anda mencari tahu untuk apa kondisinya. Mungkin ternyata if (tooCloseToHydrant || overTheBrink) { ketika Anda belajar lebih banyak nanti.
1
Dua hal, berdasarkan menghabiskan sebagian besar 22 tahun terakhir mempertahankan kode orang lain menulis.
Pahami jenis bug yang cenderung Anda tulis.
Sebagai contoh, saya seorang pembuat kode yang sangat teliti, jadi setelah kode saya dikompilasi, biasanya bebas dari bug sepele. Jadi bug saya cenderung menjadi hal rumit yang aneh seperti kebuntuan thread. Di sisi lain, saya punya teman yang kebanyakan menulis bug sepele - titik koma di akhir C ++ untuk loop, jadi baris berikutnya hanya dieksekusi sekali, hal semacam itu.
Jangan berasumsi orang lain menulis jenis bug yang sama dengan yang Anda lakukan.
Saya tidak tahu berapa kali saya membuang waktu untuk mengeluarkan senjata debugging besar, dengan asumsi bug adalah jenis hal aneh yang sangat halus, hanya untuk membuat teman saya melihat ke belakang dan berkata, "Apakah Anda memperhatikan bahwa ekstra titik koma?" Setelah bertahun-tahun, saya pertama-tama mencari buah yang sepele dan tergantung rendah ketika melihat kode orang lain.
Apakah Anda memformat ulang kode untuk melihat apakah ada yang bergerak?
@ Thorbjørn: Jika saya telah mengambil kepemilikan kode, saya terkadang melakukannya untuk meningkatkan keterbacaan, tetapi tidak untuk menemukan kesalahan ketik. Ide yang menarik!
Bob Murphy
Anda tidak harus melakukan itu, lihat saja apa yang terjadi. Saya sangat merekomendasikan penegakan kebijakan yang memerlukan kode untuk diformat ulang - lebih disukai secara otomatis - saat check in.
@ Thorbjørn: Saya ingin melakukannya. Apa yang Anda rekomendasikan sebagai kode "prettifier"? Saya kebanyakan bekerja di Linux dan Mac.
Bob Murphy
Saya menggunakan Eclipse yang tersedia di kedua tempat, dan editor Java memiliki tindakan Simpan yang disebut di mana Anda dapat menentukan apa yang harus terjadi setiap kali file disimpan. Di sini salah satu opsi adalah memformat sumber. Kami adalah tim kecil jadi saya belum menyelidiki lebih lanjut di dalamnya. Tim yang lebih berpengalaman memungkinkan kait pra-komit dalam sistem kontrol sumber, memungkinkan komitmen sumber ditolak jika tidak diformat dengan benar. Sangat efisien.
1
Ketahui alat Anda. Sebagai contoh, debugger Visual Studio memiliki fitur luar biasa yang disebut TracePoints yang seperti breakpoints tetapi bukannya menghentikan kode Anda, bukannya menyisipkan pernyataan jejak ke dalam output debug.
Sangat disarankan untuk membaca buku atau mengikuti kelas tentang cara menggunakan debugger Anda. Saya mengambil beberapa kelas dan membaca beberapa buku oleh John Robbins yang membuat perbedaan besar dalam efektivitas saya sebagai debugger.
Memahami secara fungsional apa yang coba dilakukan oleh kode. Jika Anda tidak tahu gambaran lengkapnya (semua kasus uji yang harus dilewati kode ini) sulit untuk di-debug dengan benar tanpa memperkenalkan bug baru
Tulis uji unit otomatis dan tipe integrasi dan tes fungsional lainnya.
Semakin banyak tes otomatis yang Anda miliki, semakin sedikit waktu yang Anda perlukan untuk debugger.
Juga, desain yang bagus - Prinsip SOLID. Jika Anda menulis kelas kecil, fokus, dan lebih menyukai komposisi daripada pewarisan, menghilangkan duplikasi, dll., Maka kode Anda akan selalu lebih mudah untuk di-debug.
Saya menemukan bahwa kode yang dirancang dengan baik menghasilkan serangkaian bug yang berbeda dengan kode yang tidak dirancang dengan baik. Secara umum, kode yang dirancang dengan baik menghasilkan bug yang lebih mudah ditemukan, diperbanyak, dan diperbaiki.
Pengecualian (dan selalu ada satu) adalah kode multithreading :-)
Jika Anda mempersempitnya ke wilayah kecil, tetapi masih tidak dapat menemukan kesalahan, coba opsi 'lihat kode + rakitan' dari debugger Anda. Mengetahui cukup ASM untuk mengatakan "harus ada cabang di sini" atau "mengapa hanya menyalin kata rendah?" akan sering menunjukkan kesalahan pengkodean.
Lihatlah buku yang sangat berharga Why Programs Fail: A Guide to Debugging Sistematik , oleh Andreas Zeller. Ini akan memperkenalkan Anda pada banyak teknik, teori, dan alat, beberapa di antaranya berada di ujung tombak penelitian.
Slide untuk buku tersedia online, tetapi saya menemukan buku itu sendiri lebih mudah dibaca.
Buku ini akan membantu Anda memulai dan membuat Anda berpikir lebih ilmiah tentang debugging, tetapi itu bukan pengganti untuk latihan. Anda mungkin perlu menulis dan men-debug selama 10 tahun sebelum Anda melihat urutan peningkatan besar dalam kinerja Anda. Saya masih ingat memiliki rahang saya turun di Sun melihat pengembang senior, yang telah pemrograman untuk Unix selama 30 tahun, menemukan bug multithreading atau paralel paralel dalam hitungan menit. Pengalaman itu penting!
Jawaban:
Jangan Menganggap Apa Pun
Sering tergoda untuk hanya mengatakan "oh, saya tahu apa yang dilakukan kode ini, tidak apa-apa". Jangan lakukan itu. Uji setiap asumsi dan melangkahi segala sesuatu dengan cermat.
sumber
Pengujian secara bertahap .
Masuk lebih dulu ke dalam kode Anda dan ujilah dari modul terkecil yang naik secara bertahap. Dengan cara ini, Anda tidak terlalu stres ketika mencoba mencari tahu di mana masalahnya sebenarnya.
Ini juga berarti bahwa itu mempengaruhi kode lebih sedikit pada satu waktu karena Anda bergerak secara bertahap..sekali saya memiliki masalah di mana saya memperbaiki sesuatu dan yang menyebabkan banyak hal lainnya rusak. Saya memberikan pujian kepada bos saya untuk ini karena dia mengajari saya ini ketika saya bermain-main.
sumber
Membagi dan menaklukkan adalah pendekatan yang baik. Cobalah untuk mengidentifikasi beberapa input yang terlihat (input pengguna / peristiwa jaringan ...) dan output (log, output ke pengguna, pesan jaringan keluar ...) di antara masalah yang ada. Coba letakkan cetakan pada potongan yang cukup besar atau titik-titik penting di antara mereka dan cobalah untuk mempersempit di mana bug berada dalam kode.
Membagi dan menaklukkan juga dapat bekerja dengan sangat baik jika terjadi regresi atas kode yang dikendalikan versi. Temukan dua build - satu di mana ia bekerja seperti yang diharapkan, yang lain dengan regresi. Persempit celah sampai Anda dibiarkan dengan sekelompok checkin sebagai tersangka potensial.
sumber
Daripada memotong bug biner, tulis tes dalam formulir
Untuk memverifikasi apa yang sebenarnya Anda ketahui benar tentang fungsi aplikasi versus apa yang Anda anggap benar.
Sebagian besar IDE memudahkan untuk mengekstrak metode dan menghasilkan potongan pengujian xUnit. Manfaatkan itu.
Mengapa tidak menaburkan debugs? Karena setelah Anda selesai, Anda mungkin harus membatalkan sebagian besar pekerjaan itu dan menghapus sejumlah besar debug tersebut. Saat Anda menulis tes, debugging Anda akan membantu dalam pencegahan dan deteksi bug di masa depan.
sumber
Terus debug. Jika Anda banyak men-debug, Anda akan meningkat.
sumber
Seperti orang lain katakan - jangan menganggap apa pun. Ini terutama benar jika kodenya sudah Anda tulis. Saat men-debug kode orang lain, Anda cenderung memperlambat karena kode itu baru bagi Anda atau Anda tidak mempercayai pembuat kode. Ketika men-debug kode Anda sendiri terlalu mudah untuk menganggap Anda menulisnya dengan benar, memperlambat!
Untuk proses debugging aktual:
Menambahkan unit test dan logging terlebih dahulu lebih efisien daripada menggunakan debugger terlebih dahulu. Anda juga mendapatkan keuntungan tambahan dari memiliki unit test untuk membantu tidak memperkenalkan bug di masa depan dan pencatatan akan membantu sesi debugging di masa depan.
sumber
Sebelum melangkah lebih dari satu potongan kecil kode, lihat apakah Anda dapat menentukan hasilnya secara akurat. Ini memang cenderung terbang dalam menghadapi jangan menganggap apa-apa (yang saya pilih BTW) tetapi ketika Anda mendapatkan pengalaman, itu dapat membantu mempersempit ke mana harus mencari.
Ini mungkin terdengar sepele, tetapi pelajari nuansa debugger Anda dan pelajari tombol pintasnya. Terkadang debugger bisa cukup lambat sehingga pikiran Anda bertanya-tanya ketika Anda melangkah. Jika Anda bisa mengimbangi mesin dan tidak berkeliaran, itu bisa membantu.
Jika Anda dapat mengubah kode saat debug:
seperti:
dari pada:
Untuk kasus Anda tidak dapat men-debug semuanya, untuk alasan apa pun, belajar untuk "bebek karet" dengan rekan kerja. Kadang-kadang tindakan menjelaskan menjelaskan. (ok, mungkin ini tidak persis dalam tema pertanyaan, tapi saya pikir itu cukup dekat untuk menjamin disebutkan)
sumber
if (tooCloseToHydrant || overTheBrink) {ketika Anda belajar lebih banyak nanti.Dua hal, berdasarkan menghabiskan sebagian besar 22 tahun terakhir mempertahankan kode orang lain menulis.
Pahami jenis bug yang cenderung Anda tulis.
Sebagai contoh, saya seorang pembuat kode yang sangat teliti, jadi setelah kode saya dikompilasi, biasanya bebas dari bug sepele. Jadi bug saya cenderung menjadi hal rumit yang aneh seperti kebuntuan thread. Di sisi lain, saya punya teman yang kebanyakan menulis bug sepele - titik koma di akhir C ++ untuk loop, jadi baris berikutnya hanya dieksekusi sekali, hal semacam itu.
Jangan berasumsi orang lain menulis jenis bug yang sama dengan yang Anda lakukan.
Saya tidak tahu berapa kali saya membuang waktu untuk mengeluarkan senjata debugging besar, dengan asumsi bug adalah jenis hal aneh yang sangat halus, hanya untuk membuat teman saya melihat ke belakang dan berkata, "Apakah Anda memperhatikan bahwa ekstra titik koma?" Setelah bertahun-tahun, saya pertama-tama mencari buah yang sepele dan tergantung rendah ketika melihat kode orang lain.
sumber
Ketahui alat Anda. Sebagai contoh, debugger Visual Studio memiliki fitur luar biasa yang disebut TracePoints yang seperti breakpoints tetapi bukannya menghentikan kode Anda, bukannya menyisipkan pernyataan jejak ke dalam output debug.
Sangat disarankan untuk membaca buku atau mengikuti kelas tentang cara menggunakan debugger Anda. Saya mengambil beberapa kelas dan membaca beberapa buku oleh John Robbins yang membuat perbedaan besar dalam efektivitas saya sebagai debugger.
sumber
Memahami secara fungsional apa yang coba dilakukan oleh kode. Jika Anda tidak tahu gambaran lengkapnya (semua kasus uji yang harus dilewati kode ini) sulit untuk di-debug dengan benar tanpa memperkenalkan bug baru
sumber
Tulis uji unit otomatis dan tipe integrasi dan tes fungsional lainnya.
Semakin banyak tes otomatis yang Anda miliki, semakin sedikit waktu yang Anda perlukan untuk debugger.
Juga, desain yang bagus - Prinsip SOLID. Jika Anda menulis kelas kecil, fokus, dan lebih menyukai komposisi daripada pewarisan, menghilangkan duplikasi, dll., Maka kode Anda akan selalu lebih mudah untuk di-debug.
Saya menemukan bahwa kode yang dirancang dengan baik menghasilkan serangkaian bug yang berbeda dengan kode yang tidak dirancang dengan baik. Secara umum, kode yang dirancang dengan baik menghasilkan bug yang lebih mudah ditemukan, diperbanyak, dan diperbaiki.
Pengecualian (dan selalu ada satu) adalah kode multithreading :-)
sumber
Jika Anda mempersempitnya ke wilayah kecil, tetapi masih tidak dapat menemukan kesalahan, coba opsi 'lihat kode + rakitan' dari debugger Anda. Mengetahui cukup ASM untuk mengatakan "harus ada cabang di sini" atau "mengapa hanya menyalin kata rendah?" akan sering menunjukkan kesalahan pengkodean.
sumber
Lihatlah buku yang sangat berharga Why Programs Fail: A Guide to Debugging Sistematik , oleh Andreas Zeller. Ini akan memperkenalkan Anda pada banyak teknik, teori, dan alat, beberapa di antaranya berada di ujung tombak penelitian.
Slide untuk buku tersedia online, tetapi saya menemukan buku itu sendiri lebih mudah dibaca.
Buku ini akan membantu Anda memulai dan membuat Anda berpikir lebih ilmiah tentang debugging, tetapi itu bukan pengganti untuk latihan. Anda mungkin perlu menulis dan men-debug selama 10 tahun sebelum Anda melihat urutan peningkatan besar dalam kinerja Anda. Saya masih ingat memiliki rahang saya turun di Sun melihat pengembang senior, yang telah pemrograman untuk Unix selama 30 tahun, menemukan bug multithreading atau paralel paralel dalam hitungan menit. Pengalaman itu penting!
sumber