Kodu Okumadan Önce Çalıştırılacak Git Komutları

 (piechowski.io)
89 puan yazan GN⁺ 21 일 전 | 1 yorum | WhatsApp'ta paylaş
  • Yeni bir kod tabanıyla karşılaştığınızda, Git geçmişini analiz ederek projenin yapısını ve riskli bölgelerini anlamak verimli bir keşif yönü belirlemeyi sağlar
  • Son 1 yılda en sık değiştirilen dosyaları bularak değişim sıklığı ile hata yoğunluğunu çapraz analiz edip yüksek riskli kodu belirleyebilirsiniz
  • Katkıda bulunanların dağılımı ve aktivite eğilimleri, bus factor, bakım boşluğu ve bilgi kopuşu olasılıklarını kontrol etmeye yardımcı olur
  • Aylık commit sayısıyla ekibin geliştirme hızı ve ivmesindeki değişimleri izleyebilir, Revert ve Hotfix sıklığıyla yayın kararlılığını değerlendirebilirsiniz
  • Bu beş komut, tek bir satır kod açmadan önce projenin sağlık durumunu hızlıca teşhis etmek için pratik araçlar olarak kullanılabilir

Kodu Okumadan Önce Çalıştırılacak Beş Git Komutu

  • Yeni bir kod tabanını analiz ederken, dosyaları açmadan önce Git geçmişiyle projenin sağlık durumunu teşhis etme yaklaşımı
    • Commit geçmişi üzerinden kimin oluşturduğunu, sorunların nerede yoğunlaştığını ve ekibin ne kadar istikrarlı yayın yaptığını anlayabilirsiniz

  • En sık ne değişiyor?

    • Komut: 
      git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20
    • Son 1 yılda en çok değiştirilen ilk 20 dosyayı gösterir
    • Üst sıralardaki dosyalar çoğu zaman ekibin “dokunmaya çekindiği” dosyalardır; yüksek değişim sıklığı (churn) ile sahiplenmeden kaçınma birleştiğinde kod tabanının en büyük yük unsuru haline gelirler
    • Microsoft Research'ün 2005 tarihli çalışmasına göre, değişim sıklığına dayalı metrikler kusur tahmininde karmaşıklık metriklerinden daha güçlüdür
    • İlk 5 dosyayı hata yoğunluğu komutuyla çapraz analiz ederek çok değişen ve çok hata veren dosyaları en yüksek risk unsuru olarak belirleyin

  • Bu kodu kim yazdı?

    • Komut: 
      git shortlog -sn --no-merges
    • Katkıda bulunanları commit sayısına göre sıralar
    • Tek bir kişi %60'tan fazlasını oluşturuyorsa bus factor riski vardır
    • En üst katkıcı son 6 ay içinde aktif değilse bakım boşluğu ihtimali vardır
    • 30 katkıcıdan son 1 yılda yalnızca 3'ü aktifse, geliştirici değişimi nedeniyle bilgi kopuşu yaşanıyor olabilir
    • Ancak squash-merge stratejisi kullanan ekiplerde yazar bilgisi birleştirmeyi yapan kişiye kayabileceği için merge stratejisinin kontrol edilmesi gerekir

  • Hatalar nerede yoğunlaşıyor?

    • Komut: 
      git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20
    • Hata ile ilgili anahtar kelimeleri içeren commit'lere dayanarak en çok hata görülen ilk 20 dosyayı çıkarır
    • Bu listeyi değişim sıklığı listesiyle karşılaştırarak sık değişen ve sık bozulan dosyaları yüksek riskli kod olarak belirleyin
    • Sonuçların doğruluğu commit mesajlarının kalitesine bağlıdır, ancak yaklaşık bir hata yoğunluğu haritası olarak bile yeterince faydalıdır

  • Proje hızlanıyor mu, yoksa duraklıyor mu?

    • Komut: 
      git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c
    • Aylık commit sayıları üzerinden aktivite eğilimini görsel olarak kavramayı sağlar
    • Düzenli bir ritim sağlıklı bir projeye işaret eder
    • Commit sayısı bir ay içinde yarıya düşerse çekirdek kadrodan ayrılma ihtimali vardır
    • 6–12 ay boyunca süren sürekli düşüş ekip ivmesinde zayıflamaya, dönemsel sıçramalar sonrası durgunluk ise batch tarzı release modeline işaret eder
    • Gerçek bir örnekte, commit hız grafiği sayesinde bir CTO bunun “kıdemli mühendisin ayrıldığı zaman” olduğunu fark etmiştir
    • Bu veri kod verisi değil, ekip verisi olması bakımından anlamlıdır

  • Ekip ne kadar sık acil müdahaleyle uğraşıyor?

    • Komut: 
      git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'
    • Revert ve Hotfix sıklığını ölçer
    • Yılda birkaç tane normaldir, ancak iki haftada bir yaşanıyorsa bu yayın sürecine güvensizlik sinyalidir
    • Bu durum test istikrarsızlığı, staging eksikliği, karmaşık rollback prosedürleri gibi daha derin sorunların belirtisi olabilir
    • Sonuç 0 ise ekip gerçekten istikrarlıdır ya da commit mesajları yeterince doğru değildir
    • Kriz örüntüleri net biçimde ortaya çıkar ve yalnızca varlığı bile güvenilirlik hakkında fikir verebilir

Sonuç

  • Bu beş komut birkaç dakika içinde çalıştırılabilir ve tek bir satır kod açmadan önce okumaya nereden başlanacağına dair yön gösterir
  • Böylece ilk günü rastgele gezinerek geçirmek yerine sorunlu alanlara odaklanan sistematik bir kod analizi yapılabilir
  • Bu yaklaşım kod tabanı denetiminin (codebase audit) ilk saatini oluşturur ve sonrasındaki bir haftalık analiz sürecine zemin hazırlar

İlgili okumalar

1 yorum

 
GN⁺ 21 일 전
Hacker News görüşleri

  • Jujutsu'da git analiz komutlarının yerine kullanılabilecek örnekler paylaşılıyor
    Son 1 yılda en çok değişen dosyalar, başlıca katkı sağlayanlar, hataların yoğunlaştığı yerler, projenin canlılığı, acil düzeltme sıklığı gibi şeyler jj log komutuyla görülebiliyor
    Kabuk betiklerinden çok programlamaya daha yakın bir sözdizimi var ama hatırlanması gereken bayrak sayısı daha az

    • Bana göre jujutsu, sürüm kontrol sistemlerinin Nix'i gibi görünüyor
      Nix nasıl havalı ama karmaşıklık ekliyorsa, jujutsu da öyle hissettirdi
      Birkaç ay kullandıktan sonra tekrar git'e döndüm. Çünkü git elim alışkın ve her yerde var
    • Bu tür özel betik dillerinin hepsini insanlar nasıl aklında tutuyor anlayamıyorum
      jq'da sadece dizi döngüsünü hatırlayabilsem bile seviniyorum, bu tür sözdizimlerine ise hiç kafam basmıyor
    • Ne jj ne de git komutlarını ezberlemeyi düşünmüyorum; ikisi de fazla uzun ve karmaşık
      Sık kullanacaksam alias ile kısaltır geçerim
    • Commit olmaması projenin ölü olduğu anlamına gelmez, hatta istikrarlı olduğu anlamına gelebilir
      Mesela 10 yıldır güncellenmeyen bir QR kod üretim kütüphanesi var ve kusursuz çalışıyor
      Bazen sırf botlarla işe yaramaz commit'ler mi eklemeliyiz diye düşündürtüyor
    • Git'i programlamak istemiyorum, sadece işimi bitirmek istiyorum
      Bu yüzden jujutsu gibi araçlar yerine geleneksel UNIX pipe komutlarını tercih ediyorum
      Gradle yerine Maven kullanmamın nedeni de aynı

  • Yazarın, geliştiricilerin commit mesajlarını düzgün yazdığını varsayması komikti
    Gerçekte çoğu en fazla “changed stuff” seviyesinde oluyor
    Benim gibi commit loglarını önemseyen insanlar azınlıkta
    Yapay zeka tarafından üretilen commit mesajları bu soruna çok yardımcı olabilir

    • Bu bir liderlik meselesi. İyi bir takım lideri ya da CTO, commit mesajı kalitesiyle ilgili beklentiyi net koyar
    • PR'ları squash ederek birleştiren ekiplerde PR gövdesi commit mesajı haline geldiği için kalite daha yüksek olur
    • squash & merge iş akışında sonuçta PR başlığı asıl mesaj olur
      Geliştiriciler commit mesajlarını istedikleri gibi yazabilir, nasıl olsa sonra kimse okumaz
    • Bizim ekip Core repo ile Non-Core repo ayrımı yapıyor
      Core tarafında PR incelemesi ve ayrıntılı açıklama zorunlu, Non-Core tarafında ise serbest deney yapılabiliyor
      Core'da commit mesajı bazen koddan 20 kat uzun oluyor, Non-Core'da ise seviye “hope this works”
    • Geliştiricilerin commit mesajı yazmaması bir kültür sorunu
      Bizim şirkette bunu birbirimizden bekliyoruz

  • Bu komutları birkaç farklı kod tabanında denedim ama sonuçlar gerçek durumla örtüşmedi
    Mesela git shortlog -sn --no-merges çıktısında en çok commit'e sahip kişi çoktan şirketten ayrılmış olabiliyor
    Commit sayısının fazla olması yüksek katkı anlamına gelmiyor

    • Bu yüzden squash-and-merge tercih ediyorum
      Gereğinden fazla commit'i feature branch'te bırakıp ana dala temiz şekilde alıyorum
    • Bu tür komutlar sorunlu projeleri teşhis ederken faydalı
      Sıradan bir kod tabanında çoğu zaman pek anlamlı sonuç çıkmıyor
    • Açıkçası yazarın bu komutları gerçekten çalıştırıp çalıştırmadığından şüpheliyim, biraz LLM yazısı gibi duruyor
    • Otomatik iş akışları tek bir kişinin kimlik bilgilerini kullanırsa istatistikler çarpıtılabilir
    • Benim de bir şirketteki merkezi kod tabanında commit sayım ezici biçimde yüksekti
      Çünkü projeyi en baştan ben kurmuştum; şimdi ise diğer insanlar daha sık commit atıyor

  • “En çok değişen dosya, insanların dokunmaya korktuğu dosyadır” sözü ilginçti

    • Biraz “o kadar kalabalık ki kimsenin gitmediği restoran” paradoksu gibi
    • Test ettiğimde en sık değişen dosyalar otomatik üretilen dosyalar ya da giriş noktası gibi sıkıcı dosyalardı
    • Bu tür komutlar için uyarı şart
      Sadece çıktıya bakıp sonuç çıkarmak insanı daha çok saf gösterir
      Aslında en fazla, son 1 yılda hangi özellikler üzerinde çalışıldığını gösterir
    • Churn (değişim sıklığı) ile Complexity (karmaşıklık) birlikte incelenirse çok daha faydalı olur
      İkisinin de yüksek olduğu yerler asıl sorunlu bölgelerdir
      Bu alanlar birikince “uygulamayı baştan yazmamız lazım” cümlesi ortaya çıkar
    • İnsanların korktuğu dosyalar zorunlu ama karmaşık dosyalardır
      Herkesin değiştirmesi gerekir ama o kadar büyüktür ki yönetmesi zordur

  • Git için bir summary alias oluşturdum; branch özeti, commit sayısı, yazar sayısı, dosya sayısı gibi bilgileri tek seferde veriyor
    Fikri GitAlias/gitalias'tan aldım

    • Neden bunu .gitconfig fonksiyonu olarak yazdığını merak ediyorum; düz bir git-summary betiği yapmak daha kolay görünüyor
    • Bu komutları her seferinde elle yazmak biraz yapay zeka yazısı gibi geliyor; gerçek deneyimli kullanıcı alias yapıp tekrar kullanır
    • Güzel bir betik ama benim ortamımda log-of-count-and-email gibi bir komut yok
    • Yerelde bir man sayfası hazırlamak iyi olabilir

  • Regex'e kelime sınırı (\b) eklenmeli
    Mesela “debugger” içindeki “bug” yüzünden yanlış sonuçlar çıkabilir
    Düzeltilmiş örnek şöyle
    git log -i -E --grep="\b(fix|fixed|fixes|bug|broken)\b" ...

    • macOS'ta \b desteklenmediği için -E yerine Perl regex seçeneği -P kullanılmalı
      git log -i -P --grep="\b(...)\b" şeklinde düzeltilebilir
    • Bizde de “rollback” kelimesi farklı anlamlarda kullanıldığı için filtreleme gerekiyor
    • İyi yakalama, çok daha doğru olmuş

  • squash-merge yapılmazsa, commit sayısı çok olan kişi aslında en dağınık geliştirici de olabilir
    Eskiden böyle biri vardı; aynı dosyaları durmadan değiştirip sonunda işten çıkarıldı
    squash bu tür durumu gizlemek için iyi bir yöntem

  • Basit commit sayısı istatistiklerine güvenmek zor
    Kimi kişi yalnızca tamamen test edilmiş kodu commit'ler, kimi ise tek satır değişiklikleri sık sık commit'ler
    Tek bir commit'in değeri kişiden kişiye 100 kat değişebilir

    • Ama yazarın amacı değişim eğilimine bakmaktı
      Mutlak değerden çok değişim oranı daha anlamlı

  • Bu analiz yaklaşımı bana Adam Tornhill'in “Your Code as a Crime Scene” yazısını hatırlattı
    orijinal bağlantı
    Ayrıca Developer’s Legacy Index kavramına da benziyor

    • Tornhill'in erken dönem C yazılarını severdim, görmek güzel

  • Yazar her komutun sonucunu doğrudan gösterse daha iyi olurdu
    Açıklamadan ziyade çıktı örnekleri daha ikna edici olurdu

    • Bana da yazı biraz yapay zeka tarafından yazılmış gibi geldi ama yine de beş komut öğrenmiş oldum, o yüzden kötü sayılmaz