Zorunlu kod incelemesi için iyi yönergeler ve uygulamalar [kapalı]

Her bir spekülasyonda zorunlu kod incelemesini deniyoruz - hiçbir sprint için en az 1 kişi yazar tarafından onaylanmamış bir efendiye ulaşmıyor - birkaç sprint için. Hem geliştiricilerden hem de yönetimden (içinde olmak inanılmaz bir durum) satın aldık ve bunun için bilinen bazı avantajlardan yararlanmak istiyoruz:

• bariz hata azaltma
• proje çevresinde meydana gelen değişiklikler hakkında daha fazla farkındalık
• "Birisinin buna bakacağını biliyorum, bu yüzden tembel olmayacağım" / anti-kovboy etkisi
• projeler içinde / arasında artan tutarlılık

Ancak hızı düşürdüğü bilinen bir şey sunuyoruz ve yanlış yapılırsa, taahhüt boru hattında zamandan başka hiçbir şey yapmayan aptal bir bürokratik adım yaratabilir. Endişe ettiğim şeyler:

• sadece nit toplama işlemine dönüşen yorumlar
• (hiperbolik olarak) insanlar iki satırlık gözden geçirmenin bir parçası olarak büyük mimari meseleler açıyorlar.
• Cevapları başka şeylerle taraflı tutmak istemiyorum.

Hepimiz makul insanlarız ve çok fazla öz analiz yapacağız, incelemelerin gerçekten bizim için çalışmasını sağlamak için bir inceleme oturumunda ne tür şeyleri gerçekleştirmeye çalışmamız gerektiğine dair savaşla ilgili bazı fikirleri kesinlikle kullanabiliriz. . Çalıştığını tespit ettiğiniz bazı yönergeler ve politikalar nelerdir?

1. İncelemeleri kısa yapın.

   Özellikle kod incelemesi sırasında uzun süre konsantre kalmak zordur. Ayrıca, uzun kod incelemeleri, kod üzerinde söylenecek çok şey olduğunu (sonraki iki noktaya bakın) veya incelemenin mimari gibi daha büyük sorunlar hakkında bir tartışma haline geldiğini gösterebilir.

   Ayrıca, bir inceleme tartışma olarak değil bir inceleme olarak kalmalıdır. Bu, kodun yazarının cevap veremeyeceği anlamına gelmez, ancak uzun bir fikir alışverişine dönüşmemelidir.

2. Çok kötü olan kodu gözden kaçının.

   Düşük kaliteli kodun gözden geçirilmesi hem gözden geçiren hem de kodun yazarı için üzücü. Bir kod parçası korkunçsa, kod incelemesi yararlı değildir. Bunun yerine yazardan kodu doğru şekilde yeniden yazması istenmelidir.

3. İncelemeden önce otomatik dama kullanın.

   Otomatik dama otomatik olarak bulunabilecek değerli zaman işaretleme hatalarını boşa harcamamaktadır. Örneğin, C # kodu için StyleCop, Kod metrikleri ve özellikle Kod analizi çalıştırmak, incelemeden önce bazı hataları bulmak için iyi bir fırsattır. Daha sonra, bir makine için yapılması çok zor olan noktalarda kod incelemesi yapılabilir.

4. İnceleme yapan kişileri dikkatlice seçin.

   Birbirini tahammül edemeyen iki kişi, birinin kodlarından birini iyi bir şekilde gözden geçirmeyecektir. Aynı sorun, bir kişi diğerine saygı duymadığında ortaya çıkar (bu arada gözden geçiren veya yazar olsun, bu fark).

   Ayrıca, bazı kişiler kodlarının incelendiğini göremezler, bu yüzden eleştirilmediklerini anlamak için özel eğitim ve hazırlık gerektirirler ve bunu olumsuz bir şey olarak görmemelidirler. Hazırlıksız bir inceleme yapmak yardımcı olmaz, çünkü onlar her zaman bir savunmada olurlar ve kodlarının herhangi bir eleştirmeni dinlemezler (her öneriyi bir eleştiri olarak alırlar).

5. Hem resmi olmayan hem de resmi incelemeler yapın.

   Bir kontrol listesine sahip olmak, nit toplama işlemine girmekten kaçınarak hassas bir kusur kümesine konsantre olmanıza yardımcı olur. Bu kontrol listesi aşağıdakileri içerebilir:

   • SQL Enjeksiyonu,
   • Hatalara yol açabilecek bir dil hakkında yanlış varsayımlar,
   • Operatör önceliği gibi hatalara neden olabilecek belirli durumlar. Örneğin, C # ' var a = b ?? 0 + c ?? 0;da, sıfır ile birleşmesi olan iki boş sayı eklemek isteyen biri için iyi görünebilir, ancak değil.
   • Hafıza aktarımı,
   • Tembel yükleme (iki riski ile: aynı şeyi bir kereden fazla yüklemek ve hiç yüklememek),
   • Taşırmak,
   • Veri yapıları (örneğin, karma kümesi yerine basit bir liste gibi hatalarla),
   • Giriş doğrulama ve genel olarak savunma programlaması,
   • İplik güvenliği,
   • vb.

   Listeyi burada durduruyorum, ancak kesin bir yazarın zayıf noktalarına bağlı olarak bir kontrol listesinde yer alabilecek yüzlerce nokta var.

6. Kontrol listesini aşamalı olarak ayarlayın.

   Zaman içinde yapıcı ve yararlı olabilmek için, resmi incelemelerde kullanılan kontrol listeleri bulunan hatalara bağlı olarak zaman içinde ayarlanmalıdır. Örneğin, ilk resmi olmayan incelemeler, SQL Enjeksiyonu'nun belirli bir miktar riskini ortaya çıkarabilir. SQL Enjeksiyon kontrolü kontrol listesine dahil edilecektir. Birkaç ay sonra, yazarın dinamik ve parametrelenmiş sorgular konusunda artık çok dikkatli olduğu görülüyorsa, SQL Injection kontrol listesinden kaldırılabilir.

Neredeyse bir kontrol listemiz var:

• Bana görev tanımını göster.
• Sonuçta bana doğru yol göster ve çalıştığını göster. Farklı senaryolar çalıştırın (geçersiz girdi vb.).
• Geçen testleri göster. Test kapsamı nasıl?
• Kodu göster - işte burada bariz verimsizlikler arıyoruz.

Oldukça iyi çalışıyor.

Diğerleri üzerinde gücü olan bir kişi, alakasız yorumları kesmek, hızlı inceleme gerektiren şeyleri gözden geçirmeyi hızlandırmak için yönetici veya moderatör yeterli olacaktır. Tek karar verici.

Bunun eksi, bu kişinin bunu başka bir şey yaparken ana görev olarak yapmak zorunda olacağı ve muhtemelen bu pozisyonda en deneyimli kişinin olmasını istersiniz.

İkinci şey mümkün olduğunca otomasyon!

• beyaz boşlukların kontrolü
• stil kontrol yazılımı
• kod incelemesinden önce otomatik derlemeler
• kod gözden geçirmeden önce otomatik test

Bu şeyler, insanların gerçek ihtiyaç duymadan yorum yapabileceği en azından bazı şeyleri kaldıracaktır. Bina oluşturmuyorsa veya sondaki boşluklara sahip değilse, gözden geçirme için yeterince iyi değildir, düzeltin ve tekrar incelenmek üzere başvurun. Eğer yapmıyorsa veya bir test başarısız olursa, yeterince iyi olmadığı açıktır.

Birçoğu teknolojilerinize bağlıdır, ancak otomatik olarak neleri kontrol edebileceğinizi daha iyi bulabilirsiniz.

Bu savaşı henüz kazanmadık, ama faydalı bulduğumuz şey bu.