Hata ayıklamayı öğrenmek

Hata ayıklama nedir ve zamanınızın çoğu neden düzeltmeye değil bulmaya gidiyor?

Hata ayıklama, "çalışmıyor" ile "bu satır yanlış" arasındaki mesafeyi kapatmak demektir. Yeni başlayan birinin karşılaştığı hataların çoğunda düzeltme tek bir kelime ya da tek bir işarettir. Bütün iş, o kelimeye ulaşmaktır.

Her şeyi basitleştiren daha keskin bir tanım var: hata, programa dair inancınızın programın gerçekte yaptığı şeyden ayrıldığı yerdir. Bir program asla "tuhaf" davranmaz, keyfi de yoktur; tam olarak yazdığınız şeyi yapar. Yani hata ayıklama, tasavvurunuzun gerçeklikten ayrıldığı noktayı bulmaktır.

Bu tanımın pratik bir sonucu var. Hata, inanç ile gerçeklik arasındaki bir boşluksa, bu ikisini yan yana koyan her şey ilerlemedir, koymayan hiçbir şey değildir. Bir değeri yazdırmak ilerlemedir. Belki düzelir umuduyla bir satırı değiştirmek değildir; o kumardır ve en kötü yanı, kazandığınızda bile hiçbir şey öğrenmemenizdir.

Ve kimsenin yeni başlayanlara söylemediği bir şey: hata ayıklama hızınız, dili ne kadar bildiğinizden çok yönteminizin ne kadar düzenli olduğuna bağlıdır. Deneyimli bir geliştirici de aynı beş aşamadan geçer, sadece ilgisiz tahminleri daha hızlı eler.

Neden her şey hatayı tekrarlanabilir kılmakla başlar?

Güvenilir bir tekrar, şunu yazabilmeniz demektir: "şunu yap, şu olur." Bu cümleye sahip olana kadar başka hiçbir şeyin anlamı yoktur. Sonrasında ne değiştirirseniz değiştirin, düzeldi mi yoksa bu sefer olmadı mı bilemezsiniz.

İyi bir tekrarın üç unsuru vardır: hataya ulaşan en kısa yol, hatanın oluştuğu verinin kendisi ve tanımlı bir başlangıç durumu. "Bazen sipariş verirken hata veriyor" bir tekrar değildir. "Yeni oluşturulmuş bir kullanıcı, boş sepet ve süresi dolmuş bir indirim koduyla gönder düğmesi 500 döndürüyor" bir tekrardır ve bu tek cümle işin yarısını yapmıştır.

Şimdi tam da bu sitede zaman kaybettiren ve kendi teknik notlarımıza yazılmış bir tuzak: tekrarınız sandığınız şeyi test etmiyor olabilir. Burada bir sayfanın önbellek dosyasını sildiğimizde, web sunucusu o silinmiş dosyayı bir dakikaya kadar sunmaya devam eder, çünkü dosya arama sonucunu 60 saniye saklar. Silme işleminin hemen ardından sayfayı açarsanız eski sayfayı görür ve silmenin işe yaramadığı sonucuna varırsınız. İşe yaramıştı; siz erken baktınız.

Bu, genel bir hatanın özel bir hali: yaptığınız şeyle gördüğünüz şey arasında haberiniz olmayan bir katman vardır. Tarayıcı önbelleği, ağ önbelleği, kod önbelleği, dosyanın başka bir sunucudaki eski bir kopyası. Sorulacak ilk soru "neden çalışmıyor" değil, "değiştirdiğim şeyi çalıştırdığımdan emin miyim?" sorusudur. PHP kodunda bunu kanıtlamanın en basit yolu, bilerek yanlış bir yazdırma satırı koyup hiç görünüp görünmediğine bakmaktır.

Bir hata mesajı gerçekte nasıl okunur?

Yeni başlayanların çoğu hata mesajını okumaz. Bakar, kırmızıdan ürker ve doğrudan aramaya gider. Oysa mesaj genellikle tam ihtiyacınız olan şeyi söyler; kimse onlara okuma sırasını öğretmemiştir.

Sıradan bir hatanın üç parçası vardır. Tür, ne sınıf bir şeyin olduğunu söyler. Metin, neyin neye olduğunu söyler. Konum, bir dosya ve satır numarası verir. Arkalarında da genellikle bir yığın izi bulunur: buraya gelmek için çağrılmış fonksiyonlar zinciri.

Yığını aşağıdan yukarı okumayın. Hataya en yakın satır listenin en üstündedir, çünkü çoğu dil en yeniyi başa koyar. Ama asıl aradığınız en yakın satır değildir; kendi yazdığınız en yakın satırdır. İlk beş satır sizin yazmadığınız bir kütüphaneye aitse, sorun genellikle orada değildir; o kütüphaneyi çağırıp ona yanlış bir şey veren kendi kodunuzun ilk satırındadır.

Ve bu bölümün en önemli noktası: hatadaki satır numarası, sorunun fark edildiği yerdir, mutlaka oluştuğu yer değil. Satır 42 bir değişkenin boş olduğunu söylüyorsa, satır 42 sağlamdır; onu doldurması gerekip doldurmayan yer daha yukarıdadır. Günlük bir örnek: "null üzerinde bir metot çağrısı" mesajı neredeyse hiçbir zaman yazdırıldığı satırla ilgili değildir. O değeri üretmesini beklediğiniz, ama bunun yerine hiçbir şey döndüren satırla ilgilidir ve ikisi arasında on fonksiyon çağrısı olabilir.

Hiç hata vermediğinde ne yaparsınız?

En zor hatalar, hata vermeyenlerdir. Program çalışır, biter ve sonuç yanlıştır ya da hiç sonuç yoktur. Burada ilk belirlenecek şey şudur: gerçekten hata yok mu, yoksa var da siz mi göremiyorsunuz? Bu ikisi çok farklıdır ve çoğu durumda cevap ikincisidir.

Bir hatanın kaybolduğu üç olağan yer: sunucuda hata gösterimini kapatan bir dil ayarı, hatayı yutup onunla hiçbir şey yapmayan bir yakalama bloğu ve yanlış çıktı kanalı. Üçüncüsü en az bilinen ve en çok zaman yiyendir.

Bir komut satırı programının iki ayrı çıktı kanalı ve bir çıkış kodu vardır. Yalnızca ilkini okursanız, bozuk bir araçla boş bir sonuç size tıpatıp aynı görünür. Bu sunucudan gerçek bir örnek, bu dersin yazıldığı gün: WordPress veritabanı sorgu komutunu çalıştırdık ve standart çıktıya sıfır bayt yazdı. Orada "hiç satır yok" sonucuna varmak yanlış olurdu. Çıkış kodu 1 idi ve hata kanalında veritabanına hiç bağlanamadığı yazıyordu.

Bu bölümün kuralı: boş bir sonuç, yokluğun kanıtı değildir. Boş bir çıktıya güvenmeden önce çıkış koduna bakın ve hata kanalını ayrıca okuyun.

Aynı hatanın herkesin başına gelen daha basit bir hali var: arama aracınız bir şey bulamaz ve siz o şeyin var olmadığı sonucuna varırsınız. Tam da bu sitede, ana sayfadaki robots etiketi tek tırnakla yazdırılır. Onu çift tırnakla ararsanız sıfır sonuç alır ve etiketin eksik olduğunu ilan edersiniz. Etiket oradadır. Deseniniz yanlıştı ve araç tam olarak bunu söyledi: "istediğin bulunamadı." Gerisini siz eklediniz.

İkiye bölme: o tek satıra giden en kısa yol

Bir tekrarınız varsa, hatayı okuduysanız ve hâlâ nerede olduğunu bilmiyorsanız, neredeyse her zaman işe yarayan ve zekânıza bağlı olmayan bir yöntem var: ikiye bölün.

Mantığı basit. Programınız bin satırsa ve sorunun nerede olduğunu bilmiyorsanız, bakılacak bin yeriniz var. Yarısını devre dışı bırakın; hata hâlâ duruyorsa beş yüz yer elendi. On bölme, bini bire indirir. Saatlerce bakmayı gerektiren bir sorun için on adım.

Bunun üç pratik hâliyle kendi gününüzde karşılaşırsınız. Kodda: fonksiyonların yarısını yorum satırı yapın ya da erken return koyun. Veride: bin satırlık girdi dosyasını beş yüze indirip hatanın kalıp kalmadığına bakın; hâlâ hata veren en küçük girdiye ulaşana kadar. O girdi tek başına cevabın yarısıdır. Zamanda: dün çalışıp bugün çalışmıyorsa, bin satır arasında değil iki sürüm arasında arayın. Git'in tam bunun için bir komutu vardır, git bisect; bölmeyi sizin yerinize yapar ve sizden yalnızca her adımdan sonra o sürümün sağlam mı bozuk mu olduğunu söylemenizi ister.

Ve yeni başlayanları kurtaran bir nokta: bölerken hâlâ hata veren en küçük örneği mutlaka bir kenarda tutun. Aynı hatayı üreten on satırlık bir dosya, aynı hatayı üreten bin satırlık bir projeden kıyaslanamayacak kadar değerlidir, çünkü içinde dikkatinizi dağıtacak bir şey kalmamıştır. Birinden yardım isteyecekseniz de bütün projeyi değil, o on satırı gönderirsiniz.

Her seferinde tek bir şeyi değiştirin ve denediklerinizi yazın

Küçük bir alana indiğinizde, daha çabuk bitsin diye üç şeyi birden değiştirmek isteyeceksiniz. İşe yararsa hangisinin düzelttiğini bilemezsiniz. Kötüleşirse artık bir yerine üç değişkeniniz olur. Acele etmenin sizi kesinlikle yavaşlattığı tek yer burasıdır.

Doğru yöntemin sabit bir biçimi vardır. Yanlışlığı kanıtlanabilir bir hipotez kurun: "sanırım önbellekten" değil, "önbellekten ise, temizleyince sonuç değişir." Sonra bu hipotezi doğrulayacak ya da öldürecek en ucuz testi seçin, yalnızca o tek şeyi değiştirin ve sonuca bakın. Hipotez yanlışsa değişikliği geri alın. Yeni başlayanlar bu son kısmı atlar ve bir saat sonra kod, kendisi yeni hata olan ilgisiz düzenlemelerle dolar.

Ve bir kez denemeden kimsenin değerine inanmadığı bir alışkanlık: bir metin dosyası açın ve denediğiniz her şeyi sonucuyla birlikte yazın. Satır başına üç kelime. Size üç şey kazandırır: aynı şeyi iki kez denemekten kurtulursunuz, yarın döndüğünüzde sıfırdan başlamazsınız ve sorunu birine anlatmanız gerekirse anlatım hazırdır.

Çoğu zaman cevabı üreten şey, o anlatımı yazmaktır. İnsanların buna bir adı bile var: sorunu tarafsız bir dinleyiciye sesli anlatmak, o dinleyici masadaki plastik bir oyuncak olsa bile. Sebebi şu: anlatmak, varsayımlarınızı tek tek söylemeye zorlar ve hata genellikle o kadar apaçık göründüğü için hiç dile getirmediğiniz varsayımdadır.

Yazdırmak mı hata ayıklayıcı mı? Peki canlı sunucuda?

İki ana aracınız var ve hangisinin daha iyi olduğunu tartışmak anlamsız, çünkü farklı işler yapıyorlar.

Yazdırmak, bir değişkenin değerini gösteren bir satır eklemektir. Avantajı her yerde çalışmasıdır: küçük bir betikten erişiminiz olmayan bir sunucuya kadar, üstelik hiçbir kurulum istemez. Dezavantajı, her çalıştırmanın size tek bir anlık görüntü vermesidir; yanlış yere koyduysanız yeniden çalıştırmanız gerekir. Günlük hataların çoğu için yeterlidir ve profesyonellerin yazdırmadığını söyleyen kişi, profesyonelleri yakından izlememiştir.

Hata ayıklayıcı programı yolun ortasında durdurur, bütün değişkenleri bir arada görmenizi ve satır satır ilerlemenizi sağlar. Nereye yazdıracağınızı hiç bilmediğinizde ya da kodun akışı o kadar çok dallandığında ki hangi dala girildiğini kestiremediğinizde hakkını verir. Öğrenmek yarım gün alır ve o yarım günü çabuk geri alırsınız.

Canlı bir sunucuda ikisi de olağan hâliyle işlemez. Hata ayıklayıcı bağlayamazsınız ve ziyaretçinin göreceği bir şey yazdıramazsınız. Orada tek bir şeyiniz vardır: günlük. Ve bir kez anlatmaya değer yaygın bir hata: günlüğe yazmak, görülmek demek değildir. Sunucunun hata seviyeleri mesajınızın hiç kaydedilmeyeceği şekilde ayarlanmış olabilir ya da günlük dosyası aklınıza gelmeyecek bir yerde olabilir. Bir hatanın peşine düşmeden önce günlüğe anlamsız bir satır yazın ve onu bulun. O satırı görene kadar, diğer mesajları görmemeniz hiçbir şeyi kanıtlamaz.

Hazır buradayken, günlüğe asla girmemesi gereken üç şey: parolalar, jetonlar ve kullanıcıların kişisel verileri. Günlük, birkaç kişinin okuduğu ve uzun süre duran bir dosyadır.