Hata Ayıklama: Kendiniz Bulun

Çoğu başlangıç seviyesi programcı bir hatayı bir duvar gibi görür. Ona çarparlar, durur ve birinden onun üstünden geçmesini isterler. Gerçekten beceri oluşturan alışkanlık başkadır: hatayı bulunabilir bir cevabı olan bir soru gibi görmeyi öğrenirsiniz ve sormadan önce onu bulursunuz.

Hata mesajını gürültü değil kanıt gibi okuyun

Stack trace'ler korkutucu görünmeleri için sürekli atlanır. Ama genellikle tam olarak nerede ve neden bir şeyin kırıldığını size söyler. Python'da TypeError: 'NoneType' object is not subscriptable alırsanız, bu rastgele saçma değildir — bir liste veya dict içermesini beklediğiniz bir değişkenin aslında None olduğu anlamına gelir. Satır numarası size nerede olduğunu söyler. Sizin işiniz o satırdan geriye doğru iz sürüp değerin nerede ayarlanması gerektiğini ama ayarlanmadığını bulmaktır.

Bunu çevrimiçi bir şey aramadan önce yapın: trace'in son satırını önce okuyun, sonra yukarı doğru ilerleyin. Son satır genellikle gerçek istisnayı adlandırır. Üzerindeki satırlar sizi oraya ulaştıran çağrı zincirini gösterir.

Bunu kasıtlı olarak yeniden üretin

Eğer bir hata sadece bazen görünüyorsa, bunu henüz anlamıyorsunuz demektir. Kodu değiştirmeden önce, bunun güvenilir bir şekilde olmasını sağlamaya çalışın. Bir seferde bir girdi değiştirin. Boş liste için başarısız olur ama dolu bir liste için olmaz mı? Sadece bir fonksiyonun ikinci çağrısında başarısız olur, birinci değil mi? Komut halinde yeniden üretebileceğiniz bir hata, %80 çözülmüş bir hatadır, çünkü artık bir düzeltmenin gerçekten işe yarayıp yaramadığını test edebilirsiniz, tahmin etmek yerine.

Sorunu yarıya, sonra tekrar yarıya bölün

Binary search sadece sıralı diziler için değildir — uzun bir fonksiyonda veya pipeline'da kırılmış kodu bulmanın en hızlı yoludur. Mantığınızın ikinci yarısını yorumlayın veya geçin ve birinci yarının hala hatayı üretip üretmediğini kontrol edin. Evet ise, sorun birinci yarıdadır. Hayır ise, ikinci yarıdadır. Tekrarlayın. Bu, 200 satırlık bir script için print() veya df.head() ile her aşamada çıktıları kontrol ettiğiniz çok aşamalı bir veri pipeline'ı için de çalışır.

Bu, baskı altında çoğu insanın yaptığı satırları rastgele değiştirip yeniden çalıştırmaktan çok daha iyidir ve bu çok daha fazla zaman boşa harcar.

print() çalışmayı bıraktığında debugger kullanın

print() ifadeleri basit durumlar için iyidir, ama bir kez birden fazla fonksiyon çağrısı arasında durumu takip etmeye başladığınızda, gerçek bir debugger gerçek zaman tasarrufu sağlar. Python'da, şüpheli satırdan hemen önce import pdb; pdb.set_trace() yerleştirin, script'i çalıştırın ve değişkenleri inceleyebileceğiniz, n ile satır satır ilerleyebileceğiniz ve s ile fonksiyon çağrılarının içine girebileceğiniz bir live prompt alırsınız. VS Code'un yerleşik debugger'ı yazı yerine tıkladığınız breakpoint'lerle aynı şeyi yapar. Her iki şekilde de, amaç aynıdır: programınızın gerçek durumunu izleyin, bunun muhtemelen ne olduğunu tahmin etmek yerine.

Bunu projenizin geri kalanından izole edin

Eğer bir hata büyük bir kod tabanının içinde gerçekleşirse, bunu büyük kod tabanının içinde ayıklamayın. İlgili fonksiyonu, aynı hatayı tetikleyen sahte, minimal girdi ile yeni bir dosyaya kopyalayın. Hata kaybolursa, çevre hakkında bir şey — bir global değişken, bir import, eski durum — gerçek sebeptir ve siz az önce önemli bir şey öğrendiniz. Eğer hata izolasyonda devam ederse, artık küçük, paylaşılabilir, test edilebilir bir durum vardır ve gerçek düzeltmeye çok daha yakınsınız.

Varsayımlarınızı hafızaya karşı değil gerçeğe karşı kontrol edin

Hata ayıklama zamanının büyük bir kısmı sorgulanmayan varsayımlara gider: