Bir yazılım ekibini yönetenlerin çoğu, git blame komutunu genelde bir sorunu araştırırken kullanır: bu satırı kim yazmış, hangi commit'te değişmiş. Ancak bu komutun ismi ("blame" yani suçlamak), aracın gerçek potansiyelini gölgede bırakıyor. Doğru kullanıldığında blame verisi; bilgi dağılımını, bakım risklerini ve ekip içi bağımlılıkları görünür kılan bir yönetim aracına dönüşebilir. Bu yazıda blame analizinin bireysel değerlendirme aracı olmaktan çıkıp ekip sağlığını izleyen bir mekanizmaya nasıl dönüştürülebileceğini ele alıyoruz.
Bir bakışta
- Blame verisi, bireyi suçlamak yerine ekipteki bilgi dağılımını ve bus factor riskini gösteren bir yönetim aracıdır.
- Yüksek churn oranına sahip ve dar sahiplik dağılımı olan dosyalar, code review önceliklendirmesinde dikkat gerektirir.
- Blame geçmişi, onboarding sürecinde yeni geliştiricilere kime danışabileceklerini gösteren pratik bir rehber sunar.
Blame Analizi Nedir ve Neyi Ölçer
git blame teknik olarak bir dosyadaki her satırın en son hangi commit ile değiştirildiğini ve bu değişikliği kimin yaptığını gösterir. Yani ortaya çıkan çıktı, "bu satırı kim yazdı" sorusunun düz bir cevabıdır.
Ancak bu soru aslında daha ilginç bir sorunun kapısıdır: "Bu satır neden böyle yazıldı?" Bir fonksiyonun neden garip bir şekilde dallandığını, bir kontrolün neden orada durduğunu anlamak için önce kimin yazdığını bilmek gerekir; sonra o kişiye ya da commit mesajına, ilgili pull request tartışmasına başvurulabilir.
Burada önemli bir uyarı var: blame çıktısı, commit mesajı ve bağlam olmadan okunduğunda yanıltıcı olabilir. Bir satırın en son değiştiği tarih, o kodun "kim tarafından tasarlandığı" anlamına gelmez — belki sadece bir değişken adı yeniden düzenlenmiştir, belki bir formatlama commit'i araya girmiştir. Bu yüzden blame'i tek başına bir sayı ya da isim olarak değil, bir araştırmanın başlangıç noktası olarak görmek gerekir.
Suçlama Aracından Yönetim Aracına Geçiş
Aracın adı ("blame") maalesef kullanım kültürünü de şekillendiriyor. Bir hata bulunduğunda "kimin blame'i çıkıyor" diye sorulması, ekipte savunmacı bir refleks yaratabilir. Oysa amaç bireyi değil, bilginin sistem içindeki akışını analiz etmek olmalı.
Burada devreye bus factor kavramı giriyor: bir ekipte, belirli bir kritik modülü anlayan kişi sayısı bire indiğinde ("o kişi bir otobüse binip gitse" projenin ne kadar zarar göreceği düşüncesinden gelen bir metafor), proje sürekliliği ciddi risk altındadır. Blame verisi, hangi dosyaların hangi kişi(ler) tarafından baskın şekilde değiştirildiğini gösterdiği için bu riski tespit etmekte doğal bir araçtır.
Bir tech lead'in bu veriye bakarken sorması gereken soru "kim hata yaptı" değil, "bilgi nerede sıkışmış, hangi modülde tek bir kişiye bağımlıyız" olmalıdır. Bu çerçeve değişikliği, aynı verinin tamamen farklı bir yönetim aracına dönüşmesini sağlar.
Yüksek Riskli Dosyaları Blame Geçmişiyle Birleştirmek
Ekip yönetiminde faydalı bir teknik, dosya bazlı churn (değişim sıklığı) analizidir: bir dosyanın belirli bir süre içinde kaç kez değiştirildiğini saymak. Sık değişen dosyalar genelde ya aktif geliştirilen bir özelliğin parçasıdır ya da tasarımı kırılgan olduğu için sürekli yama gerektiren bir risk noktasıdır.
Bu churn verisi blame geçmişiyle birleştirildiğinde, ekip şu soruya cevap bulabilir: bu sık değişen ve riskli dosyaya kim aşinadır? Eğer bu dosyayı düzenli değiştiren tek bir kişi varsa, hem o kişinin iş yükü hem de dosyanın gözden geçirilme kalitesi açısından dikkat gerekir.
Bu kesişim, code review önceliklendirmesinde pratik bir girdi sunar: yüksek churn + dar sahiplik dağılımına sahip dosyalar, review sürecinde ekstra dikkat ve mümkünse ikinci bir gözden geçiren kişi gerektirebilir. Statik analiz araçlarının işaretlediği yüksek karmaşıklık (cyclomatic complexity) veya sık uyarı üreten dosyalarla bu liste eşleştirildiğinde, "hem teknik açıdan riskli hem de bilgi olarak dar" dosyalar net biçimde ortaya çıkar — bu da sınırlı review kapasitesinin nereye yönlendirileceğine dair somut bir öncelik sırası oluşturur.
Dengesiz Sahiplik Dağılımını Tespit Etmek
Bazı modüller zamanla "birinin alanı" haline gelir. Bu doğal bir süreçtir ama fark edilmeden büyüdüğünde riske dönüşür. Belirtileri genelde şunlardır: bir modüle dair pull request'lerin neredeyse tamamının aynı kişi tarafından açılması veya onaylanması, o modülle ilgili sorularda ekibin hep aynı kişiye yönlenmesi, diğer geliştiricilerin o dosyaya dokunmaktan çekinmesi.
Bu görünürlük eksikliği, kişi izinli olduğunda ya da ekipten ayrıldığında aniden fark edilir — genelde de en kötü zamanda, bir üretim sorunu sırasında. Blame verisi üzerinden dosya/modül bazında yazar dağılımına düzenli olarak bakmak, bu tabloyu proaktif şekilde görmeyi sağlar.
Dengesizlik tespit edildiğinde uygulanabilecek pratik önlemler arasında şunlar sayılabilir: o modül üzerinde bilinçli olarak çift programlama (pair programming) seansları düzenlemek, code review atamalarında rotasyon uygulayarak farklı kişilerin o koda dokunmasını teşvik etmek, ve kritik mantığı kod içinde değil dokümantasyonda da açıklamak.
Onboarding Sürecinde Blame Verisinin Kullanımı
Yeni katılan bir geliştiricinin en büyük zorluklarından biri, "bu konuda kime sorabilirim" bilgisine sahip olmamaktır. Resmi organizasyon şeması bu soruya çoğu zaman cevap vermez, çünkü gerçek uzmanlık genelde iş unvanlarıyla değil, kim neyi sık sık değiştirdiğiyle örtüşür.
Belirli dosya veya dizinler için blame geçmişine bakarak çıkarılan bir "bu bölgeyle en çok kim ilgilenmiş" listesi, yeni katılan biri için doğal bir rehber işlevi görebilir. Bu, kişiyi tek yetkili merci ilan etmek anlamına gelmez; sadece "bu kişi muhtemelen bağlamı biliyor, ona sorabilirsin" düzeyinde pratik bir ipucudur.
Burada dikkat edilmesi gereken nokta, bu listenin resmi bir hiyerarşi ya da sorumluluk ataması gibi sunulmamasıdır. Amaç, bilgiye ulaşma süresini kısaltmak, kimseyi tek bir konuya hapsetmek değildir.
Statik Analiz ve Kod Kalitesi Verileriyle Birlikte Değerlendirme
Blame verisi tek başına teknik borcu göstermez; sadece kimin o koda dokunduğunu gösterir. Teknik borç önceliklendirmesinde asıl değer, bu bilginin statik analiz araçlarının ürettiği verilerle çakıştırılmasından gelir.
Örneğin bir statik analiz aracı belirli bir dosyada yüksek karmaşıklık, tekrarlanan kod bloğu veya güvenlik açısından riskli bir örüntü işaretlediğinde, bu dosyanın blame geçmişine bakmak iki şeyi ortaya koyar: bu riskli kodu kim/kimler yazmış ve şu anda kim(ler) bu koda aşina. Eğer riskli olarak işaretlenen kod hem karmaşıksa hem de tek bir kişi dışında kimsenin dokunmadığı bir alansa, bu, önceliklendirme listesinde üst sıralara çıkmayı hak eder — çünkü hem düzeltilmesi teknik açıdan zor hem de düzeltecek kişi sayısı sınırlıdır.
Bu yaklaşım, teknik borç yönetimine ikinci bir boyut ekler: sadece "ne kadar riskli" değil, "bunu düzeltmek için ekipte ne kadar erişilebilir bilgi var" sorusu da önceliklendirmeye dahil edilir.
Dikkat Edilmesi Gerekenler: Yanlış Kullanım Riskleri
Blame verisinin en büyük tehlikesi, performans değerlendirmesi ya da bireysel yargılama aracına dönüştürülmesidir. "Bu dosyadaki hataların çoğu senin commit'lerinde" gibi bir çerçeveleme, ekipte güvensizlik yaratır ve insanların risk almaktan, deneysel çözümler denemekten kaçınmasına yol açar.
Ayrıca eski kodun mevcut haliyle görünmesi, o kodu yazan kişinin o dönemki tercihini değil, o dönemin koşullarını yansıtıyor olabilir — belki zaman baskısı vardı, belki farklı bir mimari standardı geçerliydi, belki o zamanki bağımlılıklar farklı sınırlamalar getiriyordu. Bugünün standartlarıyla geçmişi yargılamak adil değildir.
Son olarak, bu verinin bağlamsız paylaşılması (örneğin bir toplantıda isim isim "en çok değişiklik yapan/yapmayan" listesi göstermek) savunmacı bir tutum yaratır ve asıl amaç olan bilgi paylaşımını teşvik etmenin tam tersi bir etki doğurur.
Şeffaf ve Yapıcı Paylaşım İçin Pratik Yaklaşımlar
Bu verilerin ekip içinde sağlıklı şekilde konuşulabilmesi için birkaç pratik ilke işe yarar:
- Veriler bireysel değil, süreç ve sistem odaklı sunulmalı: "X modülünde bilgi dar, nasıl dağıtırız" diye çerçevelenmeli, "X kişi bu modülü tekelinde tutuyor" diye değil.
- Amacın açıkça belirtilmesi önemli: bu analizin performans değerlendirmesi değil, bakım sürdürülebilirliğini artırmak için yapıldığı baştan söylenmeli.
- Somut aksiyonlarla desteklenmeli: rotasyonlu code review atamaları, kritik modüller için dokümantasyon yazma görevleri, çift programlama seansları gibi yapıcı öneriler sunulmalı.
- Düzenli ama düşük baskılı bir alışkanlık haline getirilmeli: bu analiz, kriz anında değil, örneğin üç ayda bir yapılan sakin bir "kod sağlığı" gözden geçirmesinin doğal bir parçası olmalı.
Blame analizi, adının çağrıştırdığının aksine, doğru kullanıldığında ekip içi güveni zedeleyen değil, bilgi paylaşımını ve sürdürülebilirliği güçlendiren bir araçtır. Önemli olan, verinin kime değil, sisteme ve sürece dair ne söylediğine odaklanmaktır.
