Skip to main content

> kod_i̇nceleme_paradoksu:_pr_boyutu,_i̇nceleme_derinliği_ve_otomatik_onaylama_(lgtm)

Kod İnceleme Paradoksu: PR Boyutu, İnceleme Derinliği ve Otomatik Onaylama (LGTM)

'10 satırlık PR'a 10 yorum gelirken 1.000 satırlık PR'a 'LGTM (bana uyar)' denmesi' paradoksu neden yaşanır ve ekipler 200-400 satırlık PR sınırını nasıl uygular?

Senior (L5)

ÖZET VE TEKNİK CEVAP

Kod İnceleme Paradoksu (veya Bisiklet Kulübesi Kanunu) insan beyninin bilişsel sınırlarından doğar: 10 satırlık bir PR'da mühendisin beyni tüm bağlamı rahatça kavrar ve değişken ismini bile tartışır; 45 dosyanın değiştiği 1.200 satırlık dev bir PR geldiğinde ise beyin aşırı yüklenir, mühendis kodu yüzeyselce kaydırıp 'LGTM (bana uyar)' diyerek gözü kapalı onaylar. Sonuç olarak en kritik güvenlik açıkları ve mimari hatalar bu dev PR'ların içinde canlıya sızar. Başarılı ekipler katı PR boyutu kalkanları uygular: PR'ları fonksiyonel 200-400 satırla sınırlar, Katmanlı PR (Stacked Diff) tekniğini kullanır ve biçimlendirme işlerini otomatik linter'lara bırakarak insanların yalnızca iş mantığına ve hata senaryolarına odaklanmasını sağlar.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

SmartBear ve Google mühendislik araştırmaları, 400 satırı aşan kod incelemelerinde etkinliğin çöktüğünü kanıtlamıştır: 500 satırın üzerindeki oturumlarda hata yakalama oranı %60'tan fazla düşer ve 60 dakikayı aşan incelemeler ciddi zihinsel yorgunluk yaratır. Katmanlı PR (Stacked PR) iş akışı büyük bir özelliği birbirine bağlı küçük atomik PR'lar zincirine böler (ör. PR 1: Veritabanı Migrasyonu -> PR 2: Servis Katmanı -> PR 3: API Uç Noktası -> PR 4: Arayüz). Her atomik PR 100-200 satır sürer, incelemesi 5 dakika alır ve kodlar feature flag arkasında sürekli canlıya merge edilir.

2. Doğru Kullanım Senaryosu

Tüm günlük yazılım geliştirme iş akışları, takım PR kılavuzları, yeni mühendis oryantasyonu ve kod kalite yönetişimi.

3. Prodüksiyon Arıza Modları

Bir mühendisin kimlik doğrulama ve veritabanı sorgularını içeren 3.500 satırlık dev bir PR açması; yoğun bir takım arkadaşının kodu okumadan onaylaması ve canlıya geçen bir SQL Injection açığının büyük bir veri sızıntısına yol açması.

4. Teşhis ve Telemetri Sinyalleri

Ortalama PR boyutunun 800 satırı aşması; devasa PR'ların 2 dakikadan kısa sürede onaylanması; inceleme yorumlarının mimari veya hata senaryoları yerine sadece boşluk ve formatlama tartışmalarından ibaret olması.

5. Önleme ve Mimari Bariyerler

400 satırı aşan PR'lara otomatik uyarı etiketi koyan CI kontrolleri (DangerJS) kurun; Prettier/ESLint formatlamasını pre-commit kancalarına bağlayarak insanların stil tartışmasını yasaklayın; mühendislere Katmanlı PR (Stacked PR - Graphite) eğitimleri verin.

6. Mimari Ödünleşimler (Trade-offs)

Büyük işleri küçük katmanlı PR'lara bölmek ileri seviye git rebase ve feature flag disiplini gerektirir; ancak kod inceleme hızını 3 katına çıkarır ve hataların %70 daha fazlasını canlıya çıkmadan yakalar.

Vaka İncelemesi (TinyCTO Örneği)

Ortalama PR boyutunun 1.100 satır olduğu bir ekipte kod incelemelerinden sürekli canlıya hata kaçıyordu. Tech Lead katı bir kural getirdi: Graphite kullanılarak fonksiyonel kod farkı 300 satırla sınırlandı. PR inceleme süresi 3 günden 4 saate indi, mühendisler koda derin mimari yorumlar yapmaya başladı ve canlıya kaçan hata oranı 6 ayda %65 azaldı.

İnteraktif Konsept Alıştırmaları

2 Alıştırma
Q1

Kod İnceleme Paradoksu (Code Review Paradox) nedir?

10 satırlık koda 10 eleştirel yorum gelirken, 1.000 satırlık dev koda anında 'LGTM (bana uyar)' denilip gözü kapalı onay verilmesidir.
Q2

Bilimsel araştırmalarla kanıtlanmış ideal PR satır sınırı nedir?

200 ila 400 satır fonksiyonel kod farkı.

Kod İnceleme Paradoksu: PR Boyutu, İnceleme Derinliği ve Otomatik Onaylama (LGTM) — Sıkça Sorulan Sorular

'Katmanlı PR'lar' (Stacked PRs) geliştiricilerin büyük özellikleri küçük parçalarla yazmasını nasıl sağlar?

Birbirine bağlı küçük git dalları (migrasyon -> veri modeli -> API -> arayüz) zinciri oluşturarak; her parça bağımsız incelenir ve feature flag arkasında güvenle merge edilir.

İnsan mühendisler neden kod formatlama veya stil konularında asla yorum yapmamalıdır?

Formatlama CI pre-commit kancalarında Prettier/ESLint ile %100 otomatikleştirilmelidir. İnsan zamanı sözdizimi tartışmalarıyla harcanamayacak kadar değerlidir.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • ▸Code review effectiveness collapses past 400 lines of code due to cognitive overload.
  • ▸Large PRs receive superficial rubber-stamp approvals ('LGTM'), hiding critical bugs.
  • ▸Stacked PRs break large features into atomic 100-200 line reviewable units.
  • ▸Automate 100% of linting and formatting so humans focus strictly on business logic.

Yaygın Yanılgılar

  • ✗Yanılgı: A big 2,000-line PR is fine if it includes unit tests (Gerçek: Reviewers cannot mentally verify test coverage on massive diffs).
  • ✗Yanılgı: Splitting PRs slows down delivery (Gerçek: Small PRs review 3x faster and merge continuously).

Karar Kılavuzu & Önceliklendirme

Enforce a CI warning on all PRs with >400 lines of functional diff. Adopt a Stacked PR tool (Graphite/git-town) across product engineering squads.

Doğrulanmış Kaynaklar & Referanslar