Bir UI Hatasının Aslında Sistem Hatası Olduğunu Nasıl Anlarsın?

Canlı üründe en tehlikeli cümlelerden biri şudur:

“Şurada küçük bir UI bug’ı var.”

Bazen gerçekten küçüktür.

Padding yanlıştır. Buton taşmıştır. Breakpoint eksiktir.

Ama bazen kullanıcının gördüğü semptom sadece sistemdeki daha derin bir problemin son halkasıdır.

Bir not satırında yanlış action görünmesi, bir modalın eski veriyi açması veya geri tuşunun beklenmedik yere gitmesi yalnızca component problemi olmayabilir.

İlk ayrım: yanlış görünüyor mu, yanlış biliyor mu?

Ben önce şu ayrımı yaparım.

Eğer sistem doğru state’e sahip ve onu yanlış render ediyorsa UI problemine yakınızdır.

Eğer component kendisine yanlış state geliyorsa artık daha yukarı bakmak gerekir.

Örneğin:

• yanlış entity seçili,
• eski cache hydrate edilmiş,
• optimistic state geri alınmamış,
• aynı veriyi iki writer güncelliyor,
• mobil lifecycle sonrası stale state restore edilmiş,
• route state ile domain state farklı gerçeklik taşıyor.

Bu durumda butonu düzeltmek yalnızca semptomu gizleyebilir.

Aynı bug farklı ekranlarda çıkıyorsa shared cause ara

Bir problem birden fazla yüzeyde tekrar ediyorsa tek tek ekran yamalamak son seçeneğimdir.

Önce ortak noktaları ararım:

• shared component,
• shared hook,
• canonical data source,
• event bus,
• query key,
• hydration,
• permission rule,
• route model,
• platform wrapper,
• breakpoint token.

Çünkü aynı hata üç farklı ekranda varsa üç ayrı tesadüf olma ihtimali, tek shared root cause olma ihtimalinden genellikle düşüktür.

UI neden sistem problemini saklar?

Çünkü kullanıcı yalnızca son katmanı görür.

Bir not kartına tıklıyor ve yanlış action açılıyor.

Kullanıcı için sorun karttır.

Sistem açısından zincir şöyle olabilir:

User tap → gesture handler → selected item state → mobile row mode → domain action mapping → route transition → persisted UI state → lifecycle restore

Hata zincirin herhangi bir yerinde olabilir.

Bu yüzden production debugging’de “ekranda neresi yanlış?” sorusu başlangıçtır; teşhis değildir.

Root-cause tree kullanıyorum

Ben problemi şu ağaca ayırmayı tercih ederim:

Render Component yanlış mı çiziliyor?

Interaction Click/tap/keyboard/back gesture yanlış event mi üretiyor?

State Doğru state’e mi bakıyoruz?

Domain State’in anlamı doğru mu?

Persistence Eski state geri mi geliyor?

Synchronization Cloud/local/client arasında yarış var mı?

Platform Android, browser veya desktop lifecycle farklı mı?

Release Düzelttiğim kod gerçekten canlı mı?

Bu sıra her problem için mekanik uygulanmaz. Ama kör patch döngüsünü kırar.

En önemli sinyal: patch geri geliyor

Bir UI hatasını düzelttiniz.

Bir gün sonra başka akışta yeniden çıktı.

İkinci patch yapıldı.

Başka platformda geri geldi.

Burada üçüncü kez CSS veya component state’iyle oynamak doğru davranış değildir.

Bu, problem tanımının yanlış olduğuna dair güçlü kanıttır.

İki başarısız patch sonrası aynı varsayımla üçüncü patch atmak yerine yeniden teşhis gerekir.

Release farkını UI bug sanmak

Bir başka klasik durum: kod doğru, production yanlış.

Developer local’de yeni UI’ı görüyor. PR merge edilmiş. CI yeşil.

Ama kullanıcı hâlâ eski davranışı görüyor.

Bu durumda component’i yeniden yazmak saçmadır.

Kontrol edilmesi gerekenler:

• doğru branch deploy edildi mi,
• Cloudflare hangi commit’i taşıyor,
• output artifact güncel mi,
• custom domain doğru deployment’a mı bağlı,
• cache veya service worker eski asset mi veriyor,
• build identity canlı kodla eşleşiyor mu?

Production gerçeği doğrulanmadan UI debugging tamamlanmış sayılmaz.

Bir bug ne zaman architecture debt sinyalidir?

Şu durumlarda bug’ı lokal kabul etmem:

• aynı entity için iki state kaynağı varsa,
• component domain kararını kendisi veriyorsa,
• farklı platformlar aynı davranışı ayrı ayrı implemente ediyorsa,
• hydration canonical state’i koşulsuz overwrite ediyorsa,
• cache ile persistence rolü belirsizse,
• UI state’i kalıcı business state gibi kullanılıyorsa,
• destructive action davranışı tek yerde tanımlı değilse.

Bu işaretler varsa çözüm çoğu zaman bir buton değil, ownership düzeltmesidir.

Sonuç

Frontend’de görünen hata frontend’e ait olmak zorunda değil.

İyi debugging semptomu hızlı kapatmak değildir. Problemin hangi katmanda doğduğunu ispatlamaktır.

Ben canlı üründe önce “hangi component bozuk?” diye değil, “hangi gerçeklik yanlış?” diye bakıyorum.

Çünkü UI son katmandır.

Sistem doğru değilse iyi çizilmiş ekran sadece yanlış gerçeği daha güzel gösterir.