Spring Boot Statik Analizörü Neden Veritabanı Çağrılarını Kaçırıyor

Bir mühendis, Spring Boot uygulamalarında bir endpoint değiştirildiğinde etkisinin nereye ulaştığını bulan bir statik analiz aracı geliştirirken, aracın en ciddi hatalarının hep aynı biçimde ortaya çıktığını fark etti: veritabanı işlemi, transaction veya mesaj yayını olmadığını 'kesin' şekilde bildiren yanlış negatifler. Sorunun kökü, Spring'in kaynak kodda görünür şekilde çağrılmayan kodu çalıştırmasıydı — handler'dan başlayıp çağrıları takip eden klasik kod inceleme yaklaşımı bu kısımları kaçırıyordu.

Gerçek dünya projelerinde ölçülen bulgular çarpıcı: interface tabanlı mapping'ler (OpenAPI generator veya paylaşılan API sözleşmeleri) yüzünden endpoint'ler annotation taramasıyla bulunamıyor; fonksiyonel routing (RouterFunctions) tamamen görünmez kalıyor; @ModelAttribute metodları her handler'dan önce çalıştığı için çağrı grafiğinde hiç yer almıyor; Spring Data'nın türetilmiş metodları (save, findById) hiçbir kaynak dosyada bulunmuyor; sınıf seviyesindeki @Transactional metod bazlı taramada görünmüyor ve araç zaten var olan transaction'ı 'eklenmesi gereken' bir öneri olarak sunuyor.

Uygulama olayları (@EventListener), executor'lara devredilen işler ve mesajlaşma sınırları (SQS, RabbitMQ) da benzer kör noktalar yaratıyor: kuyruk adları farklı biçimlerde yazılabiliyor, annotation'sız consumer'lar taramadan kaçıyor, RabbitMQ'da exchange/routing key eşleşmesi hedef string üzerinden yapılamıyor. Ayrıca JPQL'in SQL gibi okunması FETCH gibi anahtar kelimeleri tablo adı sanma gibi hatalara yol açıyor.

Bu bulgular, kod inceleme yapan mühendisler için de bir uyarı: statik analiz araçları veya insan gözüyle yapılan pull request incelemeleri, Spring'in çerçeve düzeyinde çalıştırdığı örtük davranışları (interface mapping, class-level transaction, event listener'lar) gözden kaçırabilir. 'Bulunamadı' ifadesi çoğu zaman aracın eksikliğidir, kodun eksikliği değil.