Ekip üyelerini “mandelbug” un varlığı konusunda nasıl ikna edilir?

Bir uygulama geliştiriyoruz; başka bir kodlayıcı tarafından geliştirilen bir kitaplığı içerir, bu kitaplık sunucu ile birden çok ağ bağlantısı üzerinden iletişim kurar ve bu birlikte çalışan birden çok iş parçacığını içerir. Sunucu tarafı kodu oldukça karmaşıktır ve kaynak koduna erişimimiz yoktur.

Son zamanlarda bazen uygulama çökmesi yapan bir mandelbug keşfettim . Bir kez çoğaltabilir ve yığın izlemesi yapabilirim, bu yüzden bir hata raporu açtım. Hatanın kendisini düzeltmek kolaydır (arka plan iş parçacıklarından birinde yakalanmamış web istisnası, CLR'nin programı sonlandırmasını sağlar).

Sorun, geliştiricinin "düzeltildiğine ikna olmadığı için" hatayı düzeltmeyi reddetmesidir. Ne yazık ki benim için patron onunla birlikte ve hata varlığını kanıtlamak ve gittiğini doğrulamak birim testi yapmak için "sağlam bir test vakası" yapmak sürece bu hata düzeltilemez diyor. Böceğin doğası nedeniyle temelde imkansız olan şey.

Herhangi bir tavsiye?

Mümkünse, uygulama kodunuza biraz uyku veya blok koyarak bu hatanın yeniden üretilip üretilemeyeceğini kontrol etmek için biraz zaman harcayabilirsiniz . Ama çok fazla zaman harcamayın. Bu sorun çoklu yoldan (ve gözlemlediğiniz gibi) bağlı olduğu için, bu durum nadir olacaktır.

Benim tavsiyem bunu çok fazla terlememek. İşinize devam edin. Bu kilitlenme ile karşılaştığınızda, hata raporunuzu yığın izlemesi ile güncelleyin, bunun tekrarlanan bir durum olduğunu söyleyip sahibini kütüphane geliştiricisine değiştirin. Yönetimin / müşteri adayının frekansına bağlı olarak düzeltilip düzeltilmeyeceğine karar vermesine izin verin.

Ayrıca geliştiricinin zihnini anlamaya çalışın. "Yakalanmayan web istisnası" dediniz. Bu aşamadaki geliştirici, bunu yakalamanın diğer etkilerinin ne olacağından tam olarak emin olmayabilir . Bu nedenle, koda dokunmak konusunda isteksiz olabilir.

Yani, az çok açıklayıcı yorumlarınızdan, bunu şu şekilde anladım:

Eksik olan basit bir ek istisna işleme olduğundan eminsiniz ve lib'deki hangi kod satırının sorunlu olduğunu ve lib'in nasıl düzeltilebileceğini zaten biliyorsunuz.

O zaman neden sadece eksik olan birkaç kod satırını lib'e kendiniz eklemiyorsunuz, takımdan lib'i bu değişikliklerle test etmesini isteyin? Düşük riskli bir değişiklik olduğundan emin olun, lib'den sorumlu geliştirici tarafından anlaşılması kolaydır. Olabilecek en kötü şey, düzeltmeniz bazı beklenmedik davranışlara neden olursa, birinin VCS'nizdeki değişikliği geri alması gerektiğidir.

Çoğu insan, iş zaten yapıldığında ikna etmek daha kolaydır. Ayrıca, "bu kod yanlış, bir şekilde düzeltin" aksine, "burada geliştirilmiş bir çözüm" üzerinde daha iyi tepki veriyorlar.

EDIT: geliştirici hala bu değişikliği eklemeyi reddettiğinde, en iyi seçenek sorunlu kodu ağ hatası simüle nerede izole bir test koşum içinde çalışması için çalışıyor. Eski kodla etkili bir şekilde çalışmak , bu tür sorunların nasıl çözüleceğine dair birçok tekniği açıklar. Örneğin, kitaplığın yalnızca sorunlu modüller ve işlevler de dahil olmak üzere bir test sürümünü oluşturabilir ve çevresinde "ağ özel durumunu" denetimli koşullarda simüle edebileceğiniz bir "sahte ortam" oluşturabilirsiniz. Bu ilk bakışta çok fazla çaba gibi görünebilir, ancak böyle bir ortama sahip olduğunuzda, ona çok fazla ek test ekleyebilirsiniz (ve sanırım bu mantıklı olacaktır, çünkü lib'in yazarı eksik eklemeyi reddettiğinde tek bir yerde istisna yönetimi,

Bunun gibi bir hata için, otomatik fuzz testi (rastgele test olarak da bilinir) yeniden üretmeye yardımcı olabilir. Bu, sabit bir parametre setini (veya girişleri) test ettiğiniz şeye rasgele ayırarak hatayı bulma işlemini otomatikleştirir. Her test çalıştırması, parametreler, zaman damgaları vb. Dahil olmak üzere bir günlük dosyasına kaydedilir, böylece kilitlenme meydana geldiğinde (teorik olarak), aynı parametreleri kullanarak testi tekrarlamak için tekrar oynatabilirsiniz.

Otomatikleştirildiğinden beri, test süreci kısa sürede birçok testi gerçekleştirebilir. Genellikle bir gecede çalıştırmak için bırakılabilir ve sabahları çökmeyi yeniden oluşturup oluşturmadığını görmek için bir günlük dosyasını kontrol edebilirsiniz.

Şeytan Avukatı başka bir yol önerir.

Diğer geliştirici, açıkça, orada bir hata olmadığını belirtti.

Var olmadığı iddia edilen hatadan cehennemi strese sokmanın ve çok daha sık çökmesine neden olmanın bir yolunu bulabilir misiniz?

Yığın izlemesi, hatanın var olduğunu veya en azından belirli bir yapıda var olduğunu gösteren açık bir kanıttır. Elinizde olmayan, hatanın giderildiğine dair kanıt. Bunu görmezden gelmek aptalca. Bir müşterinin sisteminde her seferinde tetiklenen birden fazla sistemde yüz binlerce otomatik denemeden sonra hataları yeniden üretmek imkansızdı .

Yılda bunun gibi birkaç hata alıyorum, çoğu yığın izinden bile faydalanmadan. Hemen hemen her durumda, önceden üretemesem bile, düzeltildikten sonra kolayca otomatik bir test yapabilirdim.

Örneğin, birkaç ay önce yalnızca kullanıcı dakikada 96 kelimeden daha hızlı yazdığında oluşan bir hatayı düzelttim. Düzeltmeden önce, tek bildiğim hata "bazen" oldu. Hızlı yazma için bir birim testi yazmak benim için asla olmazdı. Ancak, temel nedeni öğrendikten sonra, bunun için bir test yapmak önemsizdi.

Bir hatanın düzeltildikten sonra bile çoğaltılamadığı nadir durumlarda bile, kod denetimi ile kapatabilirsiniz.