Kod İncelemelerini Hızlandırmak
Kod incelemeleri acı verici olabilir. Yazılım mühendisleri genellikle inceleme sürecinin yavaş olduğundan, aşağı akış görevlerini geciktirdiğinden ve siz bir açık çekme isteği (PR) ile bir sonraki göreviniz arasında gidip gelirken bağlam değiştirmeye yol açtığından şikayet eder. Kod incelemeleri ayrıca kusur bulma ve bisiklete binme ile dolu olabilir ve bu da onu ilgili herkes için kötü bir deneyim haline getirir.
Bu sorunu çözmek için bazı mühendisler, çekme taleplerinden ve kod incelemelerinden tamamen kurtulmamızı önerecek kadar ileri gittiler. Bu, startuplarda küçük ekipler için işe yarayabilir, ancak bunun herkes için, özellikle kurumsal düzeydeki şirketler için doğru çözüm olduğunu düşünmüyorum.
Bunun yerine, kod inceleme sürecini hem kod yazarı hem de kod gözden geçiren için daha iyi bir deneyim haline getirmenin birçok yolu vardır. Bu en iyi uygulamalardan yedisini birlikte ele alalım.
#1: Çekme İsteklerini Küçük Tutun (Pull Request,PR : Çekme İsteği)
Her mühendis, 1000’den fazla kod satırı değiştirilmiş çekme isteklerini gözden geçirmekten korkar. Bu incelemelerin tamamlanması saatler alabilir ve çoğu zaman, incelemeyi yapan kişinin kodu dikkatlice gözden geçirmek yerine gözden geçirmeye başlamasıyla sonuçlanır.
Çözüm, çekme isteklerinizi küçük tutmaktır. Küçük PR’leri gözden geçirmek daha kolay ve daha hızlıdır çünkü gözden geçirenin tüm değişikliklerin birlikte nasıl çalıştığına dair zihinsel bir model oluşturmak için fazla zaman harcamasına gerek yoktur. Ayrıca daha az kod değiştirilir, bu da umarım daha az hataya, daha az yoruma ve yazar ile gözden geçiren arasında daha az ileri ve geri dönüşe eşittir.
PR’larınızı küçük tutmak ilk başta zor görünebilir, ancak işinizi küçük görevlere bölerseniz ve odaklanmaya devam ederseniz bu yapılabilir. Yeni özellikler uygularken veya hataları düzeltirken büyük yeniden düzenleme işlemleri yapmayın. Yeni özelliklerin küçük parçalarını üretim uygulamasında görünmeden ana dalda birleştirebilmek için kodunuzda özellik bayraklarını kullanın.
PR’larınızı küçük tutun. Yorumcularınız minnettar olacaktır.
#2: Çekme İsteği Şablonlarını Kullanın
Başka bir sıkıntı, herhangi bir bağlam olmaksızın bir çekme talebini gözden geçirmesi isteniyor. Hiçbir açıklama yapılmadan kucağınıza bir PR düştüğünde, genellikle “Bu PR ne için? Bu hangi sorunu çözüyor? Bununla ilgili bir görev var mı? Bu özel yaklaşım neden benimsendi?”
Çekme isteği şablonu , her yeni çekme isteğinde varsayılan metin olarak ayarlayabileceğiniz küçük, yapılandırılabilir bir formdur . PR şablonu, kod yazarından PR’leri için ilgili ayrıntıları sağlamasını ister. Tipik olarak, bir PR şablonu, ne yaptığınızın ve neden yaptığınızın kısa bir açıklamasını, görev biletine bir bağlantı ve değişiklikleri doğrulamak için bir test planı ister.
İyi PR şablonları ayrıca genellikle kod yazarının temel özelliklerin hiçbirini kaçırmadığından emin olmak için geçmesi gereken kısa bir kontrol listesi içerir. Bu kontrol listesi, birim testleri, dokümanlar, uluslararasılaştırma, tarayıcılar arası destek ve erişilebilirlik gibi öğeleri içerebilir.
Aşağıda, tüm depolar için kullanılabilecek, sevilen bir örneği görebilrisiniz.
#3: Tepki Süresi SLA’larını Uygulayın
Çekme isteklerinin istediğinizden daha uzun süre incelenmediğini fark ederseniz, ekip olarak yeni bir çekme isteğinin ne kadar hızlı incelenmesi gerektiğine ilişkin beklentileri belirlemenin şimdi tam zamanı. Başka bir deyişle, bir PR’nin alınması gerekmeden önce var olabileceği maksimum süre nedir? Bir saat? İki saat? 24 saat?
Bu soruya vereceğiniz cevap muhtemelen ekibinizin büyüklüğüne bağlı olacaktır. Ayrıca, ekibinizden gelen dahili çekme isteklerine karşı diğer ekiplerden gelen harici çekme istekleri için farklı bir cevabınız olabilir.
Bir yanıt süresi SLA’sı (hizmet düzeyi sözleşmesi) seçerken, doğru dengeyi bulmak isteyeceksiniz. Yeni bir PR yayınladığınızda herkesin yaptıklarını hemen bırakıp kodunuzu gözden geçirmesini beklemek mantıklı değil, ancak PR’lerin saatlerce gözden geçirilmemesini de istemiyorsunuz.
Takım arkadaşlarınızın akış durumuna geçmesini sağlayan doğru dengeyi bulun. Kendi kodları üzerinde çalışabilmeli ve ardından gün boyunca doğal durma noktalarında PR’leri gözden geçirebilmelidirler.
Şahsen, dahili ekip PR’leri için iki saatlik yanıt süresi SLA’sı ve harici ekip PR’leri için 24 saatlik yanıt süresi SLA’sı olmasını seviyorum.
Sizin ve takım arkadaşlarınızın ne karar vereceğinden bağımsız olarak, bir takım anlaşmasına sahip olmak, birbirinizi sorumlu tutmanıza olanak tanır. Herkes belirli bir SLA’yı kabul ettiyse ve bu süre PR’larınızdan biri için geçtiyse, insanları bu konuda rahatsız etmeye başlamanın uygun olduğunu bilirsiniz.
#4: Genç ve Orta Düzey Mühendisleri Eğitin
Eğitim fırsatları her yerde. Daha az deneyimli mühendislere rehberlik etmek, onlara çalıştıkları teknolojiler ve diller hakkında bilgi vermekten fazlasını içerir. Ayrıca, onlara etkili bir kod incelemesinin nasıl yapılacağı gibi yumuşak becerilerin öğretilmesini de içerir.
Bir kod incelemesi sırasında ne aradığınızı takım arkadaşlarınıza öğretin. Neyin önemli olduğunu ve neyin olmadığını anlamalarına yardımcı olun. Engelleyici olmayan önerilerin önüne “nit” koyarak olduğu gibi, kod inceleme yorumlarında onlara etkili bir şekilde nasıl iletişim kuracaklarını öğretin .
Nasıl daha etkili bir kod gözden geçirici olunacağına dair birçok harika kaynak var. Google’ın Kod İnceleme Geliştirici Kılavuzu baştan sona okumaya değer. Kılavuz, hem kod yazarı hem de kod gözden geçiren için mükemmel tavsiyelere sahiptir. Daha arsız bir kaynak için, Kod Gözden Geçiricinizin Size Aşık Olmasını Nasıl Sağlarsınız, çekme istekleri oluşturan geliştiriciler için kolayca en iyi (ve eğlenceli) tavsiyelerden bazılarıdır.
#5: Sürekli Entegrasyon Ardışık Düzenlerini Ayarlayın
Yorumların çoğu “Eksik noktalı virgül” veya “Girinti burada görünmüyor” gibi şeyler olduğunda kod incelemeleri sıkıcı hale gelir. Kod biçimlendiricilerin ve kod linterlerinin sizin için halledebileceği şeyler üzerinde kod incelemeleri sırasında zaman harcamayın. Bilgisayarların önemsiz şeyleri otomatikleştirmesine izin verin, böylece bir insan gerektiren önemli şeylere odaklanabilirsiniz.
JavaScript projeleri için, deponuz için Prettier gibi bir biçimlendirici ve ESLint gibi bir linter yapılandırmak kolaydır . Daha sonra Travis CI , CircleCI , GitHub Actions veya GitLab CI/CD gibi bir şey kullanarak deponuz için sürekli entegrasyon ayarlayabilirsiniz .
CI işlem hattınız, birim testlerinizle birlikte bu biçimlendirme ve astarlama görevlerini sizin için çalıştıracaktır. CI ardışık düzeni bir çekme isteğinin herhangi bir adımında başarısız olursa, bu çekme isteğinin birleştirilmesini engeller.
Artık kod incelemesinin birkaç önemli bölümünü otomatikleştirdiniz ve saatlerce tasarruf ettiniz.
#6: Çekme İsteği İnceleme Uygulamalarını Kullanın
Bazen bir çekme isteğindeki kodu gözden geçirmek değil, aynı zamanda işlerin iyi göründüğünü doğrulamak için uygulamadaki değişiklikleri manuel olarak görüntülemek de gereklidir. Karmaşık kurulum adımlarına sahip uygulamalarda, başka birinin kodunu aşağı çekip yerel olarak makinenizde çalıştırmak beş dakika ile bir saat arasında sürebilir. Ne baş ağrısı!
Her yeni bir PR oluşturulduğunda kodunuzu kısa ömürlü bir test ortamına otomatik olarak dağıtmak için çekme isteği inceleme uygulamaları kullanılır. Bu, gözden geçirenlerin, kodu indirip makinelerinde yerel olarak çalıştırmalarına gerek kalmadan UI değişikliklerini kolayca incelemesine olanak tanır. Bu sadece zamandan tasarruf etmekle kalmaz, aynı zamanda kolaylaştırarak gözden geçirenleri incelemelerinde daha kapsamlı olmaya teşvik eder.
#7: Kod Değişikliklerinizi Görselleştirmek için Diyagramlar Oluşturun
GitHub veya GitLab’da kodu gözden geçirirken dosyalar genellikle alfabetik sırayla gösterilir. Nispeten küçük PR’ler için bu bir sorun olmayabilir. Ancak bir PR ile ilgili düzinelerce dosya olduğunda, daha büyük bir resimde nasıl bir araya geldiklerini görebilmeniz için bazen bu değişiklikleri mantıksal olarak gruplandırılmış olarak görmek yardımcı olur.
CodeSee İnceleme Haritaları , hangi dosyaların değiştirildiğini ve bu değişikliklerin yukarı ve aşağı bağımlılıklarını nasıl etkilediğini görselleştirmenize yardımcı olur. PR’nize otomatik olarak bir yorum ve diyagram göndermek için GitHub ile entegre olurlar. Hatta kod gözden geçirenlerinize yol göstermesine yardımcı olması için kodunuz için etkileşimli turlar oluşturabilirsiniz. Hepsinden iyisi, CodeSee Haritalar açık kaynaklı kuruluşlara ve bunların halka açık havuzlarına ücretsizdir.
Sonuç: Kod İncelemede Zamanınızı Önemli Şekilde Azaltmanın 7 Yolu
Özetlemek gerekirse, kod inceleme sürenizi önemli ölçüde azaltmak için yedi ipucu:
- Çekme isteklerini küçük tutun.
- Bir gözden geçirenin ihtiyaç duyacağı tüm bağlamı sağlamak için çekme isteği şablonlarını kullanın.
- Yanıt süresi SLA’larını uygulayın.
- Bir kod incelemesi sırasında aradığınız temel şeyler konusunda genç ve orta düzey mühendisleri eğitin.
- Linterler, biçimlendiriciler ve birim testleri çalıştırmak için CI işlem hatlarını ayarlayın.
- Kullanıcı arabirimi değişikliklerini kolayca inceleyebilmek için çekme isteği inceleme uygulamalarını kullanın.
- CodeSee İnceleme Haritaları gibi bir araç kullanarak kod değişikliklerinizi görselleştirmek için diyagramlar oluşturun.
Bu makaleyi okuduğunuz için teşekkürler! Bana destek olmak isterseniz;
Beni Twitter, Linkedin ve YouTube‘da takip edin.
Kısa bir yorum bırakmayı UNUTMAYIN!
