Hata ayıklama: hatayı bulmanın sistematik yolu

Hata ayıklama rastgele denemek değil, bir yöntemdir

Hata ayıklama (debugging), yazılımın beklenen ve gerçek davranışı arasındaki farkın nedenini bulup gidermektir. Yeni başlayanlar genellikle kodu rastgele değiştirip "belki olur" diye denerler. Deneyimli geliştiriciler ise bunu bilimsel bir sorgulama gibi yürütür: gözlem yapar, hipotez kurar, hipotezi sınar ve sonuca göre yeni hipotez üretir.

Bu yaklaşımın kazancı hem hız hem güvendir. Hız: hatanın neden kaynaklandığını anlamadan yapılan değişiklikler genellikle belirtiyi saklar, nedeni bırakır. Güven: hatanın gerçek nedenini bulup düzelttiğinizden emin olursunuz ve aynı hatanın başka yerlerde de olup olmadığını arayabilirsiniz. Hata ayıklama, bu nedenle bir araç bilgisinden çok bir düşünme disiplinidir; araçlar yalnızca bu disiplini hızlandırır.

Adım adım hata ayıklama akışı

Çoğu hatada işleyen akış şöyledir:

• Hatayı yeniden üretin. Hatayı güvenilir biçimde tetikleyemiyorsanız onu düzeltip düzeltmediğinizi de bilemezsiniz. Girdiyi, ortamı ve adımları kaydedin.
• Beklenen ile gerçek davranışı net yazın. "Çalışmıyor" bir tanım değildir; "bu girdi için şu sonuç beklenirken bu sonuç dönüyor" bir tanımdır.
• Kapsamı daraltın. Hatanın hangi katmanda (arayüz, iş mantığı, veri erişimi, dış servis) ortaya çıktığını bulun. Aralığı yarılayarak arama burada çok işe yarar: akışın ortasına bir kontrol noktası koyun, değer doğruysa sorun sonrasındadır, yanlışsa öncesindedir.
• Hipotez kurun ve sınayın. En olası nedeni seçin, onu doğrulayacak ya da çürütecek en ucuz denemeyi yapın.
• Nedeni bulunca düzeltin, ardından hatayı yakalayacak bir test yazın. Böylece hata geri dönerse otomatik fark edilir.
• Aynı sınıftan hataların başka yerlerde olup olmadığına bakın.

En sık yapılan hata, yeniden üretme adımını atlayıp doğrudan düzeltmeye geçmektir.

Debugger ile çalışmak: kesme noktaları ve adım adım izleme

Debugger, programı satır satır çalıştırmanıza ve o anki değişken değerlerine bakmanıza izin verir. Başlıca olanaklar şunlardır: kesme noktası (programı belirli bir satırda durdurur), adım atma (bir sonraki satıra, bir fonksiyonun içine ya da dışına geçme), çağrı yığınını görme (şu noktaya hangi çağrı zinciriyle gelindi), değişken ve ifade izleme, koşullu kesme noktası (yalnızca belirli bir koşul doğruyken durur).

Örneğin bir döngü binlerce kez dönüyor ve yalnızca belirli bir kayıtta hata veriyorsa, her turda durmak yerine yalnızca o kayıt geldiğinde duran koşullu bir kesme noktası koyarsınız. Durduğunuzda hatalı değerin nereden geldiğini görmek için çağrı yığınında geriye doğru ilerlersiniz. Yazdırma ifadeleri (print ile bakma) basit durumlarda hızlıdır, ancak debugger yeniden derlemeye gerek bırakmaz ve değişkenin tüm yapısını gösterir. Duruma göre birini seçin.

Yapılandırılmış loglama: çalışan sistemin hafızası

Debugger geliştirme ortamında çalışır; canlı sistemde ise elinizdeki tek iz loglardır. İyi loglama, hatayı sonradan anlamanızı sağlar. Yapılandırılmış loglamada her kayıt serbest metin yerine alanlara ayrılmış bir veridir: zaman, önem düzeyi, mesaj ve bağlam alanları (kullanıcı, istek kimliği, işlem adı gibi).

İşe yarayan pratikler: önem düzeylerini tutarlı kullanın (hata, uyarı, bilgi, ayrıntı); her isteğe bir izleme kimliği verip tüm kayıtlarda taşıyın, böylece dağınık servislerde bir isteğin yolunu izleyebilirsiniz; hatayı kaydederken yalnızca "hata oluştu" yazmayın, hangi işlemin, hangi girdiyle, hangi çağrı yığınıyla başarısız olduğunu ekleyin; parolalar, kimlik numaraları ve kart bilgileri gibi hassas veriyi asla loga yazmayın. Çok fazla log da sorundur: gürültü içinde asıl iz kaybolur ve depolama maliyeti artar. Ne zaman ayrıntı düzeyini açacağınıza dair bir ayar mekanizması kurun.

Zor hata sınıfları: ne yapılır?

Bazı hatalar yukarıdaki akışa kolay teslim olmaz:

• Zamanlamaya bağlı hatalar (yarış koşulu, kilitlenme): Her seferinde tekrarlanmazlar. Eşzamanlılığı artıran ya da araya gecikme sokan testlerle tetiklemeyi deneyin, paylaşılan durumu azaltın, kilit sıralarını gözden geçirin.
• Bellek sızıntıları ve aşırı bellek kullanımı: Bellek profil araçlarıyla zaman içindeki ayırma desenlerini karşılaştırın; hangi nesne türünün biriktiğini bulun.
• Performans sorunları: Tahminle değil ölçümle ilerleyin. Profil aracı zamanın ve kaynağın nerede harcandığını gösterir; çoğu zaman sezgi yanılır.
• Yalnızca canlıda görülen hatalar: Ortam farklarını (veri, yapılandırma, ağ, yük) listeleyin; canlı veriden temizlenmiş bir örnek ile yerelde yeniden üretmeye çalışın.
• Aralıklı dış servis hataları: Yeniden deneme, zaman aşımı ve devre kesici davranışını gözden geçirin; logda dış çağrının süresini ve sonucunu tutun.

Bu sınıflarda profil araçları ve gözlemlenebilirlik (loglar, ölçümler, izlemeler birlikte) başlıca yardımcılardır.

Olay sonrası inceleme: aynı hatayı bir daha yaşamamak

Hatayı düzeltmek işin yarısıdır. Canlıda ciddi bir sorun yaşandıysa, ekip olay sonrası inceleme yapar. Amaç suçlu bulmak değil, sistemin neden bu hatayı yakalayamadığını anlamaktır. İnceleme genellikle şunları içerir: olayın zaman çizelgesi, etkinin kapsamı, kök neden ve katkıda bulunan etkenler, neden daha erken fark edilmediği ve alınacak önlemler.

Önlemler somut ve sahipli olmalıdır: eksik bir test, eksik bir uyarı, belirsiz bir devir teslim süreci ya da zayıf bir loglama noktası. "Daha dikkatli olalım" bir önlem değildir; "şu hata türü için şu uyarı eklenecek" bir önlemdir. Suçlamasız bir kültürde bu incelemeler ekibin en değerli öğrenme kaynağına dönüşür.

Sık yapılan hatalar ve öğrenme yolu

• Belirtiyi tedavi etmek: Bir boş değer hatasını yalnızca boş kontrolü ekleyerek susturmak, değerin neden boş geldiğini açıklamaz.
• Aynı anda çok şeyi değiştirmek: Hangi değişikliğin işe yaradığını anlayamazsınız. Her denemede tek şeyi değiştirin.
• Hata mesajını okumamak: Çağrı yığını ve mesaj çoğu zaman yeri doğrudan gösterir. Önce onu dikkatle okuyun.
• Kendi koduna körlük: Sorunu önce kendi varsayımlarınızda arayın; kütüphaneyi suçlamak çoğu zaman son seçenek olmalı.
• Notsuz ilerlemek: Neyi denediğinizi yazmazsınız ve aynı yolu tekrar edersiniz.

Öğrenme yolunda sıra şu olabilir: önce kullandığınız dilin debugger'ını rahat kullanmayı öğrenin, sonra loglama düzenini oturtun, ardından profil araçlarına ve zor hata sınıflarına geçin. Kâğıt üzerinde düşünmeyi de ihmal etmeyin; hatayı bir meslektaşa anlatmak çoğu zaman cevabı kendiliğinden ortaya çıkarır.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Yazılımda Loglama ve Hata Ayıklama (Debugging) Teknikleri programının modülleri bu sayfadaki akışı izler: Yapılandırılmış Loglama Tasarımı, Debugger ile Hata Ayıklama, Zor Hata Sınıfları ve Profil Araçları ile Sistematik Teşhis ve Olay Sonrası İnceleme.