05 Oca 2026·5 dk
Yazmadığınız hata raporlarını ayıklayın: pratik bir iş akışı
Yazmadığınız hata raporlarını tekrar üretmek için pratik bir iş akışı: sorunu çoğaltma, UI/API/DB katmanını izole etme ve minimal, test edilebilir bir düzeltme isteme.
Yazmadığınız hata raporlarını tekrar üretmek için pratik bir iş akışı: sorunu çoğaltma, UI/API/DB katmanını izole etme ve minimal, test edilebilir bir düzeltme isteme.
Başkasının yazdığı bir hata raporunu ayıklamak zor çünkü orijinal geliştiricinin zihinsel haritası eksik. Hangi şeylerin kırılgan olduğunu, neyin "normal" olduğunu ya da hangi kestirme yolların alındığını bilmiyorsunuz. Küçük bir belirti (bir buton, bir yazım hatası, yavaş bir ekran) API, veritabanı veya arka plan işiyle ilgili daha derin bir sorundan kaynaklanabilir.
Yararlı bir hata raporu size dört şey verir:
Çoğu rapor yalnızca sonuncusunu verir: "Kaydetme çalışmıyor", "bozuk", "rastgele hata." Eksik olan, tekrarlanabilir yapan bağlamdır: kullanıcı rolü, spesifik kayıt, ortam (prod vs staging) ve bir değişiklikten sonra başlayıp başlamadığı.
Amaç, belirsiz bir semptomu güvenilir bir çoğaltıma çevirmektir. Bir kere isteğiniz üzerine bunu üretebiliyorsanız, gizemli olmaktan çıkar. Bu, bir dizi kontroldür.
Hemen kontrol edebileceğiniz şeyler:
"Bitti" demek "sanırım düzelttim" demek değildir. Bitti: çoğaltım adımlarınız küçük bir değişiklikten sonra geçiyor ve hızlıca etkilenmiş olabilecek yakın davranışları yeniden test edebiliyorsunuz.
Zaman kaybetmenin en hızlı yolu birden fazla şeyi aynı anda değiştirmektir. Başlangıç noktanızı dondurun ki her test sonucu bir şey ifade etsin.
Bir ortam seçin ve problemi çoğaltana kadar orada kalın. Rapor prod'dan geldiyse önce orada doğrulayın. Riskliyse staging kullanın. Yerel ortam, verileri ve ayarları yakından eşleştirebiliyorsanız uygundur.
Sonra hangi kodun gerçekten çalıştığını sabitleyin: sürüm, build zamanı ve akışı etkileyen feature flag'ler veya konfigürasyon. Küçük farklar (devre dışı bırakılmış entegrasyonlar, farklı API base URL, eksik arka plan işleri) gerçek bir hatayı hayalete çevirebilir.
Temiz, tekrarlanabilir bir test altyapısı oluşturun. Yeni bir hesap ve bilinen veriler kullanın. Mümkünse her denemeden önce durumu sıfırlayın (çıkış yap, cache temizle, aynı kayıttan başla).
Varsayımlarınızı yazın. Bu meşguliyet değil; sonra kendinizle tartışmayı engeller.
Bir temel not şablonu:
Eğer çoğaltma başarısız olursa, bu notlar sıradaki hangi düğmeyi birer birer çevireceğinizi söyler.
Hızlı kazanım, belirsiz bir şikayeti bir komut dosyası gibi çalıştırılabilir bir şeye çevirmektir.
Başlangıç olarak raporu kısa bir kullanıcı hikâyesi olarak yeniden yazın: kim ne yapıyor, nerede ve ne bekliyordu. Sonra gözlenen sonucu ekleyin.
Örnek yeniden yazım:
"Bir faturalama yöneticisi olarak, bir fatura durumunu Paid'e değiştirip fatura sayfasında Kaydet'e tıkladığımda, durum kalıcı olmalı. Bunun yerine sayfa aynı kalıyor ve yenilemeden sonra durum değişmemiş durumda."
Sonra raporu doğru yapan koşulları yakalayın. Hatalar genellikle tek bir eksik detaya bağlıdır: rol, kayıt durumu, locale veya ortam.
Tıklamadan önce yazılacak ana girdiler:
Orijinal davranışı kaydederken kanıt toplayın. Ekran görüntüleri yardımcıdır ama kısa bir kayıt zamanlama ve tam tıklamaları yakaladığı için daha iyidir. Her zaman bir zaman damgası (zaman dilimiyle) not edin ki loglarla eşleştirebilesiniz.
En çok tahminleri ortadan kaldıran üç netleştirici soru:
Nedeni tahmin ederek başlamayın. Problemi bilerek, aynı şekilde, birden fazla kez meydana getirin.
Önce raporlayanın adımlarını tam olarak çalıştırın. Onları "iyileştirmeyin." Deneyiminizin ilk saptığı farklılığı not edin; küçük bir farklılık bile (farklı buton etiketi, eksik alan, hafifçe farklı hata metni) ipucu olabilir.
Çoğu uygulamada işe yarayan basit bir iş akışı:
Tekrarlanabilir olduktan sonra bir seferde bir şeyi değiştirin. Genelde işe yarayan tek değişken testleri:
Sonunda başkası 2 dakikada çalıştırabilecek kısa bir repro betiği bırakın: başlangıç durumu, adımlar, girdiler ve ilk başarısız gözlem.
Tüm kod tabanını okumadan önce hangi katmanın başarısız olduğuna karar verin.
Soru: belirti sadece UI'da mı, yoksa veri ve API yanıtlarında da mı var?
Örnek: "Profil adım güncellenmedi." Eğer API yeni adı döndürüyorsa ama UI hâlâ eskiyi gösteriyorsa UI durum/önbellek sorumlusu olabilir. API hiç kaydetmiyorsa API veya DB tarafındasınız demektir.
Birkaç dakikada cevaplanabilecek hızlı triage soruları:
UI kontrolleri görünürlükle ilgilidir: console hataları, Network sekmesi ve eski durum (UI kaydettikten sonra yeniden çekmiyor veya eski önbellekten okuyor olabilir).
API kontrolleri sözleşmeyle ilgilidir: payload (alanlar, tipler, ID'ler), status kodu ve hata gövdesi. Beklenmeyen bir gövde ile gelen 200, 400 kadar önemlidir.
DB kontrolleri gerçektir: eksik satırlar, kısmi yazımlar, kısıt hataları, WHERE koşulunun eşleşmemesinden dolayı 0 satır güncelleme.
Yönünüzü korumak için küçük bir harita çizin: hangi UI eylemi hangi endpoint'i tetikliyor ve hangi tablo(lar)ı okuyor/yazıyor.
Netlik genellikle tıkladığınız istekten veritabanına ve geri dönen yolun izlenmesinden gelir.
Rapor veya repro için üç çapaç (anchor) yakalayın:
Korelasyon ID'si yoksa, gateway/backend'inize bir tane ekleyin ve yanıt başlıklarına ile loglara dahil edin.
Gürültüye boğulmamak için sadece "Nerede başarısız oldu ve neden?" sorusunu cevaplamak için gerekenleri yakalayın:
İzlemeniz gereken sinyaller:
Eğer "dün çalışıyordu ama bugün çalışmıyor" ise ortam kayması şüphelenin: değişen flag'ler, döndürülen sırlar, eksik migration'lar veya durmuş işler.
En kolay düzeltilecek hata, küçük ve tekrarlanabilir bir denemedir.
Her şeyi küçültün: daha az tıklama, daha az alan, hatayı hâlâ tetikleyen en küçük veri seti. Eğer sadece "çok kayıtlı müşterilerde" oluyorsa, yine de tetikleyen minimal bir örnek oluşturun. Oluşturamıyorsanız bu, hatanın veri hacmiyle ilgili olabileceğine işaret eder.
"Kötü durum" ile "kötü kod"u ayırmak için durumu kasıtlı olarak sıfırlayın: temiz hesap, yeni tenant veya veri seti, bilinen build.
Repro'yu net tutmanın pratik yollarından biri kompakt bir giriş tablosu tutmaktır:
| Given (kurulum) | When (eylem) | Expect | Got |
|---|---|---|---|
| User role: Editor; one record with Status=Draft | Click Save | Toast "Saved" + updated timestamp | Button shows spinner then stops; no change |
Repro'yu taşınabilir yapın ki başkası da hızlıca çalıştırsın:
En hızlı yol genellikle sıkıcıdır: bir şeyi değiştir, gözlemle, not al.
Yaygın hatalar:
Gerçekçi bir örnek: bir ticket "CSV dışa aktarım boş" diyor. Siz admin hesabıyla test edip veri görürsünüz. Kullanıcının kısıtlı bir rolü varmış ve API izin filtresi nedeniyle boş liste dönüyor. UI'yı sadece "Satır yok" diye yamalarsanız gerçek soru kaçırırsınız: o rolün dışa aktarmaya izin verilip verilmemesi mi yoksa ürünün neden filtrelediğini açıklaması mı gerekir?
Her düzeltmeden sonra aynı çoğaltımı yeniden çalıştırın, sonra etkilenebilecek bir yakın senaryoyu test edin.
Tek bir paket halinde: tekrar edilebilir adımlar, muhtemel başarısız katman ve kanıtla gelin; böylece ekipten daha iyi cevap alırsınız.
Kodu kimse değiştirmeden önce doğrulayın:
Sonra hızlı bir regresyon turu yapın: farklı bir rol, ikinci tarayıcı/gizli pencere, aynı endpoint/tabloyu kullanan yakın bir özellik ve bir uç durum girdisi (boş, uzun metin, özel karakterler).
Destek mesajı: "Düzenle Müşteri formunda Kaydet butonu hiçbir şey yapmıyor." Sonraki sorular, bunun sadece geçen aydan önce oluşturulmuş müşterilerde ve fatura e-postasını değiştirdiğinizde olduğunu ortaya çıkarır.
UI ile başlayın ve en basit hata varsayımıyla ilerleyin. Kaydı açın, düzenlemeyi yapın ve "hiçbir şey" aslında bir şey mi diye işaretlere bakın: devre dışı buton, gizlenmiş toast, render olmayan doğrulama mesajı. Ardından tarayıcı konsolunu ve Network sekmesini açın.
Burada Kaydet tıklaması bir isteği tetikliyor, ama frontend sadece 200'ü başarı kabul edip 400'leri yok saydığı için UI sonucu hiç göstermiyor. Network sekmesi 400 yanıtı ve şu şekil bir JSON gövdesi gösteriyor: {\\\"error\\\":\\\"billingEmail must be unique\\\"}.
Şimdi API'nin gerçekten başarısız olduğunu doğrulayın: isteğin tam payload'unu alın ve UI dışında yeniden çalıştırın. Eğer orada da başarısız oluyorsa frontend durum hatalarını takip etmeyi bırakın.
Sonra veritabanını kontrol edin: neden yalnızca eski kayıtlar için benzersizlik başarısız oluyor? Eski müşterilerin yıllar önce placeholder billing_email paylaştığını keşfedersiniz. Yeni bir benzersizlik kontrolü artık o placeholder'a sahip herhangi bir müşterinin kaydedilmesini engelliyor.
Bırakılabilecek minimal repro:
billing_email = [email protected] olan bir legacy müşteri seçin.billingEmail must be unique ile 400 döndürdüğünü gözlemleyin.Kabul testi: API bir doğrulama hatası döndürdüğünde UI mesajı gösterir, kullanıcının düzenlemelerini korur ve hatayı hangi alanın başarısız olduğu ile açıklar.
Hata çoğaltılabilir ve muhtemel katmanı belirledikten sonra, küçük ve güvenli bir yama üretecek şekilde yardım isteyin.
Basit bir "vaka dosyası" paketleyin: minimal repro adımları (girdiler, ortam, rol), beklenen vs gerçek, neden UI/API/DB olduğunu düşündüğünüz ve hatayı gösteren küçük log kesiti.
Sonra isteği daraltın:
Eğer Koder.ai (koder.ai) gibi bir vibe-coding platformu kullanıyorsanız, bu vaka-dosyası yaklaşımı öneriyi odaklı tutar. Snapshot ve rollback de küçük değişiklikleri güvenle test etmenize ve bilinen bir baseline'a dönmenize yardımcı olur.
Güvenlik, ödemeler, veri migration'ları veya üretim verisini bozabilecek her şey için deneyimli bir geliştiriciye devredin. Ayrıca değişiklik küçük bir yamadan büyümeye başlıyorsa ya da riski basitçe açıklayamıyorsanız devredin.
Bir hatayı tekrarlanabilir bir betiğe çevirerek başlayın: kim (rol), nerede (sayfa/akış), hangi kesin girdiler (ID'ler, filtreler, payload), beklenen sonuç ve gözlenen sonuç. Eksikse, uçtan uca aynı senaryoyu çalıştırmak için bir örnek hesap ve bir örnek kayıt ID'si isteyin.
Bir ortam seçin ve yeniden üreterek bitene kadar orada kalın. Ardından build/sürüm, feature flag'ler, konfigürasyon, test hesabı/rol ve kullandığınız kesin verileri kaydedin. Bu, raporlayanın kurulumuyla uyuşmayan bir ortamda “hatalı” görünmesini engeller.
Aynı adımlar ve girdilerle iki kez tekrarlayın, sonra gerek olmayan her şeyi çıkarın. Temiz başlangıçtan 3–6 adımla, yeniden kullanılabilir bir kayıt veya request body ile çalıştırılabilir olması hedeflensin. Küçültemiyorsanız bu genellikle veri hacmi, zamanlama veya arka plan işi bağımlılığı işaretidir.
Hiçbir şeyi değiştirmeyin. Önce raporlayanın adımlarını birebir çalıştırın ve deneyiminizin ilk farklılaştığı yeri not edin (farklı buton etiketi, eksik alan, farklı hata metni). O ilk uyuşmazlık çoğu zaman hatayı tetikleyen gerçek koşuldur.
Verinin gerçekten değişip değişmediğine bakın. API yeni değeri döndürüyorsa ama UI eskiyi gösteriyorsa sorun muhtemelen UI durumunda, önbelleklemede veya yeniden getirmede. API yanıtı yanlışsa veya kayıt hiç yapılmıyorsa API/DB üzerinde yoğunlaşın. DB satırı hiç güncellenmiyorsa (veya WHERE koşulu 0 satır etkiliyorsa) kalıcılık katmanındasınız demektir.
Butona tıkladığınızda bir ağ isteğinin gidip gitmediğini doğrulayın, sonra istek payload'u ve yanıt gövdesini inceleyin; sadece status koduna bakmayın. Loglarla eşleştirmek için zaman damgası (zaman dilimiyle) ve kullanıcı kimliği yakalayın. "Başarılı" bir 200'ün beklenmeyen bir gövde döndürmesi, 400/500 kadar önemlidir.
Birer defada bir şeyi değiştirin: rol, kayıt (yeni vs eski), tarayıcı/cihaz, temiz oturum (gizli pencere/önbellek temiz), ağ. Tek değişken testi hangi koşulun önemli olduğunu söyler ve aynı anda birden çok şeyi değiştirmenin yol açtığı tesadüfleri kovalar.
Aynı anda birden çok değişkeni değiştirmek, raporlayanın farklı bir ortamında test etmek ve roller/izinleri göz ardı etmek en büyük zaman kayıplarıdır. Bir diğer yaygın hata ise UI'daki yüzeysel semptomu düzeltip altta yatan API/DB doğrulama hatasını görmezden gelmektir. Değişiklikten sonra aynı çoğaltımı yeniden çalıştırın ve bir yakın senaryoyu test edin.
Orijinal minimal çoğaltımın artık geçtiği ve etkilenebilecek bir yakın akışın yeniden test edildiği durum "done" sayılır. Somut bir kontrol tutun: görünür bir başarı mesajı, doğru HTTP yanıtı veya beklenen DB satırı değişikliği gibi. "Sanırım düzeldi" demek yeterli değildir.
Sıkıştırılmış bir vaka dosyası verin: minimal adımlar ve kesin girdiler, ortam/sürüm/flag'ler, test hesabı ve rol, beklenen vs gerçekleşen ve bir kanıt parçası (istek/yanıt, hata metni veya zaman damgalı log snippet'i). Ardından en küçük yamayı isteyin ve küçük bir test planı ekleyin. Koder.ai kullanıyorsanız, bu vaka dosyası snapshot/rollback ile birlikte küçük değişiklikleri güvenle test etmeyi kolaylaştırır.