Debugging: Menemukannya Sendiri

Kebanyakan pemula memperlakukan bug seperti dinding. Mereka memukulnya, berhenti, dan meminta orang lain untuk memanjatnya. Kebiasaan yang benar-benar membangun keterampilan adalah berbeda: Anda belajar memperlakukan bug seperti pertanyaan yang memiliki jawaban yang dapat ditemukan, dan Anda menemukannya sebelum Anda bertanya.

Baca pesan error seperti itu bukti, bukan kebisingan

Stack traces terus diabaikan karena terlihat menakutkan. Tetapi mereka biasanya memberi tahu Anda dengan tepat di mana dan mengapa sesuatu rusak. Jika Anda mendapat TypeError: 'NoneType' object is not subscriptable di Python, itu bukan omong kosong acak — itu berarti sebuah variabel yang Anda harapkan untuk menampung list atau dict sebenarnya adalah None. Nomor baris memberi tahu Anda di mana. Pekerjaan Anda adalah melacak ke belakang dari baris itu dan menemukan di mana nilai seharusnya telah diatur tetapi tidak.

Lakukan ini sebelum mencari apa pun secara online: baca baris terakhir traceback terlebih dahulu, kemudian naik. Baris terakhir biasanya menuliskan pengecualian aktual. Baris di atasnya menunjukkan call chain yang membawa Anda ke sana.

Reproduksikan dengan sengaja

Jika bug hanya muncul terkadang, Anda belum memahaminya. Sebelum menyentuh kode, coba buatnya terjadi secara konsisten. Ubah satu input pada satu waktu. Apakah gagal dengan list kosong tetapi bukan list penuh? Apakah gagal hanya pada panggilan kedua ke fungsi, bukan yang pertama? Bug yang dapat Anda reproduksi sesuai perintah adalah bug yang 80% teratasi, karena sekarang Anda dapat menguji apakah perbaikan benar-benar berhasil bukan sekedar menebak.

Potong masalah menjadi dua, kemudian dua lagi

Binary search bukan hanya untuk array yang diurutkan — itu adalah cara tercepat untuk menemukan kode yang rusak dalam fungsi panjang atau pipeline. Komentari atau lewati setengah kedua logika Anda dan periksa apakah setengah pertama masih menghasilkan bug. Jika ya, masalahnya ada di setengah pertama. Jika tidak, masalahnya ada di setengah kedua. Ulangi. Ini bekerja untuk skrip 200 baris sama baiknya dengan berfungsi untuk pipeline data multi-tahap di mana Anda memeriksa output di setiap tahap dengan print() atau df.head().

Ini mengalahkan pengubahan baris secara acak dan menjalankan kembali, yang dilakukan sebagian besar orang di bawah tekanan dan membuang waktu jauh lebih banyak daripada yang disimpan.

Gunakan debugger bukan print() ketika print() berhenti bekerja

Pernyataan print() baik-baik saja untuk kasus sederhana, tetapi setelah Anda memburu state di beberapa panggilan fungsi, debugger aktual menghemat waktu nyata. Di Python, letakkan import pdb; pdb.set_trace() tepat sebelum baris yang mencurigakan, jalankan skrip, dan Anda mendapatkan prompt langsung di mana Anda dapat memeriksa variabel, melangkah baris demi baris dengan n, dan melangkah ke panggilan fungsi dengan s. Debugger bawaan VS Code melakukan hal yang sama dengan breakpoint yang Anda klik bukan ketik. Bagaimanapun, tujuannya sama: amati state aktual program Anda bukan menebak apa yang mungkin terjadi.

Isolasi dari sisa proyek Anda

Jika bug terjadi di dalam basis kode besar, jangan debug di dalam basis kode besar. Salin fungsi yang relevan ke file segar dengan input minimal palsu yang memicu kegagalan yang sama. Jika bug hilang, ada sesuatu tentang konteks sekitar — variabel global, import, state basi — adalah penyebab sebenarnya, dan Anda baru saja belajar sesuatu yang penting. Jika bug bertahan dalam isolasi, Anda sekarang memiliki kasus kecil, dapat dibagikan, dapat diuji, dan Anda jauh lebih dekat ke perbaikan aktual.

Periksa asumsi Anda terhadap kenyataan, bukan memori

Bagian besar waktu debugging dihabiskan untuk asumsi yang tidak dipertanyakan: