Code review'da değişiklik istendi

Vaka dosyası

Karar vermeden önce kanıtı ayır.

Dört görünüm aynı durumu farklı açıdan açar. Bir görünüm seçmek ilerleme kaydı oluşturmaz.

Görev

Bu durumda neyi değerlendireceksin?

Senaryo sonunda kullanıcı,

01
bir Pull Request'taki değişiklik talebini kişisel eleştiri veya otomatik red olarak okumadan yorumun niyetini ve önemini netleştirebilmelidir.
02
Gerekçeli yanıt verme, gerekli kod ve test değişikliğini yapma, sonucu açıklama, yeniden review isteme ve base branch güncellendiğinde oluşan Merge Conflict riskini görünür kılma adımlarını değerlendirebilmelidir.

Rol ve ekip

Rolün: Bir ürün ekibinde ilk ayındaki stajyer veya junior geliştirici.
Ekip ve ürün bağlamı: Ekip Git repository'sini GitHub üzerinde barındırıyor. Kullanıcının TASK-248 için açtığı Pull Request, checkout zaman aşımı mesajını güncelliyor. @checkout-maintainers değişen alan için review temas noktası. Repository, ticket, kişi, branch ve yorumların tamamı temsili ve kurgusaldır.

Practice, platform and company boundary

Code Review değişikliği başka bir bakışla inceleme pratiğidir. Bu senaryodaki Comment, Approve, Request changes, review thread ve re-request davranışları GitHub'a özgü platform mekanikleridir. Request changes sonucunun merge'i gerçekten engellemesi repository ruleset veya branch protection ayarına bağlıdır.

Yorumu kişisel saldırı olarak okumama, anlamadığında açıklama isteme ve teknik trade-off'larla yanıt verme yaklaşımı Google Engineering Practices içinde açık bir şirket pratiği olarak yayımlanmıştır. Bu senaryo o yaklaşımı yararlı bir örnek olarak kullanır; bütün ekiplerin zorunlu yorum etiketi veya escalation süreci olarak sunmaz. Merge Conflict ise Git davranışıdır; GitHub yalnızca bu durumu görünür kılan yüzeylerden biridir.

Kanıt sınırı

Bildiğin: Pull Request'ın base/head yönü ve ticket kapsamı doğru. Mevcut testler başarılı. Reviewer, non-retryable timeout durumunda yanlış eylem gösterilebileceğini gerekçelendirerek Request changes review'u göndermiş; ayrıca ayrı bir optional adlandırma önerisi bırakmış. Kullanıcı düzeltme üzerinde çalışırken base branch'te aynı fonksiyon değişmiş.
Kasıtlı olarak eksik bırakılan: Repository ruleset'inin Request changes durumunu merge için zorunlu engel yapıp yapmadığı, ekibin review thread'ini kimin resolve ettiği, base branch güncellemesinde merge veya rebase tercih ettiği ve çatışan yeni değişikliğin ürün niyeti başlangıçta verilmez. Bunlar Git'in veya Code Review'ın evrensel kuralları değildir.

Temsili kayıt

Temsili artefactTemsili GitHub Pull Request diff özeti ve review yorumları — özgün ve kurgusaldır; gerçek bir repository, şirket kaydı veya alıntı değildir.

Repository: ornek-magaza/web

Pull Request: #184 — TASK-248 Checkout zaman aşımı mesajını netleştir

Base / head: release/1.4 ← ayse/task-248-timeout-copy

Author: @ayse-y

Review state: Changes requested

Diff özeti: getTimeoutMessage içindeki genel timeout mesajı yeniden deneme eylemi gösterecek biçimde değiştirildi. Mevcut test yalnız retryable timeout durumunu kapsıyor.

Reviewer — required: “isRetryableTimeout(error) helper'ı retryable ve non-retryable timeout'ları ayırıyor. Burada yalnız error.type === "timeout" kontrol edilirse çalışmayacak bir yeniden deneme eylemi gösterebiliriz. Bu helper'ı kullanıp non-retryable durum için de test ekleyebilir misin?”

Reviewer — optional: “getTimeoutMessage ileride başka hata mesajlarını da taşıyacaksa getCheckoutErrorMessage adı daha geniş kapsamı anlatabilir. Bu PR için zorunlu değil; sonraki değişiklikte de ele alınabilir.”

Ownership bağlamı: Reviewer @deniz, checkout alanının review temas noktalarından biridir. Code Owner approval'ının bu repository'de zorunlu olup olmadığı artefact'ta belirtilmemiştir.

Artefact'taki required ve optional etiketleri GitHub'ın zorunlu yorum sözlüğü değildir. Yorum niyetini görünür kılan temsili ekip dilidir.

Bölüm 1 / 2