Etkili Kod İncelemesi Nasıl Yapılır

Etkili bir kod incelemesi, satır satır stil avcılığı değil, risk yakalama işidir: doğruluğu, tasarımı ve bakım kolaylığını sorgulamak, biçimlendirmeyi bir linter'a bırakmaktan çok daha değerlidir. Küçük PR'lar, hızlı dönüş süresi, net "blocking" ve "non-blocking" ayrımı ve 2026'nın AI çöpü dalgasına karşı şüpheci bir bakış, riski gerçekten azaltan dört unsurdur; parantezin yerini tartışmak değil.

Kod incelemesi gerçekte ne için var?

Kod incelemesinin işi doğruluğu, mimariyi ve bakım kolaylığını kontrol etmektir, kod stilini değil. Google'ın reviewer standartları bunu açıkça söyler: bir incelemeci önce tasarımı, sonra işlevselliği, karmaşıklığı ve test kapsamını sorgulamalı; stil ve biçimlendirme ise otomatik araçların işidir, insanın değil. Aynı rehber "Nit:" etiketini önerir: bir yorumun önemsiz olduğunu ve PR'ı bloklamadığını açıkça belirten kısa bir ön ek.

Büyük tasarım kararlarının PR yorumlarında tartışılması zaten geç kalınmış bir savunmadır. Mimariyi değiştirecek bir karar, kod yazılmadan önce bir mühendislik RFC'sinde netleşmeliydi; incelemede "bunu neden böyle kurguladın" sorusu çıkıyorsa, süreç bir adım geriden işliyor demektir.

Sert görüşüm şu: kırk nit yorumu bırakıp bir race condition'ı kaçıran bir inceleme, titiz değil başarısızdır. Yorum sayısı, incelemenin kalitesini değil, incelemecinin neye odaklandığını gösterir. Bir PR'ın altında elli yorum birikmişse ve hepsi virgül ile değişken adıyla ilgiliyse, o inceleme başarılı değil, dikkatin yanlış yere gitmiş hâlidir.

Küçük PR'lar ve hızlı dönüş neden döngü süresini kısaltır

Süreçle ilgili şikâyetlerin çoğu, aslında sürecin hızıyla ilgilidir. Google'ın eng-practices rehberi, bir inceleme isteğine en geç bir iş günü içinde, ideal olarak çok daha kısa sürede yanıt verilmesini; birden fazla inceleme turunun mümkünse tek günde tamamlanmasını şart koşar ve şunu doğrudan yazar: "kod inceleme sürecine dair şikâyetlerin çoğu, süreci hızlandırarak çözülür."

Hız kadar hacim de belirleyici. SmartBear'ın uzun süredir referans alınan araştırması (Cisco kökenli, hâlâ SmartBear'ın amiral verisi), en verimli inceleme aralığının 200-400 satır kod olduğunu, oturumlar 60-90 dakikayla sınırlı tutulduğunda hata bulma oranının %70-90 bandına çıktığını gösteriyor. 400 satırı aşan ya da saatte 500 satırdan hızlı ilerleyen incelemelerde bu oran sert biçimde düşüyor.

Bu iki veriyi birleştirince pratik kural netleşiyor: PR'ları 400 satırın altında tutun, incelemeyi 90 dakikada bitirin, isteği bir iş günü içinde yanıtlayın. Git branch stratejileri arasında trunk-based gibi yaklaşımlar küçük ve sık PR akışını doğal olarak zorlar; büyük feature branch'lerin incelemede tıkanmasının asıl nedeni genelde strateji seçimidir.

Ton ve blocking/non-blocking yorumlar

Bir yorumun ciddiyeti cümlenin sertliğinden değil, etiketinden anlaşılmalı. Yazarın "bu PR'ı mergeleyebilir miyim" sorusuna yorumun kendisi cevap vermeli, incelemecinin ruh haline bakmasına gerek kalmamalı.

Nit: Bu değişkeni `userId` yerine `id` yapabiliriz, zorunlu değil.
Should: Bu fonksiyon 120 satır; en azından doğrulama kısmını ayırmayı düşünelim.
Must: Bu sorgu kullanıcı girdisini escape etmiyor, SQL injection riski var — mergeden önce düzeltilmeli.

"Must" işaretli bir yorum çözülmeden hiçbir PR merge edilmemeli; "Nit" işaretli bir yorum hiçbir PR'ı bloklamamalı. Aradaki boşluk incelemecinin insafına kalınca, aynı ekipte biri "harika iş" yazıp diğeri virgül hatasında ısrar ediyor demektir; bu tutarsızlık, incelemenin kendisinden daha çok yıpratıyor.

Yazarın sorumlulukları

İyi bir inceleme, iyi bir PR ister. Merge etmeden önce kendi diff'inizi okuyun; birçok "Nit" yorumu, yazarın kendi kendine yapacağı bir gözden geçirmeyle zaten ortadan kalkar. Temiz kod prensiplerini bir kontrol listesi gibi kullanıp isimlendirme ve fonksiyon uzunluğu gibi konuları PR açmadan önce halletmek, incelemecinin zamanını gerçek risklere ayırmasını sağlar.

Açıklama metnini boş geçmeyin: ne değişti, neden değişti, nasıl test edildi yazın. Test eklemeden gönderilen bir PR, incelemeciyi kör uçuşa zorlar; işe yarayan unit testler doğruluğu incelemecinin gözünden değil, çalıştırılabilir kanıttan doğrular. Geri bildirime savunmacı değil meraklı yaklaşın: "neden böyle" sorusu bir suçlama değil, genelde gerçek bir bilgi eksikliğidir.

Büyük bir değişikliği tek seferde açmak yerine, mantıksal olarak bağımsız parçalara bölüp art arda gönderin. İncelemeci her PR'ı ayrı ayrı ve hızlı değerlendirebilirse, sizin de beklemeniz kısalır; bu, hem yazarın hem incelemecinin çıkarınadır, tek taraflı bir fedakârlık değildir.

AI tarafından üretilen PR'ları şüpheyle incelemek

Temmuz 2026 itibarıyla AI çöpü artık teorik bir risk değil, günlük bir operasyonel yük. Bir açık kaynak bakımcısı, on beş günlük bir pencerede aldığı 136 PR'ın %71'inin düşük kaliteli, AI üretimi "çöp" olduğunu bildirdi. CodeRabbit'in kendi araştırması, AI üretimi PR'ların insan yazımı PR'lara göre yaklaşık 1,7 kat daha fazla sorun içerdiğini buldu — bu satıcı tarafından yapılmış bir araştırma olduğu için tarafsız bir kaynak gibi okunmamalı, ama yönü net.

Hacim öyle bir noktaya geldi ki GitHub'ın PR'lar için bir "kill switch" değerlendirdiği Şubat 2026'da The Register tarafından yazıldı; curl projesi de aynı gerekçeyle herkese açık bug bounty programını kapattı. Bu ortamda bir PR'ı "AI yazdı" diye farklı bir kalite standardıyla değil, ama kesinlikle daha şüpheci bir varsayımla incelemek gerekiyor: kod çalışıyor görünüyor olabilir, ama neden bu şekilde yazıldığını kimse açıklayamıyor olabilir.

Pratikte fark yaratan iki refleks: diff'in "mantıklı" görünmesini yeterli saymayıp her hata yolunu ve kenar durumunu ayrı ayrı sorgulamak, ve yazarın (insan ya da ajan) diff'i savunabildiğinden emin olmak. AI kod asistanı kullanırken yapılan hatalar ve AI çöpünün açık kaynak güvenliğini nasıl zorladığı üzerine yazdıklarımız, bu şüpheciliğin nereden geldiğini daha ayrıntılı anlatıyor.

İnceleyen için kontrol listesi ve yorum ciddiyeti kuralı

Kontrol listesi uzun tutulmamalı; amacı ezberlemek değil, dikkati doğru sıraya sokmaktır. Her incelemede aynı sırayla sorun: önce risk, sonra stil.

• Bu değişiklik doğru mu çalışıyor, kenar durumları düşünülmüş mü?
• Güvenlik açığı, veri sızıntısı ya da yetkilendirme hatası var mı?
• Tasarım sistemin geri kalanıyla tutarlı mı, gereksiz karmaşıklık eklemiş mi?
• Testler gerçek davranışı mı doğruluyor, yoksa sadece kapsamı mı dolduruyor?
• Değişiklik geri alınabilir mi, yoksa üretimde tek yönlü bir kapı mı açıyor?
• Stil ve biçimlendirme sorunları varsa, bunlar zaten bir linter'a devredilebilir mi?

Bu üç etiketli sistem karmaşık değil, ama tutarlı uygulanınca hem yazarın savunmaya geçmesini önlüyor hem de incelemecinin gerçekten önemli olanı gizlemeden söylemesini kolaylaştırıyor.

Sıkça Sorulan Sorular

Kod incelemesinde en sık yapılan hata nedir?

Stil ve biçimlendirmeye, doğruluk ve tasarımdan daha fazla zaman ayırmak. Bu sorunların çoğu bir linter ve formatter ile otomatik çözülür; insan dikkatini oraya harcamak gerçek riskleri kaçırma ihtimalini artırır.

Bir PR ne kadar sürede incelenmeli?

Google'ın rehberine göre en geç bir iş günü içinde, mümkünse çok daha kısa sürede. Birden fazla tur gerekiyorsa bunların da aynı gün içinde tamamlanması hedeflenmeli; gecikme, incelemeyle ilgili çoğu şikâyetin asıl kaynağıdır.

AI'nın yazdığı kodu nasıl farklı incelemelidir?

Standardı değil, varsayılan güveni değiştirin. Diff mantıklı görünse bile her hata yolunu ayrı sorgulayın ve yazarın değişikliği savunabildiğinden emin olun; 2026'daki AI çöpü verileri, "görünüşte doğru" ile "gerçekten doğru" arasındaki farkın eskisinden daha büyük olduğunu gösteriyor.

Nit yorumları tamamen yok mu sayılmalı?

Hayır, ama bloklamamalı. Nit etiketiyle işaretlenmiş bir öneri değerli olabilir; sadece yazarın onu uygulayıp uygulamama kararını kendisine bırakmalı ve merge'ü geciktirmemeli.