Kod İnceleme Kültürü ve PR En İyi Uygulamaları

Kod incelemesi kapı bekçiliği yapmak değildir; ekiplerin birlikte öğrenmesini, sahipliği devretmesini ve kaliteyi yüksek tutmasını sağlar. İyi bir inceleme kültürü tüm ekibi ileri taşır; kötü bir inceleme ise darboğazlara ve kırgınlığa yol açar.

1) Küçük tutun (mümkünse 400 satırın altında). 2) Açık bir açıklama yazın: neden, ne ve nasıl sınanacağı. 3) İlgili bileti bağlayın. 4) Kullanıcı arayüzü değişiklikleri için ekran görüntüleri veya videolar ekleyin. 5) İnceleyenleri istemeden önce değişiklik farkınızı kendiniz inceleyin.

Gönderimlerle aynı geleneksel ön ekleri kullanın: feat: add user profile page, fix: handle 404 in fetch wrapper, refactor: extract Avatar component. Birçok ekip değişiklik günlüklerini bunlardan oluşturur.

Çoğu ekip bir PR şablonu kullanır; şablonu .github/pull_request_template.md konumuna yükleyin.

İnceleyenleri istemeden önce kendi değişiklik farkınızı satır satır gözden geçirin. Açıkça anlaşılmayan seçimleri açıklayan yorumlar ekleyin. Çoğu zaman başkasının bulmasını beklemeden kendi hatalarınızı yakalarsınız.

2000 satırlık bir PR nadiren ayrıntılı biçimde incelenir. Şu şekilde bölün: 1) yeniden düzenleme (davranış değişikliği yok), 2) yeni davranış, 3) kullanıcı arayüzü iyileştirmeleri. Her birini incelemek ve geri almak daha kolaydır.

Emirler yerine sorularla ifade edin: 'Bunu bir kancaya çıkarmak hakkında ne düşünüyorsunuz?' demek, 'bunu çıkarın' demekten daha etkilidir. Mutlaka düzeltilmesi gerekenlerle olsa iyi olacakları birbirinden ayırın. Şu ön ekleri kullanın: nit:, question:, blocker:.

'Bu kafa karıştırıcı' demek yazara hiçbir şey anlatmaz. 'Erken dönüşü anlamak için bunu 3 kez okumam gerekti; bir koruma koşuluna çıkarabilir miyiz?' demek, yazarın üzerinde çalışabileceği bir yön verir.

Akıllıca çözümler, iyi adlandırmalar ve yararlı sınamalar hakkında olumlu yorum yapın. Bu, söz konusu kalıpları teşvik eder ve geri bildirimin geri kalanını daha yumuşak hâle getirir. Yalnızca eleştiri alan PR'lar çekişmeli bir ortam hissi verir.

Prettier biçimlendirmeyi, ESLint ise biçim kurallarını ele alır. Sekmelerle boşluklar arasındaki fark gibi konular için inceleme döngülerini boşa harcamayın. Bir biçim kuralı sürekli gündeme geliyorsa onu kod denetleyicisine ekleyin.

Sınamalar da koddur. Yeni kodun sınamaları olduğundan emin olun. Sınamaların gerçekten doğru şeyi çalıştırdığını kontrol edin; yanlış şeyi doğruladıkları için bozuk durumda bile başarılı olan birçok sınama vardır.

Her yoruma, yalnızca başparmak yukarı emojisiyle olsa bile, yanıt verin. Katılmadığınız önerilere karşı çıkın (kodu siz yazdınız; bağlamı siz daha iyi biliyor olabilirsiniz). Çözülmüş konu dizilerini çözüldü olarak işaretleyin. Kapsam değişirse PR açıklamasını güncelleyin.

Bir iş günü içinde inceleyin. Güncelliğini yitirmiş PR'lar bağlamı kaybeder; yazar başka bir işe geçmiştir ve dalın yeniden tabanlanması gerekir. Bir hafta bekleyen büyük PR'lar her zaman çetin birleştirmelere dönüşür.

GitHub'ın öneri özelliği, yazarın bir düzeltmeyi tek tıklamayla kabul etmesini sağlar. Düzyazı içinde 'bu satırı X olarak değiştirin' demekten çok daha hızlıdır.

Şu koşullarda onay verin: kod doğruysa, sınamalar başarılıysa, değişikliği anlıyorsanız ve birleştirmek güvenliyse. Onay vermek, sonucu birlikte sahiplenmeniz anlamına gelir. Sorgulamadan onaylamayın; okumadıysanız bunu açıkça söyleyin.

Yazar: ekran görüntüleri ve sınamalar içeren küçük, iyi açıklanmış PR'lar hazırlayın. Önce kendiniz inceleyin. İnceleyen: yapıcı, soru temelli geri bildirim verin. Mutlaka düzeltilmesi gerekeni küçük ayrıntıdan ayırın. İyi noktaları takdir edin. Biçimi atlayın; bunu araçlar ele alsın. Bir gün içinde inceleyin. Yalnızca anladığınızda onay verin. PR şablonları süreci standartlaştırır. İncelemeler kapı bekçiliği değil, iş birliğidir.