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 merkezî 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.
İşin özeti: rakip değiller, farklı seviyeler
Açık konuşayım — bu ikisini doğrudan rakip diye görmek biraz yaniltı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’nın 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 bolmuyor, 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 resmî 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 merkezî 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’nın verdiği erken geri bildirim ile SonarQube’un sunduğu merkezî 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ı: merkezî 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 ölür: 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.
Sıkça Sorulan Sorular
SonarQube ile PMD aynı şey mi?
Hayır, aynı kategoride değiller. PMD daha çok kurallara dayalı statik analiz yapıp kodu “kurala aykırı” diye hızlıca yakalar. SonarQube ise kalite kapıları, teknik borç, güvenlik ve trend gibi daha geniş bir görünüm sağlar. Ben ikisini birlikte kullandığım projelerde “geliştirici düzeltmeleri” için PMD, “yönetim raporu ve kapı” için SonarQube daha net ayrıştı.
PMD’yi pipeline’a koymak mantıklı mı?
Evet, özellikle hızlı geri bildirim istediğinizde çok işe yarıyor. Build sırasında tarama yapınca geliştirici hatayı erken görüp düzeltmeye odaklanıyor. Küçük ekiplerde sunucu kurulum derdi olmadan da ciddi fayda alınabiliyor. Benim deneyimde “PR başına hızlı uyarı” hedefiyle PMD çok iyi çalıştı.
SonarQube hangi konularda daha güçlü?
SonarQube; kod kalitesi, güvenlik, teknik borç ve geçmişe dönük trend takibini tek yerde toplar. Ayrıca “Quality Gate” mantığıyla ekiplerin belirli seviyeleri tutturmasını sağlar. Yani sadece tekil hata yakalamak değil, zaman içinde iyileşmeyi ölçmek için daha uygun.
Java’da teknik borç ve tekrar eden kodu hangi araç daha iyi gösterir?
Bu tarz metrikleri yönetmek için SonarQube daha doğru adres. Tekrarlı kod, maintainability/complexity gibi göstergeler ve teknik borç tahminleri SonarQube ekranında daha anlamlı bir hikâye oluşturuyor. PMD ise daha çok “şu satır/şu kural ihlali” şeklinde aksiyon odaklı kalıyor.
İkisini birlikte kullanırsam çakışma olur mu?
Genelde çakışma yaşanmaz; rol paylaşımı yapınca daha verimli olur. PMD’yi PR/CI aşamasında hızlı düzeltme için, SonarQube’yi ise kalite kapısı ve yönetim görünürlüğü için konumlandırmak iyi bir pratik. Ben böyle ayırınca ekiplerin “hangi ekranda karar veriyoruz?” karmaşası azaldı.
Kaynaklar ve İleri Okuma
SonarQube: Analyze source code (resmi dokümantasyon)
SonarQube: Quality Gates (resmi dokümantasyon)
PMD: Ruleset Reference (resmi PMD dokümanları)
PMD GitHub (resmi repo ve dokümanlar)
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.
