🚨 J · Yaygın Hatalar ve Çözümleri

J · Yaygın Hatalar ve Çözümleri: Bu sözlük, bir **doktorun ayırıcı tanı (differential diagnosis) el kitabı** gibidir: AYNI belirti (örn.

Bu sözlük, bir **doktorun ayırıcı tanı (differential diagnosis) el kitabı** gibidir: AYNI belirti (örn. "request başarısız oldu") onlarca FARKLI kök nedenden gelebilir, ve yanlış teşhis yanlış tedaviye (yanlış ekibe escalate) yol açar. GRUP A-I boyunca (B1'deki eksik dependency, C3'teki middleware sırası, F5'teki contract defect, G4'teki test zinciri) HER GRUP kendi hata sınıfını doğurdu — bu sözlük onları TEK bir referans noktasında TOPLAR. Java'da bunun karşılığı bir "runbook"tur — production'da bir alarm çaldığında hangi log'a, hangi metriğe bakılacağını önceden yazılı olarak bilmek, panikle rastgele arama yapmaktan ÇOK daha hızlıdır. Peki bu sözlük neden ezberlemek yerine BAŞVURU kaynağı olarak kullanılmalı? Çünkü gerçek bir production ortamında karşılaşacağın hata mesajı BİREBİR burada olmayabilir — ama BURADAKİ 12 kalıp, "belirtiden kök nedene, kök nedenden doğru ekibe" giden DÜŞÜNME BİÇİMİNİ öğretir; bu düşünme biçimi her yeni, hiç görmediğin hataya da uygulanabilir.

Aşağıdaki 12 hata, bu sayfa boyunca gördüğün gerçek senaryolara dayanır. Her giriş: belirti (gerçek hata mesajı), kök neden, bozuk/düzeltilmiş kod örneği ve testerın bunu HANGİ katmanda (istemci/network, sunucu/kod, sözleşme/spec) yakaladığını içerir.

Bir Hatayı Katmana Göre Teşhis Etmek

🎬 Bir Hatanın Teşhis Sırası

Belirti: request başarısız

Bir request başarısız oldu — ama "başarısız" tek başına HANGİ EKİBE gideceğini söylemez.

İlk soru: bu HANGİ KATMANDA doğdu? Network paneli (GRUP E) ilk bakılacak yerdir.

Request sunucuya HİÇ ULAŞMADIYSA (ECONNREFUSED, CORS, timeout) → Client/Network katmanı.

Request ULAŞTI ama yanlış/sessiz bir sonuç döndüyse (400 yerine 201, boş body) → Server/Code katmanı.

Ders — Sunucu doğru çalıştı ama DOKÜMANLA uyuşmuyorsa (F5) → Contract/Spec katmanı. Doğru katmanı bulmak, doğru ekibe escalate etmenin ilk adımıdır.

Request gövdesi JSON olmasına rağmen `Content-Type` header'ı eksik veya `text/plain` gibi yanlış — sunucu gövdeyi hangi formatta ayrıştıracağını bilemiyor.

400, gövde HİÇ ayrıştırılamadığında (bozuk JSON); 422, gövde ayrıştırıldı ama bir İŞ KURALINI (minLength gibi) ihlal ettiğinde kullanılır. Çoğu API bu ayrımı yapmadan HER İKİ durumu da 400 döner — bu bir standart hatası değil ama sözleşmede AÇIKÇA belirtilmesi gerekir.

Tarayıcı, farklı bir origin'e (portlar bile farklı origin sayılır) request atmadan önce bir `OPTIONS` request'i (preflight) gönderir; sunucu bu request'e `Access-Control-Allow-Origin` header'ıyla CEVAP VERMEZSE tarayıcı GERÇEK request'i hiç göndermez.

Sunucu o portta HİÇ dinlemiyor — ya hiç başlatılmamış, ya çökmüş, ya da yanlış porta bağlanmaya çalışılıyor (bkz. C1'deki unutulan `app.listen`).