Giriş

Bu makale, tarayıcı (frontend) ve sunucu tarafı (backend) hata ayıklama süreçlerini sistematik hale getirmek için tasarlanmış 10 adımlı bir kontrol listesi sunar. Kontrol listeleri yazılım süreçlerinde tekrar edilebilirlik ve doğruluk sağlar; bu yaklaşımın faydalarını detaylandıran bir kılavuza AppMaster çalışması örneklemektedir (bkz. kaynaklar).

Makale boyunca pratik adımlar, hangi araçların hangi durumda işe yaradığı ve hatayı tekrarlı olarak yakalamak için kullanabileceğiniz kısa şablonlar yer alır. Tarayıcı tarafı için araç önerileri ve debug akışları konusunda daha fazla bilgi için web.dev rehberine bakabilirsiniz.

Nasıl kullanılır?

Bu kontrol listesini bir hatayı ilk keşfettiğiniz andan, düzeltmeyi üretime göndermeye kadar takip edilecek bir süreç olarak düşünün. Her adımı uyguladıktan sonra bulgularınızı hataya ekleyin; böylece aynı hatayı tekrar eden ekip üyeleri için zaman kazanırsınız. Kritik üretim hatalarında, önce canlı kullanıcı etkisini sınırlamak (ör. feature flag, trafik kısıtlama) gerekebilir; bu makale genel izlemeleri kapsar, değişikliklerinizi canlıya uygulamadan önce değişiklik yönetimi süreçlerinizi takip edin.

10 Adımlı Kontrol Listesi

1) Sorunu yeniden üret ve ortam bilgilerini kaydet

• Adım adım yeniden üretme talimatlarını yazın: hangi sayfa/istek, hangi kullanıcı eylemi, hangi giriş verileri.
• Ortam bilgisi: tarayıcı ve sürümü, işletim sistemi, uygulama sürümü (commit/derleme), backend sürümü ve konfigürasyon bilgilerini toplayın.
• Eğer mümkünse minimal ve izole bir repro (ör. yeni bir tarayıcı profili veya küçük bir test sayfası) oluşturun.

2) Tarayıcı konsolu ve Network sekmesini kontrol et

Tarayıcı DevTools (örn. Chrome DevTools) ile konsol hatalarını, uyarıları ve ağ isteklerini inceleyin. Network sekmesinde isteklerin HTTP durum kodlarını, yanıt sürelerini ve hatalı yüklenen kaynakları görebilirsiniz. Chrome günlükleri ve ek debug seçenekleri için Google Chrome belgesine başvurabilirsiniz.

• XHR/fetch isteklerini filtreleyin, Request/Response headerlarını karşılaştırın.
• Kaynakların (JS/CSS) 404 veya 500 dönüp dönmediğini kontrol edin.

3) HAR, ekran görüntüleri ve log paketleri topla

• Network sekmesinden HAR dosyası oluşturun (gerektiğinde “Save all as HAR with content”).
• Hata anına ait konsol çıktılarını, stacktrace’leri ve ekran görüntülerini ekleyin.
• Kullanıcı veya test adımlarıyla eşleştirilmiş zaman damgalarıyla birlikte sunucu loglarını toplayın.

4) Stacktrace ve source map analizini yap

Frontend tarafında kod minify/uglify edilmişse source map’leri kullanarak gerçek dosya ve satır numarasını bulun. Backend tarafında stacktrace, hangi sınıf/metodun hataya neden olduğunu hızlıca gösterir. Hata izleme araçları veya Sentry gibi çözümler kullanıyorsanız stacktrace içindeki dosya/satır bilgilerini kontrol edin.

Daha ayrıntılı debugging araçları ve kaynak haritaları hakkında uygulamalı rehberler için web.dev içeriği yararlı olabilir.

5) İzolasyon: tarayıcı eklentileri, cache ve farklı ortamlar

• Tarayıcı eklentilerini devre dışı bırakın veya inkognito ile deneyin.
• Cache/Service Worker sorunlarını ekarte etmek için sayfayı cache temizleyerek yeniden yükleyin.
• Backend için bağımlılıkları (ör. third-party servisler) mocklayarak hatayı izole edin.

6) Sunucu logları, metrikler ve izleme verilerini incele

Sunucu tarafında uygulama loglarını, hata seviyesini (ERROR/WARN) ve zaman çizelgesini eşleştirerek analiz edin. İzleme panellerindeki (CPU, bellek, latency) ani değişimler hatanın kaynağı hakkında ipucu verebilir. Kritik servis çağrılarında timeout veya bağlantı hataları olup olmadığını kontrol edin.

7) Breakpoint ve adım adım (step-through) debugging

Tarayıcıda DevTools üzerinden breakpoint koyarak değişken değerlerini ve çağrı yığınını adım adım inceleyin. Backend için IDE’nizde (örneğin Visual Studio, VS Code vb.) debugger attach ederek gerçek zamanlı izleme yapın; Microsoft’un web hata ayıklama giriş notları sunucu tarafı debugging pratikleri için yararlı bilgiler içerir.

Sunucu tarafında canlı debug gerekiyorsa dikkatli olun: üretim ortamında performans etkileri ve güvenlik riskleri olabilir; mümkünse snapshot veya staging ortamında debug yapın.

8) API çağrılarını bağımsız olarak test et (curl/Postman)

• İstemciden bağımsız olarak backend uç noktasını test ederek istemci kaynaklı hata ihtimalini ele.
• Header, body ve authentication token’larını doğrulayın; CORS ön uçtan kaynaklanıyorsa Origin ve Access-Control headerlarını kontrol edin.

9) Düzeltme, test ve kod incelemesi

• Hatanın kaynağı belirlendikten sonra küçük, geri alınabilir bir düzeltme uygulayın.
• Birim testi/entegrasyon testi yazarak hatanın tekrar ortaya çıkmasını engelleyin.
• Pull request içine hatayı açıklayan kısa bir not ve repro adımlarını ekleyin; kod incelemesi sırasında test sonuçlarını paylaşın.

10) Dokümantasyon, kayıt kapatma ve öğrenilen dersler

• Hata kaydına: reproducer, loglar, root cause, çözüm ve hangi testlerin eklendiğini yazın.
• Eğer gerekiyorsa runbook veya operasyona adım ekleyin; aynı problem tekrar çıktığında hızlı müdahale sağlanır.

Pratik Örnekler (Kısa Senaryolar)

Örnek A — Tarayıcıda API isteği 401 döndürüyor

• Adım 1: Tarayıcı network sekmesinden ilgili XHR isteğini bulun, Request Header bölümünde Authorization başlığı var mı kontrol edin.
• Adım 2: Aynı isteği curl veya Postman ile çalıştırarak backend’in authenticator davranışını izole edin.
• Adım 3: Eğer token eksikse front-end kodunda token set eden adımı doğrulayın; token elde edildiği yerde Storage/Context güncellendi mi diye kontrol edin.
• Adım 4: Fix sonrası aynı isteklerde header’ın eklendiğini ve backend’in 200 döndüğünü doğrulayın; ilgili entegrasyon testi ekleyin.

Örnek B — Backend 500 ve NullReference tarzı hata

• Adım 1: Sunucu loglarını ve stacktrace’i bulun; hangi sınıf/metot ve satırın hataya yol açtığını tespit edin.
• Adım 2: Aynı girdiyle lokal veya staging ortamında reproducer çalıştırın.
• Adım 3: Gerekirse küçük birim testi yazarak null kontrolü veya varsayılan değer ekleyin; regression test ekleyin.

Hata Raporu Şablonu (Kısa)

• Başlık: Kısa ve açıklayıcı
• Adımlar: Hatanın yeniden üretimi için net adımlar
• Beklenen/gerçek davranış
• Ortam: tarayıcı/sürüm, backend sürümü, OS
• Ekler: HAR, stacktrace, log kesitleri, ekran görüntüleri
• Öncelik ve etki alanı

Araçlar ve Kısa Kaynak Rehberi

• Tarayıcı Debugging: Chrome DevTools (Console, Network, Sources) — bakınız Chrome dokümanı.
• Frontend kaynak haritaları, performans ve hata ayıklama: web.dev araç rehberi.
• Backend debugging giriş: Microsoft Learn sunucu tarafı hata ayıklama notları — Microsoft.

Sınırlamalar ve Güvenlik Uyarısı

Bu rehber genel iyi uygulamaları özetler; kritik üretim değişiklikleri sırasında kurumunuzun değişiklik yönetimi, on-call ve güvenlik politikalarını izleyin. Loglara şifre, token veya kişisel veri yazmaktan kaçının. Üretim üzerinde interaktif debug yapılması performans ve güvenlik riskleri taşıyabilir; mümkünse staging/snapshot ortamlarında test edin.

Kısa 10 Maddelik Hızlı Kontrol Listesi

1. Hatanın adımlarını yaz ve ortam bilgilerini kaydet.
2. Tarayıcı konsolu ve Network sekmesini kontrol et.
3. HAR, ekran görüntüsü ve log paketlerini topla.
4. Stacktrace ve source map ile dosya/satırı tespit et.
5. Eklentiler/cache izole ederek yeniden dene.
6. Sunucu loglarını ve metrikleri incele.
7. Breakpoints ile adım adım debug yap.
8. API’yi bağımsız test et (curl/Postman).
9. Fix uygula, test ekle ve kod incelemesi yap.
10. Dokümante et, regression test ekle ve kaydı kapat.

Kaynaklar

• AppMaster — İç uygulamalar için kontrol listeleri (kontrol listesi uygulamaları üzerine örnekler).
• web.dev — Araçlar ve hata ayıklama (frontend debug ve araç rehberi).
• Google Chrome — Tarayıcı hata ayıklama günlükleri (Chrome debug/günlük seçenekleri).
• Microsoft Learn — Sunucu tarafı hata ayıklama (backend debugging pratikleri).