Code Review — özü, kuralları ve ekipte inceleme nasıl yapılır

Code Review Nedir?

Code Review, bir veya daha fazla geliştirici tarafından kaynak kodun projenin ana dalına entegre edilmeden önce incelenmesi sürecidir. İncelemenin amacı sadece hata bulmak değil, aynı zamanda mimariyi iyileştirmek, ekip standartlarına uygunluğu sağlamak ve bilgiyi yaymaktır. Otomatik analizden (linter'lar) farklı olarak, kod incelemesi bir insan tarafından gerçekleştirilir ve okunabilirliği, mantığı ve mimari kararları değerlendirir.

Google Engineering Practices, 2024'e göre Code Review'un iki eşit derecede önemli hedefi vardır: kod tabanını hatalardan korumak ve geri bildirim yoluyla geliştiricileri eğitmek. Mobil projelerde, inceleme mutlaka çerçevelerin (UIKit, SwiftUI, Jetpack Compose), bellek yönetiminin ve ağ isteklerinin kontrolünü içerir.

Code Review GitLab ve GitHub'da sırasıyla Merge Request ve Pull Request aracılığıyla düzenlenir. Her MR/PR bir diff, satır yorumları, tartışmalar ve kontrol durumları içerir. Microsoft Research'e (2023) göre, düzenli inceleme yapan ekipler üretimde %40 daha az kritik hata yayınlar.

Code Review Tarihi: Resmi Denetimlerden Asenkron PR'lara

İlk resmi Code Review 1970'lerde IBM'de adım adım kontrol listeleri ve protokollerle "yapılandırılmış denetimler" olarak ortaya çıktı. 2000'lerde Git ve dağıtık ekiplerin yaygınlaşmasıyla, inceleme Pull Request aracılığıyla asenkron bir formata dönüştü. GitHub (2008) PR'ları ana akım bir uygulama haline getirdi. Modern Code Review, bürokrasi yerine hız ve öğrenmeye odaklanan gayri resmi, asenkron bir süreçtir.

Code Review Türleri: Resmi ve Resmi Olmayan Yaklaşımlar

Code Review, süreç ve katılımcıların dahiliyetine göre dört ana türe ayrılır. Resmi (Asenkron İnceleme) — senkron iletişim olmadan MR/PR aracılığıyla kontrol, dağıtık ekiplerde en yaygın olanı. Gayri resmi — hızlı CR, bir geliştiricinin diğerine yaklaşıp 5 dakika için koda bakmasını istemesidir.

Microsoft Research, 2023'e göre çift programlama (Pair Programming), iki geliştiricinin tek bir ekranda çalışması ve her kod satırının gerçek zamanlı olarak anında incelemeyle yazılmasıdır. Over-the-shoulder — bir geliştirici diğerinin ekranına bakar ve resmi bir süreç olmadan kodu yorumlar. Walkthrough — kod yazarı, bir grup geliştiriciyi değişiklikler arasında yönlendirir ve her kararı açıklar.

Code Review Kontrol Listesi: Kodda Neler Kontrol Edilmeli

Code Review kontrol listesi, inceleyen kişinin kritik açıları kaçırmamasına yardımcı olur. İlk kategori — doğruluk ve mimari: çözüm göreve uygun mu, gereksiz karmaşıklık var mı, desenler doğru seçilmiş mi (MVP, MVVM, Clean Architecture)? İkinci kategori — stil ve biçimlendirme: kod ekip kod stilini (Kotlin Code Style, Swift Style Guide) takip ediyor mu?

Thoughtbot Code Review Guide, 2024'e göre üçüncü blok — test: birim testleri yazılmış mı, sınır durumlarını kapsıyor mu, mevcut testler geçiyor mu? Dördüncü — güvenlik: sabit kodlanmış token, API anahtarı, SQL enjeksiyonu, bellek sızıntısı yok mu? Beşinci — performans: coroutine/RxJava doğru kullanılmış mı, UI iş parçacığı bloke edilmiş mi, aşırı tahsis var mı?

• Mantık — algoritma doğruluğu, sınır durumları ve hata yönetimi
• Mimari — Clean Architecture, MVVM'ye uyum, sorumlulukların ayrılması
• Kod stili — adlandırma, biçimlendirme, projeyle tutarlılık
• Testler — birim testlerinin varlığı, tamamlığı ve yeşil durumu

Code Review Nasıl Yapılır: İnceleyen için Kurallar

Code Review, inceleyen kişinin titizlik ve hız arasında denge kurmasını gerektirir. Ana kural, kodu küçük parçalar halinde incelemektir. Optimum hacim — oturum başına 200–400 satır değişiklik. Google Research'e (2022) göre 500 satırdan fazlasını incelemek etkinliğini kaybeder: kaçırılan hata sayısı değişiklik hacmiyle doğru orantılı olarak artar. İkinci kural — mimariyle başlayın, sonra mantık, sonra ayrıntılar.

SmartBear, 2025'e göre yorumlar spesifik olmalıdır: "bu kötü" değil, "bu yöntem SRP'yi ihlal ediyor — doğrulama mantığını ayrı bir sınıfa çıkarın". Her yorum bir iyileştirme önerisidir, eleştiri değil. Kod doğruysa ancak stil inceleyenin tercihleriyle uyuşmuyorsa — yorumsuz bırakın. İnceleyen kişi, kendisi farklı yazmış olsa bile doğru çözümü onaylamalıdır.

Code Review Nasıl Alınır: Yazar için İpuçları

Code Review almak, kodu incelemekten daha az önemli olmayan bir beceridir. Yazar yorumlara açık olmalı ve bunları çözümü iyileştirmek için bir fırsat olarak görmelidir. İlk kural — yorumları kişisel eleştiri olarak almayın. Code Review kodu kontrol eder, geliştiriciyi değil. İkinci — bir yorum net değilse, hemen düzeltmek yerine açıklama isteyin.

LeadDev, 2024'e göre, incelemeye göndermeden önce yazar kendi kodunu kontrol etmelidir: testleri çalıştırın, kontrol listesini gözden geçirin, hata ayıklama günlüğü veya yorumlanmış kod olmadığından emin olun. MR/PR, değişikliklerin bağlamıyla birlikte net bir açıklama içermelidir. Açıklama ne kadar iyiyse, inceleme o kadar hızlı ve verimli olacaktır.

Code Review'da Psikolojik Güvenlik

Code Review'un önemli bir yönü ekipteki psikolojik güvenliktir. Bir geliştirici sert eleştiri veya alay konusu olmaktan korkarsa, sorunları tartışmak yerine saklar. Google Project Aristotle (2017) şunu gösterdi: yüksek psikolojik güvenliğe sahip ekipler %25 daha üretkendir. Kurallar: kodu eleştirin, yazarı değil; suçlama yerine soru sorun; iyi çözümler için teşekkür edin.

Yazar için önemli kural — yorumları kapatmakta acele etmeyin. İnceleyen kişi değişiklik talep ettiyse, bunlar yapılmalıdır, sadece "tamam" deyip düzeltmeden bırakmayın. Düzeltmeleri yaptıktan sonra — tekrar inceleme isteyin. GitLab ve GitHub, inceleyen kişiyi bilgilendirmek için Re-request Review'ı destekler.

Code Review Otomasyonu: Linter'lar ve Statik Analiz

Code Review otomasyonu, resmi kural kontrollerini ortadan kaldırarak geliştiricilerin yükünü azaltır. Linter'lar (ktlint, SwiftLint, ESLint) kod stilini, biçimlendirmeyi ve temel hataları kontrol eder. Statik analizörler (Detekt, SonarQube, Infer), kod insan incelemesine ulaşmadan önce potansiyel hataları, bellek sızıntılarını ve güvenlik sorunlarını bulur.

detekt Documentation, 2024'e göre CI/CD boru hatlarında, MR/PR oluşturulurken linter'lar ve analizörler otomatik olarak çalışır. Kontrol başarısız olursa, MR Birleştir düğmesiyle engellenir. Bu, insan incelemesine ulaşan kodun zaten temel kontrolleri geçtiğini garanti eder. İnceleyen kişi, boşluklar ve girintiler yerine mimari, mantık ve okunabilirliğe odaklanır.

// Android projesi için detekt yapılandırma örneği
build.gradle.kts (app):

detekt {
    config = files("detekt-config.yml")
    buildUponDefaultConfig = true
    allRules = false
    autoCorrect = true
    debug = false
    parallel = true
}

tasks.named("preMerge") {
    dependsOn("detekt")
    dependsOn("ktlintCheck")
}

Mobil Projeler için Code Review Araçları

Code Review araçları mobil geliştirmede platform tabanlı (GitLab, GitHub, Bitbucket) ve özelleşmiş (Gerrit, Reviewable, Crucible) olarak ikiye ayrılır. GitLab ve GitHub yerleşik işlevsellik sağlar: diff karşılaştırması, satır yorumları, başlıklar, Onay/Değişiklik İsteği durumları, CI/CD entegrasyonu. Araç seçimi ekip büyüklüğüne ve inceleme politikasına bağlıdır.

GitLab Docs, 2025'e göre büyük ekipler (50+ geliştirici) için Gerrit daha sıkı kontrol sağlar: birleştirmeden önce zorunlu CI doğrulaması, ağırlıklı onaylar (Verified + Code-Review) ve ayrıntılı erişim hakları. Küçük ve orta ölçekli ekipler için GitLab ve GitHub en uygun seçimdir: Required Approvals, Code Owners ve Merge Checks yapılandırması dakikalar alır.

• GitLab — Approvals, Code Owners, Merge Checks, MR Templates, yerleşik CI/CD
• GitHub — Pull Requests, CODEOWNERS, Required Reviews, GitHub Actions
• Bitbucket — Mercurial/Git için Pull Requests, Diff yorumlarıyla Approvals
• Gerrit — sıkı doğrulama süreci, ağırlıklı değerlendirmeler, Jenkins entegrasyonu

Code Review'da Sık Yapılan Hatalar

Code Review'da hatalar etkinliğini azaltır ve ekibin motivasyonunu düşürür. Birincisi — aynı anda çok büyük bir değişiklik hacmini incelemek. Bir MR 2000+ satır içerdiğinde, inceleyen kişi hataların %70'ine kadarını kaçırır. İkincisi — kod stili veya mimariye dayanmayan öznel yorumlar. Gerekçesiz "ben farklı yazardım" gibi yorumlar değer sağlamaz.

Google Engineering Practices, 2024'e göre üçüncü hata — testleri görmezden gelmek. Bir MR yeni işlevsellik için testler içermiyorsa, inceleyen kişi bunları talep etmelidir, "sonra" diyerek onaylamamalıdır. Dördüncü — dikkatin dağıldığı gün sonunda veya sprint sonunda inceleme yapmak. İnceleme için en iyi zaman, görevler arasında geçiş yapmadan 30–60 dakika ayrılan günün ilk yarısıdır.

İnceleme güvenliği — beşinci yaygın hata: inceleyenler kodda sabit kodlanmış sırlar, güvensiz JavaScript WebView'lar veya güvenlik açığı bulunan kütüphaneler olup olmadığını kontrol etmez. Mobil projelerde bu kritiktir: bir API anahtarı sızıntısı tüm backend'i tehlikeye atabilir.

Dağıtık Ekiplerde Code Review

Uzak ekipler için Code Review birincil bilgi paylaşım kanalıdır. Net son tarihlerle MR aracılığıyla asenkron biçim önerilir: inceleme için maksimum 24 saat. Karmaşık mimari tartışmalar için ekran kaydı (Loom) kullanın. Dağıtık ekiplerde, zaman dilimi değiştiğinde bağlamın kaybolmaması için MR yorumlarında kararların yazılı olarak belgelenmesi özellikle önemlidir.