Kavramın hikâyesi
Önce iş karşılığını gör, gerektiğinde bağlamı aç.
İlk taramaİşte karşılaşacağın sinyaller
Gerilim ve çözüm · Bölüm 01
Hangi problemi çözer?
Code Review, değişiklik niyeti ile ortaya çıkan diff arasındaki boşluğu konuşulabilir hâle getirir. Reviewer tasarımın mevcut sistemle uyumunu, beklenen davranışı, gereksiz karmaşıklığı, testlerin anlamını ve bakım etkisini sorgulayabilir.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Review hata bulunmayacağını garanti etmez; erken geri bildirim ve paylaşılan bağlam için ek bir kontrol noktasıdır.
Gerçek hayat · Bölüm 02
Gerçek iş senaryosu
SCN-003 bağlamında junior geliştiricinin değişikliği için reviewer, “Bu hata durumunda mevcut kayıt silinebilir; önce davranışı koruyan bir test ekleyip güncelleme yolunu değiştirelim” yorumunu bırakır.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Junior yorumu kişisel eleştiri veya otomatik red olarak okumaz. Beklenen davranışı doğrular, gerekçe belirsizse soru sorar, kod ve testi günceller, yaptığı değişikliği açıklar ve yeniden review ister. Bu akış GitHub'da Pull Request üzerinde yaşanabilir; Code Review kavramı GitHub'a bağlı tanımlanmaz.
Duyacağın bağlam · Bölüm 03
Ekipte bunu nasıl duyabilirsin?
Temsili ekip konuşması: “Bu yorum merge öncesi gerekli bir davranış düzeltmesi; nit değil. Hata durumundaki beklentiyi testte görünür kıldıktan sonra tekrar review isteyelim.”
Beklenti seviyesi · Bölüm 04
Junior hangi seviyede bilmeli?
- Tanı: Reviewer, author, review comment, approval, request changes ve non-blocking suggestion ifadelerini bağlama göre tanır.
- Açıkla: Code Review'ın bir pratik; Pull Request review durumlarının ise platform mekaniği olduğunu ayırır.
- Uygula: Küçük bir diff'in amacını ve temel davranışını kontrol eder; yorumun gerekçesini ve zorunluluk seviyesini netleştirir; düzeltmesini açıklayıp yeniden review ister.
- Şimdilik bilmesi gerekmeyen: Organizasyon çapında review politikası tasarlamak, uzman güvenlik review'u yürütmek ve branch protection yönetmek.
İhtiyacın kökeni · Bölüm 05
Neden ortaya çıktı?
Bir değişiklik çalışıyor görünse bile yazarın kaçırdığı davranış, tasarım, anlaşılabilirlik veya bakım sorunları içerebilir.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Değişikliği kod tabanına almadan önce görünür kılmak, başka bir kişinin bağlamı sorgulamasını ve ortak anlayış oluşmasını sağlar. Farklı araçlar bu ihtiyaca farklı mekanikler sunar; inceleme pratiği tek bir araçla başlamaz veya bitmez.
Ekip etkisi · Bölüm 06
Şirketler neden kullanır?
Ekipler değişiklik kalitesi hakkında ikinci bir bakış almak, alan bilgisini paylaşmak ve merge öncesi kararları kayda geçirmek için Code Review kullanabilir.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
İncelenen alanlar, reviewer sayısı, approval yetkisi, beklenen yanıt süresi ve acil durum istisnaları ekibe göre değişir. Google reviewer rehberi, GitHub Pull Request reviews ve Gerrit üç somut fakat birbirinden farklı uygulama örneğidir.
Karar alanı · Bölüm 07
Trade-off ve bağlam
Code Review ikinci bir bakış ve bilgi paylaşımı sağlarken bekleme ve bağlam değiştirme maliyeti yaratabilir. Çok büyük değişiklikler incelemeyi zorlaştırabilir; aşırı yüzeysel review ise yalnızca süreç tamamlanmış izlenimi verebilir.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Hangi yorumun merge'i engelleyeceği, reviewer uzmanlığı, acil durum akışı ve kabul edilen risk ekip politikasına bağlıdır. Google'ın ilerleme ile kod sağlığını dengeleme yaklaşımı yararlı bir vaka olsa da bütün ekipler için zorunlu kural değildir.
Yanılgı radarı · Bölüm 08
Yaygın yanlış anlamalar
- “Pull Request açıldıysa Code Review yapılmıştır.” Yanlış; Pull Request review için bir yüzey sağlayabilir, fakat etkin bir inceleme ayrıca gerçekleşir.
- “Code Review ile Pull Request aynı şeydir.” Yanlış; biri pratik, diğeri GitHub platform nesnesidir.
- “Approve her repository'de merge izni verir; Request changes her zaman merge'i engeller.” Yanlış; GitHub'daki sonuç repository kurallarına bağlıdır.
- “Review yalnızca style ve typo bulur.” Eksik; tasarım, işlev, karmaşıklık, test ve dokümantasyon da incelenebilir.
- “Otomatik kontroller geçtiyse insan review'una gerek kalmaz.” Desteklenmeyen genelleme; otomasyon ile insan incelemesi farklı soruları yanıtlar.
- “Reviewer çözümü yazmak zorundadır.” Yanlış; reviewer problemi ve gerekçeyi görünür kılabilir, çözüm sorumluluğu ve işbirliği biçimi ekibe göre değişir.
Gerilim ve çözüm1. bölüm
