--- title: "Hata Ayıklayıcıyı Gerçekten Kullanmak: print() Ötesine Geçmek" url: "https://cilginyazilim.com/blog/hata-ayiklayiciyi-gercekten-kullanmak-debugger" description: "Koşullu kesme noktaları, izleme ifadeleri, çağrı yığını ve adım adım yürütme: IDE hata ayıklayıcısını verimli kullanmanın pratik teknikleri ve kurulum ipuçları." published: "2026-09-27T10:00:00+03:00" modified: "2026-09-27T10:00:03+03:00" author: "Çılgın Yazılım" category: "Geliştirici Araçları" tags: ["php", "javascript", "geliştirici araçları", "verimlilik", "vs code", "hata ayıklama", "ide", "profil çıkarma", "hata ayıklayıcı", "debugger", "xdebug", "kesme noktası", "kod okuma"] site: "Çılgın Yazılım" language: "tr" --- # Hata Ayıklayıcıyı Gerçekten Kullanmak: print() Ötesine Geçmek Çoğu geliştirici hata ayıklayıcıyı kurmadığı için print ile çalışır. Bir kez kurulduğunda geri dönüşü olmayan bir alışkanlıktır. Bir **hata ayıklayıcı** (debugger), yazılım geliştirmenin en güçlü ama en az kullanılan aracıdır. Sebebi teknik değil pratiktir: kurulumu bir kere zahmetlidir, o zahmete girilmediği için geliştiriciler `print`, `var_dump` veya `console.log` ile devam eder. Bu yöntem küçük sorunlarda işe yarar; ancak bir hatanın üç katman derinde ve yalnızca belirli bir kayıtta oluştuğu durumlarda, çıktı satırları ekleyip sayfayı yeniden yükleyerek geçirilen saatler, doğru kurulmuş bir hata ayıklayıcıyla dakikalara iner. ![Hata ayıklayıcı özellikleri listesi](https://cilginyazilim.com/uploads/blog/2026/07/hata-ayiklayiciyi-gercekten-kullanmak-debugger-ozet.png) *Koşullu kesme noktası tek başına print döngüsünün çoğunu ortadan kaldırır.* ## print ile hata ayıklamanın gerçek maliyeti Çıktı yazdırarak hata aramanın sorunu yavaş olması değil, *döngüsel* olmasıdır. Her yeni soru için kodu değiştirmek, kaydetmek, yeniden çalıştırmak ve çıktıyı okumak gerekir. Yanlış yere koyduysanız döngü baştan başlar. Ayrıca bu satırların bir kısmı er ya da geç üretime sızar — kod incelemelerinde en sık yakalanan artıklardan biridir. Hata ayıklayıcı ise programı çalışırken dondurur ve o anda *her şeye* aynı anda bakmanızı sağlar: tüm yerel değişkenler, nesnelerin içi, çağrı yığını. Yeni bir soru sormak için kodu değiştirmeniz gerekmez. ## Gerçekten fark yaratan beş özellik ### 1. Koşullu kesme noktası En değerli özellik budur ve en az bilinenidir. Bir döngü 4.000 kez dönüyor ve sorun yalnızca belirli bir kayıtta çıkıyorsa, normal kesme noktası işe yaramaz. Koşullu kesme noktası ise "yalnızca `$siparis->id === 4718` olduğunda dur" demenizi sağlar. Tek başına bu özellik, çıktı yazdırma alışkanlığının çoğunu gereksiz kılar. ### 2. İstisnada otomatik durma Hata ayıklayıcıyı "istisna fırlatıldığında dur" olarak ayarladığınızda, hatanın oluştuğu anki tam durumu görürsünüz — yığın izinde okuduğunuz özet değil, değişkenlerin gerçek değerleri. Yakalanan ama yutulan istisnaları bulmak için de en hızlı yöntemdir. ### 3. Çağrı yığını "Bu fonksiyona buraya nereden gelindi?" sorusu, özellikle framework içinde çalışırken en sık sorulan sorudur. Çağrı yığınında yukarı doğru gezinmek, her katmandaki değişken değerlerini de görmenizi sağlar. Tanımadığınız bir kod tabanını öğrenmenin en hızlı yollarından biri budur: bir isteğe kesme noktası koyup çağrı zincirini takip etmek, dokümantasyon okumaktan daha öğreticidir. ### 4. İzleme ifadeleri Bir değişkeni veya bir ifadeyi (`count($sepet->urunler)` gibi) sürekli izlemeye alabilirsiniz. Adım adım ilerlerken bu değerin ne zaman değiştiğini görmek, "bu dizi nerede boşalıyor?" türü soruları doğrudan cevaplar. ### 5. Çalışma anında değer değiştirme Duraklatılmış durumda bir değişkenin değerini değiştirip yürütmeye devam edebilirsiniz. Bu, yeniden üretmesi zor senaryoları simüle etmenin pratik yoludur: bir bayrağı elle `true` yapıp o kod yolunun ne yaptığını görmek gibi. ## Adım komutlarını doğru kullanmak Üç temel komut vardır ve karıştırıldığında hata ayıklama yavaşlar. *Step over* mevcut satırı çalıştırır ama fonksiyonun içine girmez — çoğu zaman istediğiniz budur. *Step into* çağrılan fonksiyonun içine girer; yalnızca sorunun orada olduğunu düşündüğünüzde kullanın, aksi hâlde framework kodunun içinde kaybolursunuz. *Step out* ise içinde bulunduğunuz fonksiyonu bitirip çağırana döner ve yanlışlıkla girilen bir fonksiyondan çıkmanın en hızlı yoludur. ## Kurulum: asıl engel burada PHP tarafında hata ayıklayıcı, çoğu geliştiricinin bir kez deneyip vazgeçtiği noktadır. Pratik olarak gereken üç şey vardır: eklentinin PHP tarafında etkin olması, dinleme portunun IDE ile aynı olması ve — özellikle Docker veya sanal makine kullanılıyorsa — yol eşlemesinin doğru tanımlanması. Yol eşlemesi yanlışsa hata ayıklayıcı bağlanır ama kesme noktaları hiç tetiklenmez; bu, en sık karşılaşılan ve en çok vazgeçirten durumdur. Performans notu: hata ayıklama eklentisini sürekli açık bırakmak uygulamayı belirgin şekilde yavaşlatır. Doğru kurulum, yalnızca tetiklendiğinde devreye giren bir yapılandırmadır; üretim ortamında ise kesinlikle kapalı olmalıdır. Editör verimliliğini artıran diğer ayarlar için [VS Code verimlilik rehberimize](https://cilginyazilim.com/blog/vs-code-verimlilik-ayarlari-ve-kisayollar), eklenti yükünü dengelemek için eklenti şişkinliği yazımıza bakabilirsiniz. Kurulum ayrıntıları için [VS Code hata ayıklama dokümantasyonu](https://code.visualstudio.com/docs/editor/debugging) güncel bir kaynaktır. ## Hata ayıklayıcının yetmediği yerler Dürüst olmak gerekirse her durumda uygun değildir. Üretim ortamındaki bir soruna kesme noktası koyamazsınız; orada yapılandırılmış log ve izleme gerekir — bu konuda [log yazma rehberimiz](https://cilginyazilim.com/blog/uretimde-log-a-ne-yazmali-ne-yazmamali) yol gösterir. Yarış durumları ve zamanlamaya bağlı hatalar, programı durdurduğunuz an kaybolabilir. Performans sorunları için ise hata ayıklayıcı değil profil çıkarıcı gerekir; sistematik yaklaşım için hata ayıklama alışkanlıkları yazımız tamamlayıcıdır. ## Sonuç Hata ayıklayıcı kullanmamanın sebebi neredeyse hiçbir zaman "gerek duymamak" değil, bir kereye mahsus kurulum engelini aşmamış olmaktır. Bu engeli aşan geliştiriciler geri dönmez, çünkü koşullu kesme noktası ve çağrı yığını gibi özellikler, çıktı yazdırarak yapılan aramanın karşılayamayacağı sorulara anında cevap verir. Bu hafta bir öğleden sonranızı ayırıp yerel ortamınızda hata ayıklayıcıyı çalışır hâle getirin ve ilk kesme noktanızı en karmaşık bulduğunuz akışa koyun. O akışın nasıl çalıştığını, muhtemelen ilk kez gerçekten göreceksiniz. ## Sıkça Sorulan Sorular ### Hata ayıklayıcı uygulamayı yavaşlatır mı? Eklenti sürekli etkinken evet, belirgin şekilde. Yalnızca istek üzerine devreye giren bir yapılandırma kullanmak ve üretimde tamamen kapalı tutmak gerekir. ### Kesme noktaları neden hiç tetiklenmiyor? En yaygın sebep yol eşlemesinin yanlış olmasıdır: IDE'nin gördüğü dosya yolu ile sunucudaki yol farklıysa hata ayıklayıcı bağlanır ama durmaz. Docker ve sanal makine kurulumlarında bu ayar mutlaka kontrol edilmelidir. ### print ile hata ayıklamak tamamen yanlış mı? Hayır, hızlı ve basit kontroller için tamamen meşrudur. Sorun, karmaşık ve derin hatalarda tek yöntem olarak kullanılmasıdır. ### Üretim ortamında hata ayıklayıcı kullanılabilir mi? Kullanılmamalıdır: performans etkisi ve güvenlik riski nedeniyle. Üretimde ihtiyaç duyulan şey yapılandırılmış log, izleme ve hata takip sistemidir. --- Kaynak: [Hata Ayıklayıcıyı Gerçekten Kullanmak: print() Ötesine Geçmek](https://cilginyazilim.com/blog/hata-ayiklayiciyi-gercekten-kullanmak-debugger)