Code Review Neden Yapılır, Gerçekte Ne Bulur? Bug Avından Bilgi Paylaşımına

Sürüm notu: Bu yazı kavramsaldır; araştırma bulguları Bacchelli ve Bird'ün ICSE (International Conference on Software Engineering; yazılım mühendisliğinin en büyük akademik konferansı) 2013 makalesinden, Sadowski ve arkadaşlarının ICSE-SEIP 2018 makalesinden ve Mäntylä ile Lassenius'un 2009 tarihli çalışmasından, review ilkeleri Google Engineering Practices'ın Kasım 2026'daki hâlinden alınmıştır.

Önce Tahmin Et

Sitedeki serilerin ortak örnek uygulaması Bookstore'un (bir online kitapçı) ekibinde sprint retrospektifi yapılıyor. Product Owner Selin bir soru soruyor: "Pull request'ler ortalama bir buçuk gün bekliyor. Bu bekleme bize ne kazandırıyor? Production'a çıkan hataların kaçını review'da yakaladık?" Emre ve Ayşe birbirine bakıyor; ikisinin de aklındaki cevap "bug'ları yakalıyoruz" ama elde sayı yok.

Senin için bir tahmin sorusu. Microsoft'ta yapılmış bir araştırmada, gerçek review'lardan rastgele seçilmiş 570 review yorumu tek tek okunup türlerine ayrıldı. Sence bu yorumların yüzde kaçı bir hatayı, yani programın yanlış çalışmasına yol açacak bir kusuru işaret ediyordu? Yüzde 60 mı, yüzde 40 mı, daha az mı? İkinci soru: aynı araştırmada geliştiricilere "review'u neden yapıyorsun?" diye sorulduğunda en sık verilen cevap neydi?

Araştırmalar Review Hakkında Ne Söylüyor?

Bugün çoğu ekibin yaptığı review, 1970'lerin toplantı odasında satır satır yapılan code inspection'ından farklı: araç tabanlı, asenkron ve hafif. Literatür buna modern code review diyor ve bu konuda en çok atıf alan iki çalışma Microsoft ve Google'dan geliyor.

Alberto Bacchelli ve Christian Bird, ICSE 2013'te yayımladıkları çalışmada Microsoft'ta 17 geliştiriciyi review yaparken gözlemledi, 165 yönetici ve 873 geliştiriciyle anket yaptı ve 200 review tartışmasındaki 570 yorumu sınıflandırdı. Tahminin cevabı burada: geliştiricilerin yüzde 44'ü review'un bir numaralı amacını "hata bulmak" olarak işaretledi, ama yorumların yalnız 78'i, yani yaklaşık yüzde 14'ü hatayla ilgiliydi. Dokuz kategori içinde dördüncü sıradaydı. En büyük grup, yüzde 29 ile kod iyileştirmeleriydi: daha iyi bir kod pratiği kullanmak, gereksiz kodu silmek, okunabilirliği artırmak. Hata yorumlarının büyük kısmı da derin tasarım sorunları değil, gözden kaçmış bir edge case ya da yanlış bir koşul gibi küçük mantık hatalarıydı.

Aynı çalışmanın ikinci önemli bulgusu anlamakla ilgili. Geliştiricilerin yüzde 91'i tanımadıkları dosyaları review etmenin daha uzun sürdüğünü söyledi; yüzde 82'si de değişen dosyayı iyi bilen bir reviewer'ın farklı geri bildirim verdiğini söyledi; verdikleri örneklere göre bu yorumlar biçimden çok algoritmaya ve tasarıma dair, daha derin yorumlar. Yani review'un kalitesini en çok belirleyen şey reviewer'ın kodu ne kadar anladığı. Araştırmacılar review'un beklenmeyen kazançlarını da sıralıyor: bilgi transferi, ekibin neyin değiştiğinden haberdar olması ve aynı soruna alternatif çözümlerin konuşulması.

Mika Mäntylä ve Casper Lassenius 2009'da IEEE'nin (Institute of Electrical and Electronics Engineers; elektrik ve elektronik mühendislerinin meslek kuruluşu) dergisi Transactions on Software Engineering'de yayımladıkları çalışmada benzer bir sonuca vardı: review'larda bulunan kusurların yaklaşık dörtte üçü yazılımın dışarıdan görünen davranışını etkilemiyordu. Bunlar kodu anlamayı ve değiştirmeyi zorlaştıran, onların deyişiyle evolvability (kodun değişime açıklığı) sorunlarıydı.

Google tarafında Caitlin Sadowski ve arkadaşları 2018'de 12 mülakat, 44 kişilik bir anket ve yaklaşık 9 milyon review edilmiş değişikliğin log'larını inceledi. Review'u şirkete erken dönemde getiren mühendis, asıl amacın başka geliştiricilerin anlayabileceği kod yazmaya zorlamak ve her kod parçasını birden fazla kişinin bilmesini sağlamak olduğunu anlatıyor; bug bulmak hoş bir yan ürün. Sayılar da hafif bir süreci gösteriyor: değişikliklerin medyan boyutu 24 satır, yüzde 35'inden fazlası tek dosyaya dokunuyor, değişikliklerin dörtte üçünden fazlasında tek reviewer var, küçük değişikliklerde ilk geri bildirim medyan bir saatin altında geliyor ve tüm sürecin medyan süresi dört saatin altında. Şirkete yeni katılan geliştiricilerin değişiklikleri, deneyimlilere göre iki kattan fazla yorum alıyor ve bu sayı kıdemle düşüyor. Makale bunu review'un eğitim etkisinin kanıtı olarak yorumluyor.

Bu çalışmaların hiçbiri "review bug bulmaz" demiyor. Söyledikleri şu: review'un ürettiği değerin büyük kısmı bug avından değil, kodun anlaşılır kalmasından ve bilginin ekibe yayılmasından geliyor. Selin'in sorusuna "kaç bug yakaladık" diye cevap vermeye çalışmak, review'u yanlış ölçütle değerlendirmek demek.

Review'un Gerçek Hedefleri

Araştırmaları bir ekip kararına çevirince dört hedef çıkıyor.

Birincisi, kod sağlığını zaman içinde iyileştirmek. Her değişiklik codebase'i biraz daha iyi ya da biraz daha kötü bırakır. Review, kötüye giden küçük adımların birikmesini durduran yer. Google'da pull request'in karşılığı CL'dir (changelist; review'a gönderilen değişiklik). Google'ın Engineering Practices dokümanı ölçütü açık yazıyor: reviewer'lar "favor approving a CL once it is in a state where it definitely improves the overall code health of the system" (Google Engineering Practices, "The Standard of Code Review"). Ölçüt mükemmellik değil, mevcut hâlden daha iyi olmak. Reviewer'ın kendi yazacağı kodu beklemesi bu ölçütü bozar.

İkincisi, ortak sahiplik. Sepet hesaplamasını yalnız Emre biliyorsa, Emre izne çıktığında sepetle ilgili her hata beklemeye başlar. Review, her değişikliği en az iki kişinin okumasını garanti eder. Bus factor (ekipten kaç kişi ayrılırsa projenin durma noktasına geleceği) review ile yükselir.

Üçüncüsü, öğrenme. Review iki yönlü bir okuldur: junior, senior'ın yorumlarından codebase'in kurallarını öğrenir; senior da junior'ın sorularından neyin açık olmadığını öğrenir. "Bu neden böyle?" sorusu, cevabı koda yorum ya da daha iyi bir isim olarak geri döndüğünde değer üretir.

Dördüncüsü, tutarlılık. İsimlerin, hata yönetiminin, katman sınırlarının ekip içinde aynı kalması. Bunun mekanik kısmı (girinti, naming biçimi) araçların işi; Coding Conventions ve Ekip Standartları serisinin "Coding Convention Nedir, Neden İnsana Değil Araca Bırakılır? Kaynaklar, Seviyeler ve Ekip Kararı" yazısında bunu ayrıntılı konuştuk. İnsana kalan kısım anlamla ilgili: bu isim doğru şeyi mi anlatıyor, bu class doğru module'de mi?

Review Ne Değildir?

Review kalite güvencesinin tek kapısı değildir. Bacchelli ve Bird'ün mülakatlarındaki bir şikâyet tanıdık gelecektir: kodu tanımayan reviewer kolay bulunan şeylere, biçim hatalarına ve bariz sorunlara bakıyor. Bir insanın 400 satırlık bir diff'te her edge case'i zihninde çalıştırmasını beklemek gerçekçi değil. Davranışın doğruluğu önce testlerle, kural ihlalleri analyzer'larla, güvenlik açıklarının bilinen kalıpları tarayıcılarla yakalanır. Review bunların üstüne gelir ve bunların göremediğine bakar: niyet, tasarım, isimlerin anlamı, eksik test edilen davranış. Testin hangi seviyede neyi koruyacağı Test Stratejisi serisinde, CI'daki kalite kapıları CI/CD Temelleri serisinin "Pipeline'da Test: Hızlı Geri Bildirim, Quality Gate'ler ve Flaky Test'ler" yazısında anlatıldı; analyzer ve quality gate'ler Statik Analiz serisinin konusu.

Review bir onay töreni de değildir. LGTM (looks good to me; "bana uygun görünüyor" anlamındaki onay kısaltması) yazıp geçmek, diff'i açmadan onay vermek, review adımını kâğıt üzerinde tutup içini boşaltır. Google'ın hız rehberi bu konuda dengeyi iyi kuruyor: hızlı cevap vermek önemli, ama hızlı cevap düşük standart anlamına gelmez; bir onay, kodun gerçekten standartları karşıladığı anlamına gelmeli.

Review son olarak bir kıdem gösterisi değildir. "Senior onaylamadan merge yok" kuralı iyi niyetle konur ama iki yan etkisi vardır: senior'lar darboğaz olur ve junior'lar başkasının kodunu okuma pratiğinden mahrum kalır. Junior'ın senior kodunu review etmesi, makalelerin gösterdiği eğitim etkisinin en hızlı yolu.

Review'un Alternatifleri ve Tamamlayıcıları

Pull request (PR) ile merge'den önce review, review yapmanın tek biçimi değil. Ekibin bağlamına göre şu seçenekler birlikte ya da onun yerine kullanılabilir:

Pair programming'de kod yazılırken ikinci bir göz zaten oradadır; bu yüzden pair ile yazılmış bir değişikliğin PR review'u çoğu zaman kısa bir kontrolden ibaret olur. Ekiplerin bir kısmı pair ile yazılan kod için ikinci bir onay istemez.

Ship / Show / Ask, Rouan Wilsenach'ın 2021'de martinfowler.com'da yayımladığı bir modeldir. Her değişikliği üç gruptan birine koyarsın. Ship: doğrudan main'e gider, review beklemez; bilinen bir kalıpla yapılmış küçük bir düzeltme gibi. Show: PR açılır ama onay beklenmeden merge edilir; ekip haberdar olur, yorumlar merge'den sonra gelir; yeni bir yaklaşımı ya da ilginç bir refactor'ı göstermek için uygundur. Ask: PR açılır ve geri bildirim gelmeden merge edilmez; yaklaşımından emin olmadığın durumlar için. Model, main'in her an yayınlanabilir olmasını ve güçlü bir otomatik kontrol zincirini varsayar. Wilsenach, her değişiklik için onay zorunluluğunu çoğu zaman bir güven sorununun belirtisi olarak görür; düzenlemeye tabi alanlarda her değişikliğin onaylanması gerekebileceğini de not eder.

Trunk-based development yapan ekiplerde (Git & GitHub serisinin "Git ile Ekip Çalışması: Branch Stratejileri, Rulesets ve Conventional Commits" yazısında anlattık) review bazen merge'den sonra yapılır. Yarım iş feature flag arkasında main'e girer, ekip arkadaşı commit'i sonradan okur, sorun varsa küçük bir düzeltme gelir. Bu modelin önkoşulu, main'e giren her şeyin otomatik testlerden geçmesi ve kullanıcıya açılmasının flag ile kontrol edilmesidir.

Bookstore ödemeye ve siparişe dokunan bir uygulama; ekip iki geliştiriciden oluşuyor ve birbirlerinin kodunu en iyi bilen kişiler yine kendileri. Bu yüzden main'e giden her kod için Ask'te kalıyoruz, ama "her şey için iki gün bekleme" yerine aşağıdaki sözleşmeyi koyuyoruz.

Bookstore Ekibinin Review Sözleşmesi

Sözleşme repo'nun içinde, docs/code-review.md dosyasında duruyor. Wiki'deki bir sayfa unutulur; kodla aynı yerde duran ve PR ile değişen bir dosya güncel kalır:

# Code review at Bookstore

We review to share ownership of the code, spread knowledge and keep the code base easy to change.
Finding bugs is welcome but it is not the main goal: tests and CI are the first line of defence.

## Who reviews

- Every pull request into main needs one approval from someone other than the author.
- Changes to migrations, authorization and payments also need an owner from CODEOWNERS.
- Juniors review too, including seniors' code. Their approval counts like anyone else's.

## How fast

- First response within one working day: a review, a question, or a time when you will look.
- Authors keep pull requests small: about 400 changed lines at most, generated files excluded.
  Bigger changes are split or agreed with the reviewer before the work starts.

## What we leave to tools

- Formatting, naming style and analyzer rules: .editorconfig, dotnet format, ESLint, Prettier.
- Build, tests and vulnerable packages: CI is green before a review is requested.

## What reviewers look at

- Does the change do what the description says? Edge cases, error paths, tests that check behaviour.
- Design: does the code belong here, will the next change be easy?
- Security and data: authorization, input validation, personal data in logs.

## Approving

- The bar is "better than before", not "as I would have written it".
- Small leftovers can be approved with comments the author fixes before merging.

Dosyanın ilk paragrafı bu yazının özeti: review'un amacı bilgi paylaşımı ve değişime açık kod; bug yakalamak testlerin ve CI'ın ilk işi. Bu cümle, bir production hatasından sonra "reviewer neden görmedi?" sorusunu "hangi test ya da kontrol bunu yakalamalıydı?" sorusuna çevirmek için orada.

Onay sayısı bir. İki onay kuralı iki kişilik bir ekipte imkânsızdır; büyüyen ekiplerde de sorumluluğu dağıtır, beşinci yazıda bu konuya döneceğiz. Riskli alanlar (migration, yetkilendirme, ödeme) için ayrıca alan sahibinin onayı isteniyor; bunun GitHub'daki karşılığı CODEOWNERS ve beşinci yazının konusu.

Cevap süresi bir iş günü. Bu sayı Google'ın hız rehberinden geliyor: rehber, odaklanmış çalışmayı bölmeden ama en geç ertesi sabaha kadar cevap vermeyi öneriyor ve cevabın tam bir review olması gerekmediğini söylüyor. "Saat 15'te bakacağım" da bir cevap. Önemli olan PR'ı açan kişinin belirsizlikte beklememesi.

400 satır sınırı, SmartBear'ın Cisco'da yaptığı review çalışmasına dayanıyor: o çalışmada bir seferde 200 ile 400 satırdan fazlasının review edilmesi bulunan kusur oranını belirgin biçimde düşürüyordu. Google'ın rehberi kesin bir sınır koymuyor; yaklaşık 100 satırı genelde makul, 1000 satırı genelde fazla buluyor. Sınırı "üretilmiş dosyalar hariç" diye yazdık, çünkü bir Entity Framework Core (EF Core; .NET'in veritabanı erişim kütüphanesi) migration'ının designer dosyası tek başına 1000 satırı geçebiliyor. Bunu ikinci yazıda gerçek bir PR üzerinde göreceğiz.

Son bölümdeki "approve with comments", Google rehberinde de geçen bir pratik: reviewer, yazarın küçük kalan yorumları düzelteceğinden eminse onayı bekletmez. İki geliştirici farklı saatlerde çalışıyorsa bu tek kural bir günlük beklemeyi ortadan kaldırabilir.

Üretimde Dikkat

Sözleşmeyi koyduktan sonra işlediğini görmek gerekir. Üç işaret izlenmeye değer. İlk review'a kadar geçen süre: bir iş günü hedefinin ne kadar tuttuğunu söyler. PR boyutu: sınırın aşıldığı PR'lar hep aynı kişiden ya da aynı tür işten geliyorsa, sorun disiplin değil işin bölünme biçimidir. Review turu sayısı: üç dört tur süren PR'lar genelde tasarımın PR açılmadan önce konuşulmadığını gösterir. Bunları GitHub verisinden nasıl çıkaracağımızı ve hangi sayıların hedefe dönüştürülmemesi gerektiğini beşinci yazıda göreceğiz.

Ekibin bir kısmı AI coding agent'larıyla kod üretiyorsa review'un yükü artar, çünkü yazılan kodun miktarı artar ama okuyacak insan sayısı aynı kalır. AI'ın yazdığı koda özgü riskleri ve AI reviewer'ların yerini AI Destekli Geliştirme serisinin "AI'ın Yazdığı Kodu Review Etmek ve Doğrulamak: Tipik Hatalar, Checklist ve AI Reviewer'lar" yazısında anlattık; bu seride yalnız yerini işaretleyeceğiz.

Düzenlemeye tabi alanlarda (ödeme, sağlık, finans) "her değişiklik başka biri tarafından onaylandı" bir denetim gereği olabilir. Bu durumda Ship ve Show seçenekleri kapanır, ama yine de PR'ları küçük tutmak ve hızlı cevap vermek beklemenin maliyetini düşürür.

Sık Düşülen Tuzaklar

Review'u tek kalite kapısı yapmak. Production'da bir hata çıktığında ilk soru "kim onayladı?" oluyorsa, ekip kısa sürede review'u savunma amaçlı yapmaya başlar: her PR'a onlarca yorum, her onay saatler sonra. Hata bir sürecin açığıdır; düzeltmesi çoğu zaman eksik bir test ya da eksik bir otomatik kontroldür.

Review'u kıdem göstergesine çevirmek. Onay yetkisini yalnız senior'lara vermek, darboğazı tek kişiye bağlar ve junior'ların okuma pratiğini keser. Junior'ın onayı aynı değerde sayılmalı; emin olmadığı kısımları soru olarak sorabilir.

Bug sayısıyla değer ölçmek. "Bu çeyrekte review'da kaç bug bulduk?" sorusu, reviewer'ları bulunması kolay olanı aramaya iter. Araştırmalara göre değerin büyüğü okunabilirlik ve bilgi transferinden geliyor; bunlar bir sayaçta görünmez.

Biçim üzerine yorum yazmak. Girinti ya da boşluk hakkında bir insan yorumu görüyorsan, eksik olan bir formatter'dır. Reviewer'ın dikkati sınırlıdır ve onu anlama ayırmak gerekir.

Büyük değişikliği sona saklamak. Üç haftalık işi tek PR'da getiren kişi review'un hızlı olmasını bekleyemez. Tasarım, kod yazılmadan önce kısa bir konuşma ya da bir taslak PR ile paylaşılır; review'da çıkan tasarım itirazı en pahalı itirazdır.

Küçük Bir Deneme

★☆☆ Ekibinin son 20 merge edilmiş PR'ındaki review yorumlarını oku ve her birini üç gruba ayır: hata, kod iyileştirme/okunabilirlik, soru veya bilgi. Oranlar Bacchelli ve Bird'ün bulgusuna benziyor mu?

★★☆ Kendi ekibin için Bookstore'unkine benzer bir sayfalık review sözleşmesi taslağı yaz. Onay sayısı, cevap süresi, boyut sınırı ve araca bırakılan kurallar için birer cümle yeterli. Taslağı bir PR olarak aç ve ekibin review'una sun.

★★★ Son bir aydaki PR'larını Ship, Show ve Ask gruplarına ayır. Hangileri gerçekten onay beklemeliydi? Ship ya da Show olabilecek PR'lar için main'in güvende kalmasını hangi otomatik kontroller sağlıyor, hangileri eksik?

Review'un neden yapıldığını ve ekipte nasıl bir sözleşmeyle yürüyeceğini konuştuk. Sözleşmenin en çok emek isteyen maddesi, PR'ların küçük olması. Bir sonraki yazıda topu PR yazarına veriyoruz: büyük bir kupon özelliğini refactor ve davranış değişikliği olarak bölmek, stacked PR'lar, iyi bir PR açıklaması ve review istemeden önce yapılan self-review.