Kod inceleme Teslim / Test Döngüsünün gerisinde kalıyor

Çevik sürecimizde 2 haftalık Sprintlerimiz var. Görevler günlük olarak (günlük yapımlar) teslim edilir ve Test Ekibi testlerini hemen ertesi gün hatta aynı gün tamamlar.

Ayrıca, biraz zaman gerektiren (1-2 saat) Dev kodu incelemelerimiz var, bu yüzden haftada 3 kez planlanıyorlar: Mon-Weds-Fri. Geliştiriciler bir araya gelir ve kodun nasıl geliştirileceğini / yeniden düzenleneceğini önerir.

Sorunumuz, Eylem Öğeleri bir kod incelemesinden sonra ortaya çıktığında, görevlerin çoğu zaten test edilmiştir. Testçiler, testlerini geçmiş olanları tekrar test etmek istemezler. Dahili geliştirmelerle ilgilenmezler.

Çevik süreci yanlış mı anlıyoruz? Kod incelemeleri günlük Sürüm / Test döngüsüyle uyumlu değil mi? Herkesin zamanını aldıkları için her gün kod incelemeleri yapamayız.

Testçiler tekrar test etmek istemiyorlar, "kodlayıcılar yeniden düzenleme istemiyorlar" demek gibi. İşin bir parçası. İşlem şu şekilde yeniden ifade edilebilir: Görevler oluşturulur. Kod oluşturulur. Kod test edildi. Kod gözden geçirilir. Kodda kusurlar bulunur. Bu kusurları gidermek için Yeni Görevler oluşturulur (örneğin, kod yeniden düzenlenir). Bu yeni görevler yeni testler gerektirir.

Kodu bir noktada inceleyecekseniz, incelemeyi erken yapmak artık pahalı değildir. Ve pahalı bir test süreciniz var gibi görünüyor, bu yüzden iki kez test etmek istemiyorsunuz. Bu nedenle testten önce kodu gözden geçirmek daha ucuzdur. Testten sonra kodu gözden geçirmek işin daha hızlı gitmesini sağlamaz. Daha yavaş gitmesini sağlar ve kötü yazılmış ancak başarılı bir şekilde test edilmiş kod vermenizi sağlar. Zamanla bu gözden geçirilmemiş kod işi yavaşlatır. Daha verimli bir rakip daha az maliyetle daha iyi bir ürün sunar ve oyun biter.

Ayrıca, testi otomatikleştirin. Manuel test böylece 1970.

Şu anda KG'den önce sahip olduğunuz zamanda kod incelemelerinin yapılmasını zor buluyorsanız, @Dukeling'in yayınladığı Bölüm II, Agile Teams'deki Kod İnceleme gibi kod incelemelerini daha hafif yapmayı düşünmelisiniz .

Muhtemelen bir kod incelemesi olarak adlandırılabilecek en basit şeyin bile fayda sağladığını gördüm: kod vermeden önce (veya bir DVCS'ye basmadan), başka bir geliştiriciyi arayın ve değişikliklerinizde yürüyün. Bu beş veya on dakika sürebilir. Bu kod incelemesinin amacı "Bu, diğer geliştirici için anlamlı mı?" Amaç, tasarım uygulamalarına odaklanmak ya da gözden geçirenin nasıl yazılması gerektiğine ilişkin kişisel fikirlerine tamamen uymak değildi. Şu faydaları sağladı:

• Kodun nasıl çalıştığı hakkında geliştirilmiş paylaşılan bilgi
• Kafa karıştırıcı veya potansiyel olarak hatalı kod yakalandı çünkü kodu açıklama eylemi yazarın bir şeyi yeniden düşünmesini sağlamak için yeterliydi
• Takım deyimlerini ve stilini yavaş yavaş geliştirmeye yardımcı oldu, çünkü bir şeyleri açıklamayı kolaylaştırdı
• Takımdan çok az homurdanıyor

Daha derin kod incelemeleri, sorunları bulmak için kesinlikle daha iyi çalışır. Ama değerlerini elde etmek için onları yapabilmeli ve onlara göre davranmalısın. Her zaman yapabileceğiniz hafif bir işlem, ertelemeye devam eden veya yalnızca birikmiş işlere bir şeyler ekleyen ağır bir işlemden daha yararlı olabilir.

Bu sorunun bir çözümü, bir kullanıcı hikayesi bittiğinde kodun başka bir akran tarafından hızlı bir şekilde gözden geçirilmesidir, böylece kodda herhangi bir temel / açık hata olmaz.

Ancak bu, test döngüsünden önce gerçekleşmelidir. Daha sonra, tüm ekiple birlikte daha büyük bir inceleme yaptığınızda, testten sonra daha az kod değişikliği olur.

Test cihazlarının seslerinden test etmek acı verici / pahalı bir süreç olduğu için tekrar test etmek istemiyor.

Hem geliştiriciler hem de test kullanıcıları tarafından test otomasyonu, çevik bir şekilde çalışmaya çalışan ekipler için büyük bir bonus. Testlerinizin daha ucuz, daha kolay ve daha tekrarlanabilir olması, bunları ne kadar çok uygulayabileceğinizdir ve bir şeyi değiştirmeye daha az direnç kazanırsınız.

Bazı dev geri bildirimlerine dayalı hızlı bir refactor yaptınız mı? Regresyon / duman paketinizi yürüten büyük kırmızı düğmeye basın ve kırpılmış olabilecek görsel sorunları kontrol etmek için bir kez hızlı bir manuel yapın. Kolay!

Böyle bir yerde olduğunuzda, tekrar test etmek bir angarya olmayacak - ikinci doğa olacak.