Resmi bir kod incelemesi yaparken faydalı bir düşünce yapısı nedir

Ekibimiz son zamanlarda her check-in için kod incelemeleri yapmaya başladı.

Takım lideri olarak, çok fazla öneri sunmak, sinir bozucu geliştiriciler ile ekip çıktısını azaltmak ve kodun bırakılması arasında farklı bir yazı yazacağım arasında bir denge bulmaya çalışıyorum.

Yararlı bir yaklaşım öneren iyi bilinen kaynaklardan herhangi bir kanıt, çalışma veya rehberlik var mı?

Kapsayıcı hedefleri aklınızda bulundurun: Sonuçta, sadece çalışan yazılım önemlidir

Akran denetimi ve check-in kodu incelemesi, kaliteyi iyileştirmeyi amaçlar . Ancak kalite için demotivated geliştiriciden daha kötü bir şey yoktur. Bir takım lideri olarak rolünüz, kodu kendiniz yazabileceğiniz bir şey olarak desteklemek değil, ekip çalışmasını teşvik etmek ve genel sonucu sağlamaktır.

İncelemeniz için net bir kapsam belirleyin

Unutmayın: kodunuz değil, ekibin kodu. Bu nedenle, yanlış sonuçlara yol açabilecek şeylere odaklanın.

• Çalışmayacağından emin olmadığınız sürece geliştiricinizin gereksinimleri karşılamayı seçtiği şekilde meydan okumayın (ancak testlerde zaten başarısız olmalıydı, değil mi?)

• Sorunun nerede olduğunu gösteren bir önlem olmadıkça düşük performans için meydan okumayın. Erken optimizasyon tüm kötülüklerin kökenidir ;-)

• Meydan okuyacak bir tasarım veya yazılım yapısı bulursanız, kendinize neden önünüzde yakalanmadığını sorun! Zaten yazılan kodun yeniden yazılması pahalıdır. Bu durumda, yazılım geliştirme ve ekip çalışması uygulamalarınızı en azından kod kadar gözden geçirme zamanı.

• belirlenmiş kodlama standartlarına uyumu ele almak. Hem gözden geçiren hem de gözden geçiren için tartışmak en sinir bozucu konu. Herkes takımınızda büyük harfli sınıf isimleri kullanmayı kabul ettiğinde ve bir erkeğin dersi olmayan biri ise, bu bir zevk meselesi mi? Veya ekip çalışmasının etkinliği ve riski?

Bu arada, bir kodlama standardının tartışılmaya değer olmadığını düşünüyorsanız, standartlarınızdan kaldırın ve üzerinde zaman ve enerji harcamayın.

Liderlik geliştirmek: gözden geçirmenin insan tarafı

Bir ekip lideri olarak, burada kalite kontrolün formalitesinin ötesinde kendinizi ve ekibinizi geliştirme fırsatı bulabilirsiniz:

• Gerçek bir değişim varsa kod incelemeleri herkes için çok daha hoş. Geliştiricinize becerilerini de gösterme fırsatı verin (ve evet, belki de yeni bir şey öğrenebilirsiniz).
• Tasarım tercihleri ​​veya mevcut standartlar hakkında eleştirilere açık olun. Bazen insanlar bu tür hayal kırıklıklarıyla daha iyi başa çıkabilir, çünkü bunun hakkında konuşabilirler.
• Çocuklarınıza koçluk yapın: bir sonraki tekrar için tavsiye vermek veya yeniden yönlendirmek için tereddüt etmeyin. Bunu yaşlılarla yapmayın: başka bir dünyada ilgili rolünüz değişmiş olabilir.

Diğer uygulamalardan yararlanın

Kod incelemesinde önleyebileceğiniz birkaç şey vardır:

• Yapı zincirinizde statik kod çözümleyicinin kullanılması , eş denetiminden çok önce yaygın hataların veya taşınabilir olmayan yapıların bulunmasını otomatikleştirebilir . Bazı araçlar bazı kodlama standartlarınızı kontrol edebilir .
• Kod düzeni ile ilgili standartlarınız varsa , kodu otomatik olarak gerektiği gibi biçimlendirmek için önceden taahhüt edilmiş güzel baskı veya benzeri formatlayıcılar kullanın. Bir yazılımın sizin için daha iyi ve tartışmadan yapabileceği şeylere asla zaman harcamayın :-)
• Son olarak, kalite sadece gözden geçirme ile değil, aynı zamanda testlerle de sağlanır. Henüz TDD kullanmıyorsanız , kod incelemesinden bağımsız olarak düşünün .

Geliştiriciler olarak biz, zihniyet her zaman açık ve şüpheci kalmalıdır.

Açık, çünkü bir geliştirici bizi ne zaman şaşırtabileceğini bilmiyor ve kendi fikirlerimiz hakkında şüpheci. Çözümlerimizin ardındaki mantık bizim için anlamlı olabilir ve başkaları için hiçbir şey ifade etmeyebilir. Kod kokusunun ardında harika bir fikir olabilir. Belki de geliştirici bunu doğru şekilde ifade etmenin yolunu bulamadı.

Biz (insanlar) iletişimde korkunç olduğumuzdan, yanlış varsayımlar yapmayın, kod sahibine incelediğiniz kod hakkında sormaya istekli olun. Bu fikri şirketin standartlarına göre kodlamada başarısız olursa, baş geliştirici de ona rehberlik etmeye istekli olduğundan.

İşte öznel yaklaşım. Nesnel yaklaşım, IMO, bu soruda çok iyi açıklanmıştır .

Yukarıdaki bağlantıya ek olarak, ulaşılacak hedefler kümesi (sürdürülebilirlik, okunabilirlik, taşınabilirlik, yüksek uyum, gevşek bağlanma vb.) Mutlaka On Emir değildir. Siz (ekip) bu hedefleri kalite ve verimlilik arasındaki dengenin işi konforlu ve "geliştiriciler için yaşanabilir hale getirdiği" bir noktaya uyarlayabilmelisiniz.

Bu hedeflere göre kalitenin ilerlemesini ölçmek için statik kod analiz araçlarının kullanılmasını öneririm. SonarQube gibi araçlar bize önceliklerimize göre özelleştirilebilen Kalite Kapıları ve Kalite Profilleri sağlar. Ayrıca, geliştiricilerin kod kokusu, hatalar, şüpheli uygulamalar vb.

Bu tür araçlar iyi bir başlangıç ​​noktası olabilir, ancak dediğim gibi kendinizi şüpheci tutun. Sonar'da sizin için anlamsız bazı kurallar bulabilirsiniz, bu yüzden onları görmezden gelebilir veya kalite profilinizden kaldırabilirsiniz.

Geliştiricinin kozmetik değişiklik koduyla uğraşması geliştiriciyi motive edecektir, ancak mutlak durumlarda yapılması gerekir. Kurşun sağlama arasındaki dengeyi bulmak zorundadır kullanışlı kod inceleme ve öğrenme gitmesine izin minör eksikliklerin. https://blog.smartbear.com/sqc/for-the-new-team-lead-the-first-six-things-you-should-know/

Akılda tutulması gereken bazı şeyler:

1. Bu, teknoloji kadar psikoloji ile de ilgili, bu yüzden burada altın bir kural yok.
2. İnsanlarla ilgili olan sadece bilgi değil, aynı zamanda hiyerarşideki kültür ve konumla da ilgilidir.
3. Eğer bu "uzun" bir oyunsa (istikrarlı ve köklü bir şirket), insanların birbirlerine güvendiği iyi entegre bir ekip genellikle incelenen koda göre daha yüksek bir değere sahiptir. Kesinlikle devam etmesi gerekmeyen şeyleri zorlamak için kullanılmamalıdır. Şeytan ayrıntıda gizlidir ...
4. Eğer bu "kısa" bir oyun ise (yan proje, Ar-Ge, bir grupta serbest çalışan) CR'nin maliyetleri genellikle bunları yapmanın getirdiği avantajların üstesinden gelir. Ve tutum "sadece uyandır" olmalı

Önemli olan sadece iki şey var.

1. Tüm gereksinimler için otomatik testler var mı?
2. Hepsi geçiyor mu?

Diğer her şey kozmetiktir ve bir kapı olarak uygulamak yerine bira üzerinde tartışılmalıdır.

Bu görünümü izlerseniz, sizi dar bir odak alanı ile sınırlar.

Gereksinimler iyi mi? Göreve başlamadan önce bilmeniz gereken ideal, yani performans, güvenlik vb.

Testler iyi testler mi? Kaçırılan uç durumlar, gereksinimi iyi test ediyorlar vb. Sonuçta: Mevcut bir gereksinim için olan ancak başarısız olacak bir test yazabilir misiniz?