Yazılım neden hala bilinen hatalarla yayınlanıyor? [kapalı]

Görünüşe göre, büyük projelerde yazılım hala hata izleyici hatalarla doludur. Şimdi özellik isteklerini anlayabiliyorum, ancak birkaç kez hala çözülmemiş, gözden geçirilmemiş veya bitmemiş çok sayıda hata gördüm, ancak bir yayın hala dışarı itildi.

Neden? Neden açık kaynak kodlu bir proje veya genel olarak bilinen hatalar içeren bir proje yayınlanacak ? Neden hata izleyicide 0 hata açılıncaya kadar beklemiyorlardı?

Aşağıdakiler de dahil olmak üzere herhangi bir sayıda neden:

1. Şirket, belirli bir zamanda kullanıcı tabanına geçme taahhüdü vermişti
2. Böcekler kritik öneme sahip, hatta önemli değildi
3. Yeni özellik geliştirme daha doğru olarak görülüyordu (doğru olsun ya da olmasın)

Bu, programlama bilginiz "tam" olmasa bile, neden bir programcı olarak çalıştığınızı sormak gibidir. Çoğu karmaşık projede, çok, çok hata olacak. Yeni özellikler eklerken onlarla uğraşmak zor, karmaşık bir iştir.

Çünkü hata içeren bir yazılım hiçbir yazılımdan daha iyidir.
Aynı sebepten:

• Her zaman gecikme olsa da nakliye şirketleri program yapmaktan rahatsız oluyorlar.
• İlaç şirketleri bilinen (ve çoğunlukla belgelenmiş) yan etkileri olan ilaçlar satmaktadır.
• Tüm dünyadaki okullar, bilinen sınırlamaları olmasına rağmen, Newton fiziğini öğretmektedir.

Bilinen eksiklikleri olan bir çözüme sahip olmak, hiçbir çözüme sahip olmamaktan veya eksiklikleri olmayan bir çözüme sahip olmaktan çok daha iyidir.
En sevdiğim IDE, istikrarlı olmaktan çok yeni özelliklere sahip. Şöyle diyelim: Her yirminci seferde bir şeyleri elle yapmak zorunda kalmayı tercih ederim, çünkü özellik her şeyi elle yapmak yerine başarısız olur.

Ya da Voltaire'nin sözleriyle söylemek gerekirse: "Le mieux est l'ennemi du bien."

Sonuçta, özgür ve açık kaynaklı yazılımlar için bile bir iş kararı. Mevcut kusurların, yayınlamak, yazılımınızı kullanıcının ellerine almak ve geri bildirim almak (ancak bunlarla sınırlı olmamak üzere), özellik istekleri ve bulunmayan yeni hata raporları dahil olmak üzere daha az etkili olduğu bir nokta vardır. testte). Bu karar, rakipler arasında yazılım için piyasada çekiş yapma ihtiyacından kaynaklanmaktadır. Yazılımınızın bir etki yaratmasını istiyorsanız, rakiplerinizi yeni özellikler veya konseptlerle pazarlamak için yenmeniz gerekir.

her şey maliyet ve fayda analizine bağlıdır. Her hata düzeltmesinin kendisiyle ilişkili bir maliyet değeri vardır (düzeltmek için çalışma saatleri, yayınlamadan X gün önce daha fazla kod değişikliği yapma riski ...). Aynı zamanda, her hata düzeltmesi daha fazla özellik, kullanılabilirlik vb.

Bu, her geliştirme ekibinin bir sürüm yaparken karşılaştığı soru: 1) maliyet ve ek değer göz önüne alındığında Bug #i düzeltilmeye değer ve 2) i = 0'dan N'ye kadar tüm açık hatalar için tekrarlayın.

Yayınlanmayan bir yazılım ürününün kimseye HİÇBİR değeri olmadığını unutmayın. 200 olağanüstü hataya sahip olan ancak işlevselliğinin% 90'ına sahip olan yazılım ürünü, sürüm sırasında çalışanlardan memnun olan herkese değer vermektedir.

Hiçbir zaman 0 hata ile piyasaya sürülen bir üründe hiç bir şirkette bulunmadım ve bence bu gayet normal. Bir noktada, kayıplarınızı azaltırsınız ve neyin işe yaradığını hesaplarsınız. Aksi takdirde, asla bir şey bırakmazsınız.

Büyük bir projede asla böcek bulmayı bırakmazsınız. Tüm hatalar giderilene ve düzeltmeler regresyonu test edilene kadar beklemek zorunda kalırsanız, asla serbest bırakmazsınız.

Ayrıca, tüm hataların dahili olmadığını unutmayın. Her program, diğer yazılımların karmaşık bir ağının bir parçasıdır ve başka yerlerdeki değişiklikler kendilerini yazılımınızda "hata" olarak gösterebilir. Dünyayı durduramazsın.

Birçok iyi cevaba ek olarak, bazen yeni bir ürünle pazarlamak için bir yarış vardır. Kritik olmayan kusurların% 15'i (veya başka bir sayı) açık olsa bile pazar payının çoğunu kazanabileceğinizi düşünüyorsanız, rakipler üzerinde avantaj elde etmek için ürünü serbest bırakmaya değer olabilir.

Bu hatalar oldukça küçük olabilir. Ticari yazılımların sevk edilmesi ve disklere ve benzeri şeylere basılması gerektiğini unutmayın. Bu çıkış tarihlerinin yerine getirilmesinin ciddi finansal sonuçları vardır ve bazı küçük sorunların ertelenmesi, başka nedenlerle pazara girme gerekliliğinden bahsetmemek için finansal anlam taşımamaktadır.

Olası cevaplar:

• Herkesin hatayla karşılaşması pek olası değildir.
• Hatalar için geçici çözümler vardır.
• Yazılımın bir zamanlar piyasaya sürülmesi gerekiyor ve mükemmelliğe ulaşılması pek mümkün değil.

İdeal olarak çoğu geliştirici uygulamalarında sıfır hata görmek ister, ne yazık ki koşullar böyle bir ütopya durumuna izin vermeyebilir.

Bunun nedeni, kullanıcı tabanının yeni özellikler talep etmesi ve ek işlevsellik için aynı veya daha fazla hatayı almaya istekli olması gerektiğine inanmak istiyorum.

Yönetim söz konusuysa, son tarihlerin bir dizi nedenden ötürü karşılanması gerekir: reklam programları, ek personel kullanılabilirliği sorunları, "bu işlevsellikten ilk önce olmalıyız" zihniyeti.

Aklımda daha az iyimser, muhtemelen geliştiriciler tembel olduğu için mi?

Ayrıca, açık kaynaklı topluluklarda genellikle "kim" in hangi hata / özellik / sorun taleplerini üstlenmek istediğini unutmayın - belki de hiç kimse onların arkasındaki daha büyük sorunlar nedeniyle mevcut sorunlarla uğraşmak istemez.

En basit programlı testte:

if (management->perceived_cost_to_fix > management->perceived_benefit_release_now) {
    release;
}

Hataları, zamanı / alanı / hafızayı veya güvenlik / kullanılabilirliği düzeltiyor olsun, her şey her zaman bir ödünleşmedir. Yapılan ödünleşim hesaplamasını düşünün. Buna katılmayabilirsiniz, ancak anlamadığınız takdirde başınız belaya girer.

Ayrıca, bir çan eğrisindeki bu hesaplamaları düşünün ... bazı insanlar her iki taraf için de gerçekten kötü olanları yapacak. Eğrinin bir ucu için Duke Nukem Forever'a bakınız.