Kod İnceleme ne zaman yapılır

Kısa bir süre önce bir scrum sürecine geçtik ve sprintlerin içindeki görevler ve kullanıcı hikayeleri üzerinde çalışıyoruz. Daha az göz korkutucu hale getirmek için kod incelemelerini sık sık yapmak istiyoruz. Bunları bir kullanıcı hikayesi düzeyinde yapmayı düşünüyoruz, ancak bunu hesaba katmak için kodumuzu nasıl şekillendireceğimizden emin değiliz.

VS ve TFS 2010 kullanıyoruz ve 6 kişilik bir ekibiz.

Şu anda özellikler için şubeliyiz ancak scrum için dallamaya geçmeye çalışıyoruz.

Şu anda raf kümeleri kullanmıyoruz ve başka teknikler varsa gerçekten uygulamak istemiyoruz.

Kullanıcı hikayesi başına kod incelemesini uygulamayı nasıl öneriyoruz?

Kullanıcı öykülerinin doğasına bağlıdır.

Her kullanıcı hikayesi için bir şube oluşturmak etkili olabilir, farklı hikayelerdeki ilerleme görülebilir, ihtiyaç duyulursa etrafından geçilebilir, hikayeler sprint'te tamamlanmazsa ilerleme sonraki sprint için dalda kalabilir . Son incelemeler daha sonra kullanım öyküsü dalında bir kullanıcı öyküsünün sonunda gerçekleştirilebilir ve kod standartlara uygunsa birleştirilebilir.

Bu şekilde çalışabilmek için bir sprint sonunda yönetilemeyen birleştirme görevlerini önlemek için hikayelerin ince taneli olması gerekir. Küçük hikayeler, diğer kullanıcı hikayeleri üzerinde çalışan geliştiricilerin sürekli olarak (temel VCM) çekmesi gereken sprint aracılığıyla geliştirici dalının düzenli olarak güncellenmesine izin verecektir.

Bu, bazı durumlarda otomasyon senaryoları ile çözülebilen şubeleri sürekli olarak oluşturmak ve birleştirmek zorunda olan süreç ek yükleri yaratır, ancak ekibin hala VCS ile çok rahat olması gerekir.

Bir sprint sonunda geliştirici dalınızı entegrasyon / üretim vb.

Ayrıca herkesin bir dev dalında çalıştığı ekiplerde çalıştım, bir kullanıcı hikayesini tamamladıktan sonra kod inceleme ve test için o şubeye itilir ve birisi dev yapısını bozan bir şey iterse, takım biralarını almak zorunda kalırlar.

Kodu gözden geçirmenin en etkili yolu, ayağa kalkmak, birini bulmak ve gelip kodu yeni oluşturduğunuz kodu tartışmaktır.

Kodunuzu yerel olarak inceleyecek birini bulamadığınız sürece bir araç kullanmayın.

Eşleştirerek kod incelemelerini tamamen önleyebilirsiniz.

Takımdaki herkes yerel mi? Öyleyse, kod teslim edilmeden önce birisinden gelip bir göz atmasını isteyin. Yerel değil mi? En sevdiğiniz ekran paylaşım programını başlatın ve birini arayın. Ben şahsen bunu sık sık yaparım. Bazen sadece "Hey, bak ne yaptım!"

Bu ad-hoc kod incelemeleri tarzını, birisinin ayakta kaldığı ve kodunu ekibe sunduğu stile tercih ederim. Ad-hoc incelemeleri, gariplik olmadan eşleştirmenin birçok faydasını (hepsi?) Verebilir. Ayrıca, "gözden geçirenin" soru sorma ve resmi olmayan bire bir ortamda iyileştirme önerme olasılığı daha yüksektir.

Kod incelemesinin SCRUM'un resmi bir parçası olmadığına inanıyorum, ancak revizyonlar kaliteye ulaşmak ve projelerinizi / ekibinizi geliştirmek için bağımsız bir taktiktir.

Bu nedenle, PROJE kalitesini sağlamak / geliştirmek ve programa uymak için SCRUM (veya başka bir çevik geliştirme metodolojisi) kullanırsınız. Ayrıca, iyi bir taktik, normal KG / test görevlerinizden bağımsız olarak ürün revizyonu (kod değil) yapmaktır. Bu etkinlik ekibinizin / ortaklarınızın / müşterilerinizin / kitlenizin önünde yapılabilirse daha iyi olacaktır.

Kodunuzu (veya diğer spesifik) revizyonları esas olarak TAKIM'ınızı iyileştirmek için sonuçları orta / uzun vadede beklemeniz gerekir. Bu, PROJELERİNİZİ etkiler, ancak uzun vadede TAKIM iyileştirmenizin bir ürünü olarak.

Yani, sorunuzu cevaplamak için, SCRUM'dan çok fazla zorlamaya çalıştığınıza inanıyorum ve revizyonları sadece olduğu gibi düşünmelisiniz.

Kodunuzu kontrol etmeden önce kod incelemeleri yapmak açık değil mi?

TFS, GIT gibi çalışmaz, bu nedenle bir şubeye veya gövdeye kodu her kontrol ettiğinizde herkes için kullanılabilir.

Bu, incelemenin check-in sırasında yapılması gerektiği için kötü değişikliklerin çalışan kopyalara yayılmayacağı anlamına gelir.