Yıllarca kod yazıp incelediğimde, daha iyi çekme istekleri oluşturmak ve kodu daha verimli bir şekilde incelemek için birkaç sır öğrendim.
Tüm bu sırları yeni kitabım Pull İstekleri ve Kod İncelemesi'ne aktardım, ancak burada geliştirici faaliyetlerinizde zaten kullanabileceğiniz bu 13 ipucunun yer aldığı bir önizleme bulacaksınız.
Daha fazla ipucu düşünebilir misiniz? Yorumlarda paylaşın 😉
PR taslağı, henüz özelliğiniz üzerinde çalışırken fikirlerinizi düzenlemenize ve ilerlemenizi belgelemenize yardımcı olur.
Hızlı ve etkili bir inceleme almanın en iyi yolu, PR'nizi küçük ve iyi belgelenmiş (gerekli tüm bağlamla birlikte) tutmaktır. Ayrıca şimdi harika kodlar sunarak gelecekteki PR'ler için şansınızı artıracaksınız!
Tüm bu ipuçlarını ve daha fazlasını, daha fazla gerçek hayattan örnekler ve eyleme dönüştürülebilir bilgiler içeren ücretsiz kitabım Pull request and Code Review: Best Practices for Developers, Junior'dan Team Lead'e kadar bulabilirsiniz.
Kendinizi incelemecinin yerine koyun, soruları tahmin edin ve onlara yardımcı olabileceğini düşündüğünüzde kendi yorum kodunuzu kullanın.
PR'ınızı tüm dünyaya atamayın. Onay için çok uzun süre beklemeden, ilgili incelemeyi almak için incelemecilerinizi dikkatli bir şekilde seçin.
Geri bildirime açık olun, açıklama isteyin, aynı fikirde olmadığınızı söyleyin (saygıyla) ve yorumlara her zaman yanıt verin.
Herkesin gözden geçirmesi gereken çok sayıda PR'si vardır ve bunun için çok az boş zamanı vardır. Diğer PR'leri incelerseniz, sizinkini de inceleme şansınızı artırırsınız.
Kıdemsiz bir geliştirici olarak, kodun bir kısmını anlamadığınızda bunu başkalarına bildirebilirsiniz; çünkü bunun ekipteki herhangi bir geliştirici tarafından anlaşılması gerekir.
Bununla ilgili daha fazla bilgiyi yazımda Kıdemsiz bir geliştirici olarak kod incelemesi nasıl yapılır? .
Kod incelemesinin amacı hataları ve uç durumları kontrol etmek ve uygulamaya meydan okumaktır. Ne küçük formatlama ya da stil tercihleri hakkında ayrıntıya girmek için ne de büyük ölçekli mimari tartışmalar için kullanılmamalıdır.
"Yapmalısın" yerine "neden olmasın"ı kullanın, açık ve olumlu olun ve değişiklik istediğinizde daima bir alternatif önerin.
Tüm yorumlar bir değişiklik gerektirmez ve PR'nin onaylanması için istenen tüm değişiklikler gerekli değildir. Değişiklik acil değilse yorumunuzda net olun.
İncelemenizi herkese açık hale getirmeden önce her yorumu yeniden okuyun: kullandığınız üslubu kontrol edin ve PR gönderen kişiye yardımcı olacak tüm bağlamı sağladığınızdan emin olun.
İnceleyicinin, istediğiniz tüm değişiklikleri yaptıktan sonra iki gün onayınızı beklemesini istemezsiniz. İncelediğinizde, tüm düzeltmeler yapılır yapılmaz onaylayacağınızı varsayalım.
Bir yorum dizisi PR'nizde bir tartışma haline geldiğinde, onu kesip tartışmaya başka bir yerde, örneğin bir Slack başlığında devam etmeyi önerseniz iyi olur. Gerekirse bir toplantı düzenleyin ve/veya üçüncü bir tarafı dahil edin.
Bu kadar! Bu ipuçları hakkında ne düşünüyorsunuz? Diğer geliştiricilere vermek istediğiniz bir ipucunu düşünebilir misiniz?
Bunları burada yorumlarda paylaşın 👇
Bu ipuçlarını beğendiyseniz ve daha fazlasını öğrenmek istiyorsanız Çekme İstekleri ve Kod İncelemesi kitabıma göz atın; ücretsizdir!
Burada da yayınlandı.