Statik analiz araçlarını kuran çoğu ekip, hazır kural paketini kurup çalıştırdıktan sonra "artık kod kalitemiz kontrol altında" diye düşünür. Bir süre sonra fark edilen şey genellikle şudur: araç binlerce stil uyarısı üretiyor ama ekibin asıl canını yakan, projeye özgü hatalar hâlâ üretime sızıyor. Bunun nedeni basit; hazır kural setleri genel geçer sorunlar için tasarlanmıştır, sizin kod tabanınızın kendine özgü alışkanlıkları, mimarisi ve zayıf noktaları için değil. Bu yazı, kendi kural setinizi nasıl oluşturacağınızı adım adım ele alıyor.
Bir bakışta
- Statik analiz araçlarının hazır kural setleri genel sorunları yakalar, ancak projeye özgü hataları ve şirkete ait standartları tespit edemez.
- Kural yazarken geçmiş hata kayıtları, code review yorumları ve ekip tartışmalarından yola çıkarak gerçek sorunları belirlemek gerekir.
- Kurallar stil, mantıksal hata ve güvenlik kategorilerine ayrılmalı; her biri farklı ciddiyet seviyesi ile CI/CD sürecinde uygulanmalıdır.
Hazır Kural Setleri Neden Her Zaman Yetmez?
Genel amaçlı statik analiz araçları, geniş bir geliştirici kitlesinde sık rastlanan hataları hedefleyecek şekilde tasarlanır: kullanılmayan değişkenler, bariz null referans riskleri, yaygın güvenlik açığı kalıpları gibi. Bu kurallar faydalıdır ama projenizin özgül bağlamına kördür.
Örneğin şirket içi kodlama standartlarınız olabilir: belirli bir isimlendirme deseni, katmanlar arası bağımlılık sınırları (örneğin veri erişim katmanının doğrudan arayüz katmanından çağrılmaması gibi) ya da belirli modüllerin birbirine import edilmemesi gerektiği gibi kurallar. Bunlar hiçbir genel kural setinde yer almaz çünkü bunlar sizin organizasyonunuza özgüdür.
Aynı şekilde özel güvenlik politikaları da hazır kurallarla yakalanamaz. Diyelim ki şirket içinde geliştirilmiş bir kriptografi yardımcı kütüphaneniz var ve bu kütüphanenin belirli bir fonksiyonunun yanlış parametrelerle çağrılması güvenlik açığı yaratıyor. Genel bir statik analiz aracı bu iç kütüphaneyi tanımaz, dolayısıyla bu riski göremez.
Framework'e özgü anti-pattern'ler de benzer bir kör nokta oluşturur. Kullandığınız bir state yönetim kütüphanesinin belirli bir yanlış kullanım şekli performans sorununa yol açıyor olabilir; bu, o framework'e has bir durumdur ve genel kural setlerinin kapsamı dışındadır.
Son olarak, her ekibin kendi tecrübesinden süzülen "bizde sık tekrarlanan hata" kalıpları vardır. Bu kalıpları sistematik ve otomatik şekilde yakalamanın tek yolu, onları açıkça kurala dönüştürmektir.
İlk Adım: Kod Tabanında Tekrar Eden Sorunları Tespit Etmek
Kural yazmaya doğrudan oturmak, çoğu zaman gereksiz veya isabetsiz kurallarla sonuçlanır. Bunun yerine önce veriye bakmak gerekir. Geçmiş hata kayıtları, code review yorumları ve varsa post-mortem (olay sonrası inceleme) belgeleri, kural adaylarının en zengin kaynağıdır.
Burada aranan sinyal şudur: aynı türde bir hata, farklı zamanlarda farklı geliştiriciler tarafından tekrar tekrar yapılıyor mu? Eğer bir code review'da sürekli "bu kaynak neden kapatılmamış" ya da "bu fonksiyon her çağrıldığında aynı hatayı yapıyoruz" gibi yorumlar tekrarlanıyorsa, bu güçlü bir kural adayıdır — çünkü insan gözüyle her seferinde yakalamak yerine otomatikleştirmek daha verimlidir.
Bu süreci yalnızca geçmiş kayıtlara bakarak değil, ekip içi kısa bir tartışma veya anket ile de besleyebilirsiniz. "Otomatik yakalamak isterdik" listesi oluşturmak, geliştiricilerin günlük iş akışında neyin tekrar eden bir sorun olduğunu en iyi onların kendisi bilir.
Bu aşamada önemli bir ayrım var: sık görülen ama düşük riskli sorunlarla, nadir görülen ama yüksek riskli sorunlar aynı şekilde ele alınmamalı. Örneğin bir isimlendirme tutarsızlığı sık görülür ama düşük risklidir; buna karşılık nadiren karşılaşılan ama veri sızıntısına yol açabilecek bir kalıp, az görülse bile öncelikli olarak kurala dönüştürülmelidir.
AST Mantığını Temel Düzeyde Anlamak Neden İşe Yarar?
Statik analiz araçları kodu düz metin olarak değil, Soyut Sözdizimi Ağacı (AST – Abstract Syntax Tree) adı verilen yapılandırılmış bir ağaç olarak işler. Kodunuzdaki her ifade, fonksiyon çağrısı, değişken tanımı ya da import satırı, bu ağaçta bir düğüme karşılık gelir.
Bir kural yazmak, aslında bu ağaç üzerinde belirli bir düğüm desenini aramaktır. "Belirli bir fonksiyonun şu parametreyle çağrılması" ya da "belirli bir modülün import edilmesi" gibi durumlar, ağaç üzerinde tanımlanabilir desenlerdir. Metin üzerinde arama yapmak (örneğin basit bir string eşleştirme) yüzeysel kalır ve kolayca yanlış sonuç üretir; AST tabanlı arama ise kodun gerçek yapısal anlamını dikkate alır.
Bazı araçlarda basit desen eşleştirmeyle de (AST bilmeden) kural yazmak mümkündür ve basit durumlar için bu yeterlidir. Ancak kural karmaşıklaştıkça — örneğin "bu fonksiyon çağrısı yalnızca belirli bir koşul bloğunun içindeyse hata say" gibi bağlama duyarlı kurallarda — AST mantığını bilmek, yanlış pozitif oranını belirgin şekilde azaltır.
Pratik bir ilk adım olarak, kullandığınız dilin bir AST görselleştirme aracında kendi kod örneklerinizi incelemeyi deneyebilirsiniz. Bu, "yakalamak istediğim kalıp ağaçta nasıl görünür" sorusuna somut bir cevap verir ve kural yazımını kolaylaştırır.
Kuralların Kapsamını Doğru Belirlemek: Hangi Kategori Hangi Amaca Hizmet Eder?
Her yeni kural aynı kategoriye ait değildir ve bu kategorileri ayırt etmemek, kural setinin zamanla karmaşıklaşıp etkisiz hale gelmesine yol açar.
Stil/biçim kuralları — girinti, satır uzunluğu, isimlendirme kuralları gibi — daha çok tutarlılık sağlar. Bu kurallar genellikle düşük risk taşır; ihlal edilmeleri çalışan kodu bozmaz, sadece okunabilirliği etkiler.
Mantıksal hata tespiti kuralları — kullanılmayan değişken, erişilemeyen kod bloğu, eksik null kontrolü gibi — daha derin bir analiz gerektirir ve genellikle gerçek hatalara işaret eder.
Güvenlik açığı taraması kuralları — tehlikeli fonksiyon kullanımı, sabit kodlanmış kimlik bilgileri, güvensiz veri akışı gibi — genellikle en yüksek önceliğe sahip olmalıdır, çünkü bu tür ihlallerin sonucu doğrudan bir güvenlik olayı olabilir.
Bu üç kategoriyi birbirinden ayırmanın pratik faydası, her birine farklı bir ciddiyet seviyesi (uyarı, hata, engelleyici) atayabilmenizdir. Böylece CI/CD sürecinde stil kuralı ihlali sadece bilgilendirme amaçlı kalırken, bir güvenlik kuralı ihlali build'i tamamen durdurabilir.
Yeni Kuralı Test Etmek: Yanlış Pozitifleri Azaltma Süreci
Yazdığınız bir kuralı doğrudan tüm kod tabanına uygulamak risklidir. Önce küçük, temsili bir kod örneği üzerinde denemek gerekir.
Burada iki temel kavram devreye girer: yanlış pozitif, kuralın gerçekte sorunlu olmayan bir kodu hatalı olarak işaretlemesidir. Yanlış negatif ise kuralın yakalaması gereken gerçek bir sorunu kaçırmasıdır. İkisi de kuralın güvenilirliğini zedeler, ama pratikte yanlış pozitifler daha hızlı güven kaybına yol açar.
Bir kuralı test ederken hem "bu kuralın yakalaması gereken" hem de "yakalamaması gereken" örnek kod parçacıkları hazırlamak faydalıdır. Bu iki küme üzerinde kuralı çalıştırıp sonuçları karşılaştırmak, kuralın gerçekten hedeflediği deseni doğru ayırt edip etmediğini gösterir.
Yüksek yanlış pozitif oranı taşıyan bir kural, zamanla geliştiricilerin aracı görmezden gelmesine yol açar — "nasılsa yanlış alarm veriyor" düşüncesi yerleştiğinde, gerçek bir uyarı da gözden kaçabilir. Bu yüzden yeni bir kuralı kademeli olarak devreye almak pratik bir yöntemdir: önce sadece uyarı seviyesinde bırakıp bir süre izlemek, gerçek dünya verisiyle doğrulandıktan sonra zorunlu (engelleyici) hale getirmek.
Kural Setini Ekiple Paylaşmak ve Sürüm Kontrolüne Dahil Etmek
Özel kural tanımları da tıpkı kaynak kod gibi ele alınmalı ve bir Git benzeri sürüm kontrol sistemine dahil edilmelidir. Bu, kural değişikliklerinin izlenebilir olmasını, gerektiğinde eski bir sürüme dönülebilmesini ve kimin ne zaman hangi kuralı eklediğinin kayıt altında kalmasını sağlar.
Kural değişikliklerinin de normal bir code review sürecinden geçmesi önemlidir. Bir kuralın kapsamını genişletmek ya da sertleştirmek, kod tabanının genelini etkileyebilir; bu yüzden bu değişiklikler de gözden geçirilmeli, tek bir kişinin inisiyatifine bırakılmamalıdır.
Her kuralın yanına kısa bir açıklama eklemek — neden var olduğu, hangi sorunu önlemeyi amaçladığı — ekip içi benimsemeyi kolaylaştırır. Bir geliştirici bir kuralla karşılaştığında, sadece "bu satır hatalı" uyarısını değil, arkasındaki gerekçeyi de görebilmelidir.
Zamanla projenin ihtiyaçları değişir. Belirli bir anti-pattern artık kullanılmıyor olabilir, ya da ekip farklı bir mimariye geçmiş olabilir. Bu durumda gereksiz hale gelen kuralların kaldırılması ya da güncellenmesi, kural setinin canlı ve işlevsel kalması için gereklidir.
Özel Kuralları CI/CD Sürecine Entegre Etmenin Genel Mantığı
Kurallar farklı aşamalarda çalıştırılabilir: yerel geliştirme ortamında (örneğin commit öncesi bir kontrol olarak) ya da CI pipeline'ında (kod birleştirilmeden önce otomatik olarak).
Burada daha önce bahsedilen ciddiyet ayrımı devreye girer: kritik bir güvenlik kuralının ihlali build'i durdurmalı, buna karşılık bir stil kuralının ihlali sadece bilgilendirme amaçlı kalabilir ve geliştiriciyi engellemeden ilerlemesine izin verebilir.
Bu entegrasyonun temel faydası, hataların üretime ulaşmadan, mümkün olduğunca erken aşamada yakalanmasıdır. Bir geliştirici kodu commit etmeden önce bir sorunu görürse, bu sorunu düzeltmenin maliyeti, aynı sorun üretimde fark edildiğinde düzeltmenin maliyetinden çok daha düşüktür.
Ancak eklenen her yeni kuralın pipeline üzerindeki zaman maliyetini de göz önünde bulundurmak gerekir. Çok fazla kuralın her commit'te çalıştırılması, build sürelerini uzatabilir ve bu da dolaylı olarak geliştirici verimliliğini etkiler.
Denge Meselesi: Aşırı Katı Kural Setlerinin Bedeli
Kural setini genişletmek kolaydır, ama her yeni kural bir bedel getirir. Çok fazla sayıda veya aşırı katı kurallar, geliştiricilerde yorgunluk yaratır ve zamanla "aracı atlatma" eğilimine yol açabilir — örneğin kuralı devre dışı bırakan satır içi yorumların gereksiz yere çoğalması gibi.
Bu riskten kaçınmanın temel yolu, her kuralın gerçek bir riski ya da gerçekten tekrar eden bir sorunu hedeflemesini sağlamaktır. "Bu da olabilir, ekleyelim" mantığıyla eklenen kurallar, zamanla kural setini gürültülü ve güvenilmez hale getirir.
Düzenli bir geri bildirim döngüsü kurmak faydalıdır: hangi kuralların gerçekten değer kattığı, hangilerinin sadece gürültü ürettiği periyodik olarak değerlendirilmelidir. Bu değerlendirme, ekip üyelerinin günlük deneyimine dayanmalıdır.
Esneklik de kural setinin bir parçası olmalıdır. Çoğu statik analiz aracı, belirli bir satır ya da bloğu makul bir gerekçeyle kuraldan muaf tutma mekanizması sunar. Bu mekanizmanın varlığı, kuralın her durumda mutlak olarak uygulanması gerektiği anlamına gelmez — makul istisnalar, kural setinin pratikte sürdürülebilir olmasını sağlar.
Sonuç Yerine: Genel Prensipler Araçtan Bağımsızdır
Bu yazıda anlatılan süreç — tekrar eden sorunları tespit etmek, kuralın kapsamını doğru kategoriye yerleştirmek, test etmek, sürüm kontrolüne dahil etmek, CI/CD'ye entegre etmek ve dengeyi gözetmek — kullandığınız spesifik statik analiz aracından bağımsızdır. Farklı araçların kural yazım sözdizimi birbirinden oldukça farklı olabilir; biri belirli bir sorgu dili kullanırken, bir diğeri yapılandırma dosyası tabanlı bir yaklaşım benimseyebilir.
Kendi aracınızın dokümantasyonuna bakarak burada anlatılan genel süreci kendi sözdiziminize uyarlamanız gerekecektir. Ancak altta yatan mantık — neyi, neden ve nasıl kural haline getirdiğiniz — değişmez.
Son olarak unutulmaması gereken nokta şudur: özel kural seti oluşturmak bir kerede tamamlanıp kapatılan bir proje değildir. Kod tabanınız evrildikçe, mimariniz değiştikçe ve ekibiniz yeni deneyimler edindikçe, kural setiniz de bu sürece paralel olarak güncellenmesi gereken sürekli bir pratiktir.
