Java tarafında kod kalitesinden söz açılınca çoğu ekip eninde sonunda aynı soruya geliyor: “Hangi aracı seçelim?” Ben de ilk duyduğumda net bir cevap bekliyordum. Ama işin aslı şu — SonarQube ile PMD aynı kulvarda koşmuyor zaten. Biri etraflı bir kontrol merkezi gibi, diğeri elindeki kurallarla kodu didik didik eden, hafif ve hızlı bir denetçi gibi çalışıyor.
Geçen yıl, 2025 Şubat’ta İstanbul’daki bir fintech ekibiyle görüşmem oldu. Bunu çok net gördüm orada. Takım önce “tek araçla işi kapatalım” diyordu, pipeline’a bakınca tablo bayağı değişti: hızlı build içi uyarılar için PMD gayet iş görüyordu, kurumsal görünürlük ve kalite kapıları içinse SonarQube ayrı bir değer katıyordu. Yani mesele sadece “hangisi iyi?” değil — hangi aşamada neye ihtiyacın var, asıl soru bu.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
İşin özeti: rakip değiller, farklı seviyeler
Açık konuşayım — bu ikisini doğrudan rakip diye görmek biraz yanıltıcı (inanın bana). PMD ile başladığınızda elinizde basit ama etkili bir mekanizma oluyor. Java kaynak dosyalarını tarıyorsun, kuralları veriyorsun, o da ihlalleri döküyor (en azından benim deneyimim böyle). Ne sunucu derdi var ne hesap açma telaşı. İdare eder mi? Eder. Hatta küçük ekiplerde bayağı rahat ettirir.
SonarQube tarafında hikâye çok daha geniş. Burada sadece kural ihlali yok; kalite kapısı var, geçmişe dönük trend var, tekrar eden kod var, coverage var, teknik borç tahmini var (ben de ilk duyduğumda şaşırmıştım). Bir de güvenlik boyutu girince iş ciddileşiyor zaten. Ben 2024 Kasım’ında Ankara’da bir SaaS projesinde bunu test ettiğimde şunu fark ettim: ekip PMD çıktısını görüp düzeltme yapıyordu ama yöneticiler “genel sağlık durumu ne?” sorusuna ancak SonarQube ekranından cevap bulabiliyordu. İki farklı ihtiyaç. İki farklı araç.
PMD neyi iyi yapıyor?
Bak şimdi, PMD’nin olayı yalınlık. Nokta. Maven ya da Gradle’a eklersin, kurallarını XML içinde tutarsın ve build sırasında raporu alırsın — bu kadar. Bu netlik güzel çünkü geliştirici akışını fazla bölmüyor, hani bir baktın uyarı var, düzelttim, devam… Hele bir de Java odaklı ekiplerde naming convention, karmaşıklık veya kullanılmayan kod gibi konularda bayağı iş görüyor, bunu teslim etmek lazım.
Bunu biraz açayım.
Bunu yaşayan biri olarak söyleyeyim, Ha, bu arada önemli bir artısı da şu: konfigürasyon tamamen repo içinde yaşıyor, yani “kim hangi ayarı yaptı, neden değişti?” sorusu ortadan kalkıyor. Küçük startup’lar için bu ciddi rahatlık. Kurumsal tarafta da belirli standartları sabitlemek isteyen ekipler bundan hoşlanıyor — beklediğimden daha sık görüyorum aslında bunu. Ugreen’in Yeni 3 Portlu GaN Şarjı: Küçük Gövde, Büyük İş yazımızda bu konuya da değinmiştik.
# Örnek PMD yaklaşımı
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>pmd-maven-plugin</artifactId>
<version>3.x.x</version>
</plugin>SonarQube neden daha kapsamlı hissettiriyor?
SonarQube’un gücü tek başına Java analizinde değil — büyük çoğunluk resmi aynı ekranda toplamasında. PR üzerine yorum bırakabildiği sürümlerde geliştirici deneyimi iyice oturuyor. Quality gate dediği şey de boş laf değil; belli eşikleri geçmeyen kodu gerçekten geri çevirebiliyor. Denemediyseniz ilk kez gördüğünüzde biraz şaşırıyorsunuz açıkçası. Bu konuyla ilgili Chrome’da Garip Üçlü: Sekme, Wii ve CyberDeck yazımıza da göz atmanızı tavsiye ederim.
Beni en çok etkileyen taraf tarihsel görünüm oldu. Bir ekipte 2025 Mart ayında yaptığımız denemede teknik borcun hafta hafta nasıl azaldığını görmek — normalde kalite ekranlarına pek bakmayan yöneticiyi bile ikna etti bu (şaşırtıcı ama gerçek). İşte burada SonarQube biraz kontrol kulesi gibi davranıyor; tek sensör değil, uçuşun tamamını izleyen sistem.
| Kriter | SonarQube | PMD |
|---|---|---|
| Tür | Kod kalitesi ve güvenlik platformu | Kural tabanlı statik analiz aracı |
| Kapsam | Çok dilli destek + dashboard + trend + quality gate | Daha dar ama hızlı Java odaklı kontrol |
| Kullanım yeri | CI/CD ve merkezi kalite yönetimi | Maven/Gradle build içi denetim |
| Ekip ölçeği | Büyüyen ve kurumsal ekipler için güçlü | Küçük/orta Java ekiplerinde çok pratik |
| Maliyet / altyapı yükü | Daha yüksek olabilir | Düşük / hafif |
Nerede hangisi daha mantıklı?
Küçük bir startup düşünelim. Ürün yeni çıkmış, iki backend geliştirici var, herkes hız peşinde koşuyor. Böyle bir yerde PMD tam biçilmiş kaftan olabilir — kurulumu kolaydır, pipeline’ı ağırlaştırmaz, kodun sessizce kötüleşmesini engeller… Bildirim gelir, herkes düzeltir, devam. Yeterli mi? Çoğu zaman yeterli.
İnanın, Eğer orta ölçekli ya da enterprise taraftaysan tablo değişiyor. Burada yalnızca “kod temiz mi?” demek yetmez; — ki bu tartışılır — hangi takımda hangi problem sık yaşanıyor, regresyon nerede artmış, güvenlik açıkları nereden sızıyor… bunların hepsini görmek istersin. SonarQube burada öne çıkıyor çünkü merkezileştirme sağlıyor. Tek ekrandan bakıp durumu anlıyorsun.
Neyse uzatmayayım — ben pratikte çoğu olgun Java ekibinin iki aracı birlikte kullandığını görüyorum. Build içinde PMD veya SpotBugs hızlı uyarı veriyor; CI tarafında SonarQube üst seviye kalite kapısı olarak devreye giriyor. Bu kombinasyon ilk bakışta fazla geliyor, ama alışınca oldukça temiz çalışıyor. Gerçekten. Pixel Boyutunda Kandırmaca: SVG İçine Saklanan Hırsızlık yazımızda bu konuya da değinmiştik. Mülakatta Çaktırılan 7 Yazılımcı Hatası: Kaçın yazımızda da bu konuya değinmiştik. Bir Haftada AI Fatura Üreticisi: Hızlı SaaS Dersi yazımızda da bu konuya değinmiştik.
Sadece PMD yeter mi?
Evet. Ama sadece belirli senaryolarda. Eğer amacın ucuz, hızlı ve doğrudan build içine gömülen kural kontrolüyse PMD gayet yeterli olabilir. Fakat organizasyon genelinde görünürlük istiyorsan eksik kalır.
Hani, Sadece PMD ile ilerleyen takımların en sık yaşadığı sorun şu oluyor: rapor var ama bağlam az. Yani yüz tane ihlal görüyorsun, tamam, düzeltiyorsun —. Bunun haftalık eğilimini ya da hangi modülün patladığını kolayca anlayamıyorsun. Bir süre sonra JSON log okur gibi rapor okumaya başlıyorsun. Yorucu biraz, evet.
Peki birlikte kullanmak saçma mı?
Tam tersine. Çoğu zaman en akıllıca hamle o oluyor. Birbirini tekrar ediyor gibi görünseler de farklı katmanlarda değer üretiyorlar — PMD’nin verdiği erken geri bildirim ile SonarQube’un sunduğu merkezi yönetim birleşince ekip içi disiplin bariz şekilde toparlanabiliyor (bizzat test ettim)
Burada, bunu yaşayan biri olarak söyleyeyim, Ben bunu ilk kez 2023 Eylül’ünde İzmir’deki bir e-ticaret projesinde gördüm. Takım önce yalnızca SonarQube kullanıyordu fakat bazı stil hataları geliştirme aşamasında geç yakalanıyordu. Sonra build içine PMD eklendi. Sonuç? PR tartışmaları azaldı — sorunlar zaten compile aşamasına yakın noktada yakalanmaya başladı. Kimse birbirini PR’da “şu import niye burada?” diye sorgulamıyordu artık.
- PMD avantajı: hafiflik ve hız.
- SonarQube avantajı: merkezi yönetim ve trend takibi.
- Beraber kullanım: hem anlık hem stratejik kalite kontrolü.
Burada gözden kaçırılmaması gereken pratik noktalar
Peki nelere bakmalı? İlk nokta rule set yönetimi. PMD’de fazla agresif kurallar koyarsanız geliştiriciler kısa sürede bıkabilir — bunu gördüm, yaşadım. En çok da de legacy kod tabanı olan projelerde önce temel hataları çözmek daha doğru olur: kullanılmayan importlar, basit complexity sorunları, bariz anti-pattern’ler… Oradan başlayın, azar azar büyütün.
İkinci nokta false positive konusu. Her araç bunlara açık olabilir, bu kaçınılmaz. Ama team workflow doğru tasarlanırsa rahatsızlık azalır. Ben genelde küçük ekiplere şunu söylüyorum: “Önce kritik kuralları açın, sonra gürültüyü azaltın.” Bu cümle havalı durduğu için değil — gerçekten işe yaradığı için söylüyorum.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
