Code Review Kültürü: Hatabulma'dan Bilgi Paylaşımına

Ekip retrospektiflerinde tekrar eden bir sinyal vardır: bir developer’ın kodu review için göndermek yerine iki hafta boyunca tek başına bir feature üzerinde çalışmayı tercih etmesi. Bu tercih, review kültüründe belirli bir başarısızlık moduna işaret eder.

Sıkı review’ların ardındaki niyet sağlamdır. Uygulama ise pull request’i çoğu zaman bir tez savunmasına çevirir; karşıda da kişinin başarılı olmasına yardım etmektense hata bulmakla ilgilenen bir kurul oturur.

Toksik ve sağlıklı review kültürü arasındaki fark teknik standartlarla ilgili değildir. Linter’lar stil tartışmalarını otomatikleştirir; reviewer’lar mimari ve edge case’lere odaklanmalıdır. “Yeterince iyi” kriterleri değişiklik tipine göre değişir: hotfix ile yeşil alan projesi farklı standartlar gerektirir. Aynı checklist iki farklı takımda tamamen farklı sonuçlar verebilir; bağlam ve iletişim tarzı belirleyicidir. Benimsemeye değer varsayılan şu: stili otomasyona bırak, insan review dikkatini iş mantığına, mimariye ve öğretmeye ayır.

Hatabulmanın Bedeli#

Hatabulucu review kültürleri güvenilir şekilde daha kaliteli kod üretmez. Ürettikleri şey savunmacı developer’lar, bilgi siloları ve noktalı virgül tartışmalarına harcanan enerjidir; mimari problemler ise arada kaynar.

Bir review süreci kolayca kod formatlama, değişken isimlendirme kuralları ve whitespace tercihleri üzerindeki savaşlara dönüşebilir. Önemsiz stil sorunları yakalanırken payment sistemindeki race condition her reviewer’ın gözünden kaçar ve sonradan production’da ortaya çıkar. O kodu yazan developer, kodu stil açısından “review’a hazır” hale getirmeye o kadar odaklanmıştı ki karmaşık async logic konusunda rehberlik istemek hiç güvenli hissettirmedi. Reviewer’ların asıl problemleri yakalayacağını varsaydı. Reviewer’lar ise let mi const mu kullanılacağına karar vermekle meşguldü.

Kapsamlı Checklist#

Yaygın bir varyant iyi niyetle başlar. Mühendislik liderliği, gerçekten yüksek standartları korumak isteyerek kapsamlı bir review checklist’i yazar. Reviewer’ların güvenlik açıklarından isimlendirme kurallarına kadar her olası sorunu yakalaması beklenir.

En yakın ölçüm bir kat yukarıda, onay kapısında duruyor. DORA’nın 2019 Accelerate State of DevOps raporu altı yıllık araştırmaya ve 31.000’den fazla profesyonele dayanıyor. Rapora göre önemli değişiklikleri için change advisory board gibi harici bir kurulun ya da bir üst yöneticinin onayına ihtiyaç duyan ekiplerin düşük performanslı çıkma olasılığı 2,6 kat daha yüksek. Rapor bu töreni haklı çıkaracak getiriyi de aradı: “daha formel bir onay sürecinin daha düşük change fail rate ile ilişkili olup olmadığını inceledik ve bu hipotezi destekleyecek bir kanıt bulamadık.” DORA’nın önerisi onayı sola kaydırmak, yani geliştirme sırasındaki peer review’a dayandırmak. Bu bulgu ekibin dışından dayatılan onayı kapsıyor; bir peer review checklist’inin ne kadar kapsamlı olması gerektiğine dair bir şey söylemiyor. Kesinleşen kısım daha dar: değişikliğin üstüne resmi bir denetim katmanı eklemek change fail rate’i düşürmedi. DORA denetimi bunun yerine peer review’ın içine koyuyor.

Reviewer’dan her olası sorunu isteyen bir checklist thread’i hata avına doğru iter ve bu tonun maliyeti doğrudan ölçüldü. Gunawardena ve arkadaşları CSCW 2022 için 93 uygulayıcıya anket yaptı. En az yılda bir review geri bildirimi alan 87 kişinin %55’i son bir yılda belirsiz olumsuz geri bildirim, %22’si ise düşüncesiz bulduğu bir geri bildirim almış. Aynı çalışmadaki asimetri sorunun neden kendiliğinden düzelmediğini anlatıyor: geri bildirim verenlerin yalnızca %27’si belirsiz olumsuz yorum yazdığını kabul ediyor, düşüncesiz geri bildirim verdiğini kabul eden ise tek bir katılımcı. Çalışmadaki senaryolarda yapıcı geri bildirim sonrası katılımcıların %20,2’si olumsuz ruh hali bildirirken, yıkıcı geri bildirim sonrası bu oran %94,3’e çıkıyor. Kadın katılımcılar yıkıcı eleştiriyi daha az uygun buluyor ve o reviewer’la çalışmayı sürdürme motivasyonları daha düşük.

Google ölçeğinde aynı dinamiğin bordroda bir karşılığı var. Murphy-Hill, Jaspan, Egelman ve Cheng 2022’de Communications of the ACM’de reviewer pushback’inin “Google’a her gün 1000 mühendis saatinden fazlasına, yani mühendislerin reviewer yorumlarına yanıt vermeye ayırdığı tahmini sürenin yaklaşık %4’üne mal olduğunu; bu maliyetin beyaz olmayan ve erkek olmayan mühendislerin sırtına bindiğini” tahmin etti. Tahmin, yorumların nasıl yazıldığına işaret ediyor; bir takım bunu standardını düşürmeden değiştirebilir.

Yorum hacmi ise görünen belirti. Sadowski ve arkadaşları ICSE-SEIP 2018 için Google’daki yaklaşık 9 milyon değişikliği inceledi: medyan değişiklik 24 satır değiştiriyor, değişikliklerin %80’inden fazlası yorumları çözmek için en çok bir tur gerektiriyor ve yorum sayısı 1.250 satır civarındaki değişikliklerde değişiklik başına yaklaşık 12,5 ile zirve yapıyor. Sıradan bir değişikliğe onlarca stil yorumu düşen bir thread bu dağılımın çok dışında kalıyor ve yazarlar bu hacmi kendi yetkinliklerine dair bir yargı olarak okuyor.

Review Neden Var#

Hata avı, review’ın açıkça belirtilen amacı değil; Google’da bile değil. Sadowski ve arkadaşlarının ilk bulgusu şu: “Google’da code review beklentileri problem çözme etrafında şekillenmiyor.” Review oraya okunabilirliği ve sürdürülebilirliği korumak için girmiş; görüştükleri developer’lar bu listeye eğitimi, normların korunmasını, geçmişin izlenmesini, kapı bekçiliğini ve kaza önlemeyi eklemiş. Hata bulmak hoş karşılanıyor ama tek odak değil. 44 developer’la yapılan anket bu oranı somutlaştırıyor: 8 katılımcı aldığı yorumları faydasız buldu, yalnızca 2 katılımcı yorumların bir bug yakaladığını söyledi.

Ölçek bunu havada kalmaktan kurtarıyor. Aynı çalışma, 25.000’den fazla developer’ın her iş günü 20.000’den fazla kaynak kodu değişikliği yaptığı bir süreci anlatıyor. Reviewer’lar buna haftada ortalama 3,2 saat ayırıyor, medyanı 2,6 saat. Medyan değişikliğin bir reviewer’ı var; değişikliklerin %25’inden azı birden fazla reviewer görüyor ve %99’undan fazlasında en çok beş reviewer bulunuyor.

Psikolojik Güvenlik Pratikte#

Review’ın işlediği takımlarda insanlar erken ve sık review istiyor, çünkü thread onlara düzenli olarak bir şey öğretiyor. Problemler yine yakalanıyor; üstelik neden önemli olduklarını açıklayacak kadar bağlama sahip biri tarafından.

Google’ın Project Aristotle çalışması bunu mümkün kılan koşula bir isim verdi. re:Work yazısına göre 180 takım (mühendislikte 115 proje takımı, satışta 65 pod) incelendi ve liderlerle yüzlerce çift kör görüşme yapıldı. Etkili takımları ayıran beş dinamik arasında psikolojik güvenlik birinci sırada çıktı; güvenilirlik, yapı ve netlik, anlam ve etki onun ardında kaldı. Google, Amy Edmondson’ın tanımını olduğu gibi kullanıyor: “takım üyelerinin, takımın kişilerarası risk almak için güvenli olduğuna dair paylaştığı ortak inanç.” Bir review thread’i, bir developer’ın sıradan bir haftada aldığı daha görünür kişilerarası risklerden biridir.

Bir thread’i bu tanımın içinde tutmak bilinçli bir yapı ister. İlk yorumu yazmadan önce sor: bu değişiklik hangi problemi çözüyor, yazar hangi trade-off’ları tarttı, hangi kısımlardan emin değil. Bu sorular thread’in geri kalanının neyle ilgili olacağını değiştirir.

Sonra diff’te şu sırayı izle:

1. İş mantığı ve gereksinimler
2. Mimari ve tasarım kalıpları
3. Performance ve güvenlik
4. Otomasyon bir şekilde kaçırdıysa stil ve formatlama

İfade biçimi de sıra kadar ağır basar. Bir soru (“bu retry edilirse ne olur?”) karşılığında açıklama getirir; bir talep yalnızca uyum getirir. Önerilen alternatifin gerekçesi de yanında olmalı, yoksa yazar kuralı öğrenir, nedenini hiç öğrenmez.

Otomasyonun Thread’den Aldığı İşler#

Modern tooling, bir insan yorumuna neyin gireceğini değiştirir. Deterministik cevabı olan kontrolleri otomasyona ittiğinde asıl soru şu olur: bu dilim ne kadar büyük? Elimizde bunun iyi bir production ölçümü var.

Bu Dilim Ne Kadar Büyük#

Frömmgen ve arkadaşları ICSE-SEIP 2024’te, reviewer yorumlarını çözen düzenlemeler öneren ve Google mühendislerinin %100’üne açılmış bir modeli anlattı. Sahada yazarlar, tüm reviewer yorumlarının %7,5’ini ML’in önerdiği bir düzenlemeyi uygulayarak kapatıyor. Modelin %50 yayılımdaki önceki sürümünde bu oran %4,9’du. Dile göre makale Java’da %9,5, C++‘ta %7,5 ve Python’da %7,1 bildiriyor.

Geri kalanın nereye gittiğini huni gösteriyor:

Aşama	Oran
Tahmin üretilen uygun yorumlar	yaklaşık yarısı
Reviewer’ın kabul edip yoruma iliştirdiği tahminler	%63’ten fazla
Yazarın önizlediği iliştirilmiş öneriler	%34
Önizlenip koda uygulanan öneriler	%70
Uygulanan bir düzenlemeyle kapanan tüm reviewer yorumları	%7,5

Google’ın araştırma blogu, aynı modelin çevrimdışı değerlendirmede %50 hedef kesinlikle yorumların %52’sini karşıladığını yazıyor. Değerlendirmedeki %52 ile sahadaki %7,5 arasındaki mesafe işin özü, çünkü bir model yazarların uyguladığından çok daha fazla düzeltme önerebiliyor.

Yine de kazanç gerçek, çünkü insan döngüsü pahalı. Aynı makale, Google’da yazarların bir değişikliği review’a gönderdikten sonra submit edene kadar ortalama 60 dakika aktif takip harcadığını ve bu sürenin yorum sayısıyla neredeyse doğrusal büyüdüğünü bildiriyor. Bir yorum sınıfını ortadan kaldırmak bu takip süresini de azaltır.

Araçların Bittiği Yer#

Otomatik kontroller yaygın güvenlik kalıplarını, performance anti-pattern’lerini ve stil tutarsızlıklarını kapsadığında, thread’de kalan her şey yargı ister. “Eksik noktalı virgül” diyecek yorum hiç yazılmaz, çünkü kontrol PR açılmadan önce çalışmıştır.

Sınırı üretici dokümantasyonu net çiziyor. GitHub’ın Copilot code review dokümanına göre Copilot “her zaman bir ‘Comment’ review bırakır; ‘Approve’ ya da ‘Request changes’ review’ı bırakmaz”. Dolayısıyla review’ları zorunlu onay sayısına dahil edilmez ve bir merge’ü engelleyemez. Aynı sayfa Copilot’ın kendi yorumlarına gelen yanıtları göremediğini, daha önce kapatılmış yorumları yeniden yazabileceğini ve bir review’ın genelde 30 saniyenin altında tamamlandığını belirtiyor.

Diğer sınırı developer’ların kendisi çiziyor. DORA’nın yaklaşık 5.000 teknoloji profesyoneliyle yaptığı 2025 State of AI-assisted Software Development raporunda katılımcıların %90’ı işte AI kullanıyor ve %80’inden fazlası verimliliğinin arttığına inanıyor; buna karşılık %30’u AI’ın ürettiği koda çok az güveniyor ya da hiç güvenmiyor. Stack Overflow 2025 Developer Survey ayrımı daha da keskin gösteriyor: %84’ü AI araçlarını kullanıyor ya da kullanmayı planlıyor, bir önceki ankette bu oran %76’ydı; buna karşılık %46’sı doğruluklarına açıkça güvenmiyor, güvenenlerin oranı %33 ve çıktıya yüksek güven duyduğunu söyleyenler yalnızca %3. En büyük şikâyet %66 ile “neredeyse doğru ama tam değil” çıktılar; %45,2’si de AI üretimi kodu debug etmenin kazandırdığından çok zaman aldığını söylüyor.

Otomasyon, kimsenin bir şey öğrenmediği yorumları ortadan kaldırır. Öğreten yorumlar ise reviewer’ların bunları yazacak zamanı ve yetkisi olup olmadığına bağlı kalır.

Review’ı İlişkiye Göre Ayarlamak#

İlk büyük feature’ını çıkaran bir junior developer’ın ihtiyacı, yeni bir servis kuran senior bir mühendisinkinden farklı. Bu yalnızca sezgi değil. Sadowski ve arkadaşları Google’daki görüşmeleri kodlayıp ikinci bulgularına ulaştı: “Google’da belirli bir code review’a dair beklentiler, yazar ile reviewer’lar arasındaki çalışma ilişkisine bağlıdır.” Bir reviewer’dan ne söylemesi beklendiğini, diff’ten çok bu çalışma ilişkisi belirliyor.

Pratikte aynı reviewer üç ayrı tür yorum yazar. Yeni başlayan biriyle işe yarayan yorumlar iş mantığı doğruluğu ve test kapsamı üzerinedir ve gerekçesini yanında taşır; çünkü asıl mesele kalıbın bir sonraki feature’a taşınması. Mid-level bir mühendisle thread bir tartışmaya döner: cross-team etki, sorgulanmayı hak eden varsayımlar, savunulmayı hak eden tasarım kararları. Eş seviyede biriyle ise iki kişinin sistem düzeyindeki seçenekleri karşılaştırmasına benzer ve mentorluk çoğu zaman takımın sonradan okuyabileceği bir dokümana dönüşür.

Bunların hiçbiri kendiliğinden olmuyor. İşin açıkça tanımlanmış bir parçası olması gerekiyor: adı konmuş review eşleşmeleri, bağlamın tek bir ikilide birikmemesi için rotasyon ve bu işin götürdüğü saatlerin görünür olması.

İşe yaradığının sinyali davranışsaldır. İnsanlar review’ı daha erken ister, geliştirmek istedikleri alanlarda spesifik feedback talep eder ve başkalarının PR’larına içerikli yorumlar bırakmaya başlar; öğrenmenin çift yönlü hale geldiği yer burasıdır.

Saat Dilimleri Arasında Review#

Dağıtık takımlarda sert bir yorumu yumuşatacak koridor sohbeti yoktur; ilişkinin tamamını thread taşır. Bu da “neden”i zorunlu kılar: gerekçesi olmayan bir feedback, açıklamaya üşenen birinin talimatı gibi okunur. Doğrudanlık seviyesi kültürden kültüre değişir; bir takıma göre ayarlanmış bir yorum başka bir takımda kaba düşer. Mimari konularda kısa bir kayıt genelde uzun bir yorumdan iyidir, gerçekten tartışmalı bir nokta ise kısa ve isteğe bağlı bir görüşmeyi hak eder.

Yeni Ekip Üyesi Ne Öğrenir#

Review’lardaki sistematik mentorluk uyum süresini kısaltır; çünkü yeni ekip üyesi kuralları kendi kodunda uygulanmış halde görür. Dokümantasyon kuralı soyut olarak anlatır; bir review yorumu ise kuralı, kişinin zaten verdiği bir karara ve zaten önemsediği bir dosyaya bağlar. Öğrendikleri şey, dokümantasyonun en kötü aktardığı kısımdır: savunulabilir birkaç seçenekten hangisini bu kod tabanının bariz kabul ettiği ve bunun nedeni.

Bu uyum süresine sayı koyan yayımlanmış bir çalışma yok. Onboarding literatürü açık kaynakta yeni katılanların önündeki engelleri ve ilk patch’in kabul edilmesini ölçüyor; “üretkenliğe geçiş süresi” tanımı da çalışmadan çalışmaya bir rakamı taşıyamayacak kadar değişiyor. Yön gösteren destek yine de var: Sadowski ve arkadaşları Google’da eğitimin review’ın birincil beklentilerinden biri olduğunu buldu ve review beklentilerinin yazar ile reviewer arasındaki çalışma ilişkisine göre değiştiğini gösterdi. Buradaki mekanizma tam olarak bu iki bulgu. İkisi de kronometre değil; buraya konacak bir uyum süresi rakamı ölçülmüş olmaz, uydurulmuş olur.

Review Kültürü Sağlığının Ölçümü#

Review cycle time ve hata tespit oranları gibi geleneksel metrikler, sağlıklı review kültürünün en önemli yönlerini kaçırıyor. Forsgren, Storey, Maddila, Zimmermann, Houck ve Butler’ın 2021’de ACM Queue’da yayımladığı SPACE çerçevesi problemin genel halini söylüyor: developer üretkenliği “tek bir metrikle ya da tek bir boyutla ölçülemez.” Çerçevenin beş boyutu memnuniyet ve iyi olma hali, performans, aktivite, iletişim ve işbirliği, verimlilik ve akış. Review sayıları aktivite boyutuna giriyor; yani ilerleme gibi görünen ama nadiren ilerleme olan sayı sınıfına.

Aşağıdaki göstergeler birer öneri; yerleşik birer ölçüm aracı olarak okunmamalı. Yayımlanmış en yakın çalışma Egelman ve arkadaşlarının ICSE 2020 makalesi: olumsuz review deneyimlerini anlamak için 1.317 developer’a anket yapıp yanıtları code review loglarıyla karşılaştırdılar. Pushback’i “pratikte görece nadir, ama ortaya çıktığında olumsuz sonuçları olan” bir olgu olarak buldular ve sinyallerinin ne yapabileceği konusunda dikkatli davrandılar: metrikleri “pushback hissini yüksek duyarlılıkla ama düşük kesinlikle tahmin ediyor; bu da onları müdahaleden fayda görebilecek etkileşimleri işaretlemek için potansiyel olarak uygun kılıyor.” Aşağıdaki her şeyin tavanı burası.

İzlemeye Değer Sinyaller#

Developer’lar review’ı kendileri mi arıyor, yoksa zorlanana kadar mı kaçınıyor? Thread’ler düzenli olarak savunmacı yanıtlarla mı bitiyor? İnsanlar başka takımların kodunu review etmeye yanaşıyor mu? Reviewer’lar hiç açıklayıcı soru soruyor mu, yoksa yalnızca hüküm mü veriyor? Hiçbirinin bir eşik değeri yok; her biri çeyreklik bir sayıdan çok, aylar içindeki yön olarak okunur.

İki gösterge daha var; bunlar iklimi değil öğrenmeyi gösterir: developer’lar eski bir review’da öğrendikleri kalıbı yeni koda uyguluyor mu, ve review thread’leri dokümantasyon güncellemesi üretmeye devam ediyor mu.

Kalıcılık da listeye girer. Review, bir junior developer’ın kaçınamayacağı birkaç günlük ritüelden biridir; bu grupta süregelen kayıpları maaşı suçlamadan önce review tonuyla karşılaştırmakta fayda var. Google’ın Project Aristotle’ı anlatan re:Work yazısı, kültürü güçlü takımlardaki bireylerin Google’dan ayrılma olasılığının daha düşük olduğunu ve yöneticiler tarafından iki kat daha sık etkili bulunduklarını aktarıyor; takım iklimi ile hem kalıcılık hem de algılanan çıktı arasında yayımlanmış en yakın bağ bu.

Yanına iki ucuz sinyal daha koyabilirsin. Alışılmadık bir yaklaşımı deneyen PR’ları say; düşmanca bir review bekleyen takım güvenli versiyonu gönderir. Bir de takımın bir yokluğu nasıl karşıladığına bak, çünkü review’lar aksi halde tek bir kişinin kafasında kalacak bağlamı yayar.

Yayımlanmış Verilerden Referans Değerler#

Planlama toplantısında uydurulan hedefler genelde iki yönde birden yanlış çıkar. Yayımlanmış referans değerler daha iyi taşınır. Sadowski ve arkadaşları Google’da tüm review sürecinin medyan gecikmesini 4 saatin altında bildiriyor; ilk geri bildirim küçük değişikliklerde bir saatin altında, çok büyük değişikliklerde yaklaşık 5 saatte geliyor. Karşılaştırma için verdikleri medyan onay süreleri şöyle: AMD’de 17,5 saat, Chrome OS’te 15,7 saat ve üç Microsoft projesinde 14,7, 19,8 ve 18,9 saat. Aynı veri kümesinde medyan değişiklik 24 satıra dokunuyor ve bir reviewer’ı oluyor, değişikliklerin %30’u birden fazla kişiden yorum alıyor, medyan developer haftada yaklaşık 3 değişiklik yazıp yaklaşık 4 değişiklik review ediyor.

Bu ölçekte yayımlanmış tek randomize review müdahalesi süreci ele alıyor. Maddila ve arkadaşları ACM TOSEM 2022 için Nudge’ı 147 Microsoft reposunda çalıştırdı ve 8.500 pull request genelinde çözüm süresini %60 kısalttı; bildirimlerin %73’ü alıcılar tarafından olumlu değerlendirildi, sistem sonradan 8.000 repoya yayıldı ve bir yılda 210.000 bildirim gönderdi. Bir hatırlatma botu gecikmeyi kıpırdatabiliyor. Ton üzerine bir müdahalenin memnuniyet skorunu oynattığını gösteren yayımlanmış bir çalışma ise yok. Yukarıdaki göstergelerin nitel kalmasının sebebi bu; bir kültür değişimi için öncesi-sonrası rakamı vermek de o rakamı uydurmak olurdu.

Nereden Başlamalı#

Bir şey kurmadan önce psikolojik güvenliği ölç. Review deneyimi üzerine anonim bir anket, ardından kötü giden thread’ler üzerine birebir konuşmalar, herhangi bir dashboard’dan çok daha fazlasını anlatır. Sonra yeni yaklaşımı gönüllü olanlarla pilot çalıştır ve sonucun takımın geri kalanını ikna etmesine izin ver. Kültürel değişim teknik değişimden yavaş ilerler; bu yüzden araç kurulumunu bu konuşmalardan sonraya bırak.

Otomatik Kapı#

Stil ve lint bulguları, bir insan diff’i açmadan önce düşmeli. Asgari bir kapı şöyle görünür:

# Stil ve lint bulguları, bir insan diff'i açmadan önce ortaya çıksın
name: Automated Review Checks
on:
  pull_request:
    types: [opened, synchronize]

permissions:
  contents: read

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0 # super-linter base branch ile diff alır

      - name: Lint changed files
        uses: super-linter/super-linter@v8
        env:
          VALIDATE_ALL_CODEBASE: false
          DEFAULT_BRANCH: main
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      # Güvenlik taramasını ayrı bir job'da tut (CodeQL, Semgrep ya da
      # kurumun zaten kullandığı tarayıcı); böylece bir stil hatası
      # güvenlik bulgusunu maskelemez.

Bu Yaklaşım Nerede Ters Gider#

Aşırı Düzeltme Tuzağı#

Takımlar review kültürlerinin toksik olduğunu anladığında, düzeltme genellikle lastik damga onaylarına kadar savrulur. Amaç öğreten bir eleştiri. İyi review’lar yine problemleri yakalar ve bunu developer’ı yıkmak yerine destekleyerek yapar.

AI Bağımlılık Riski#

AI review’ı kalıplarda güçlü, bağlamda zayıftır; bu yüzden zor kısmı bağlam olan bir değişiklikte insan yargısının yerine geçemez. Çıktısını, bir insan diff’i açtığında çoktan çalışmış bir ilk tur gibi ele al.

Senior Developer Yükü#

Bazı senior developer’lar mentorluğa odaklanmayı review’ları “basitleştirmek” olarak okur. İşe yarayan yeniden çerçeveleme erişimle ilgilidir: bir yorumdaki gerekçe, thread’i sonradan okuyan herkese açık kalır. Ters yöndeki hata da en az onun kadar yaygın. Kimse herkesi her konuda mentor edemez; o yüzden eşleşmelerin sınırı, sorumlulukların rotasyonu ve harcanan saatlerin işin değerlendirilmesinde görünür olması gerekir.

Bu Varsayılan Ne Zaman Geçerli#

Bu ayrım, haftada birkaç PR’dan fazlasını review eden her takım için geçerli. İki durumda varsayılanı geç. Formatter’ı ve linter’ı olmayan bir kod tabanının henüz devredecek bir şeyi yoktur; önce onu kur, kültür işini ikinci tura bırak. Aktif bir incident’ın içindeki bir takım da dar düzeltmeyi dar bir review ile göndermeli, öğretme turunu retrospektifte yapmalıdır.

Kod kalitesi tüm bunların gecikmeli göstergesidir. Önce insanların ne hızda öğrendiğine bak; hata sayıları sonra gelir ve neden değiştiklerini sana söylemez.

Kaynaklar#

• Modern Code Review: A Case Study at Google (ICSE-SEIP 2018) (yeni sekmede açılır) - Sadowski, Söderberg, Church, Sipko ve Bacchelli’nin yaklaşık 9 milyon değişikliğe dayanan çalışması: inceleme gecikmesi, değişiklik boyutu, reviewer sayıları ve incelemenin açıkça belirtilen amacında eğitimin hata bulmanın önüne geçtiği bulgusu
• The Pushback Effects of Race, Ethnicity, Gender, and Age in Code Review (CACM 2022) (yeni sekmede açılır) - Murphy-Hill, Jaspan, Egelman ve Cheng, reviewer pushback’inin Google’a günlük mühendis saati maliyetini ve bu maliyeti kimin ödediğini tahmin ediyor
• Predicting Developers’ Negative Feelings about Code Review (ICSE 2020) (yeni sekmede açılır) - Egelman ve arkadaşları 1.317 developer’a anket yapıp inceleme loglarının kötü bir review deneyimini önceden kestirip kestiremediğini sınıyor
• Destructive Criticism in Software Code Review Impacts Inclusion (CSCW 2022) (yeni sekmede açılır) - Gunawardena ve arkadaşları, uygulayıcıların ne sıklıkta sert inceleme geri bildirimi aldığını ve bunu verdiğini kabul edenlerin ne kadar az olduğunu ölçüyor
• Resolving Code Review Comments with Machine Learning (ICSE-SEIP 2024) (yeni sekmede açılır) - Frömmgen ve arkadaşları, tüm Google mühendislerine açıldığında bir ML önerisinin reviewer yorumlarının ne kadarını gerçekten kapattığını raporluyor
• Resolving code review comments with ML (Google Research blogu) (yeni sekmede açılır) - Makalenin birinci elden tamamlayıcısı: çevrimdışı kapsama oranı ve öneri önizleme oranını yükselten arayüz değişiklikleri
• Nudge: Accelerating Overdue Pull Requests Toward Completion (ACM TOSEM 2022) (yeni sekmede açılır) - Maddila ve arkadaşları Microsoft repolarında inceleme hatırlatmalarını randomize bir denemeyle test edip çözüm süresine etkisini bildiriyor
• The SPACE of Developer Productivity (ACM Queue, 2021) (yeni sekmede açılır) - Forsgren, Storey, Maddila, Zimmermann, Houck ve Butler, developer üretkenliğinin neden tek bir metriğe sığmadığını ve hangi beş boyutun gerektiğini anlatıyor
• Accelerate State of DevOps Report 2019 (DORA) (yeni sekmede açılır) - Ağır onay süreçlerine karşı kanıtlar ve onay mekanizması olarak peer review’ın savunusu
• 2025 State of AI-assisted Software Development (DORA) (yeni sekmede açılır) - Yaklaşık 5.000 teknoloji profesyoneli arasında AI kullanımı, algılanan verimlilik ve AI üretimi koda duyulan güven
• Understand team effectiveness (Google re:Work) (yeni sekmede açılır) - Project Aristotle’ın araştırma tasarımı ve psikolojik güvenliği takım dinamikleri arasında nereye koyduğu
• Stack Overflow 2025 Developer Survey: AI (yeni sekmede açılır) - AI araçlarının benimsenmesiyle bu araçlara duyulan güven arasındaki fark ve çıktıda en çok neyin sinir bozduğu
• Using GitHub Copilot code review (yeni sekmede açılır) - Otomatik bir incelemenin bir pull request üzerinde ne yapıp ne yapamayacağına dair üretici dokümantasyonu
• Kod İnceleme Yorumları Yazma - Google (yeni sekmede açılır) - “Nit:” kuralı dahil, net ve yapıcı inceleme geri bildirimi yazma kılavuzu
• Kod İncelemesi Hızı - Google (yeni sekmede açılır) - İnceleme yanıt süresinin neden önemli olduğu ve ekip verimliliğini nasıl etkilediği