Aşırı şişirilmiş bir yazılıma yol açan nedenler nelerdir? [kapalı]

Bugün Creative Sound Blaster sürücüleri için temiz bir kurulum yapmaya karar verdim, çünkü bir süre sonra her zaman kendi başlarına hata yapmaya başladılar. Bu da tüm temizlik prosedüründen geçmek zorunda olduğum anlamına geliyordu. Ve bu neredeyse 2 saatimi aldı.

Ve dürüst olmak gerekirse, bir neden göremiyorum ?! Ve Creative, IMHO, hiçbir zaman işe yaramayan kalitesiz yazılım üretmek için birincilik kazanmasına rağmen, şişkinlik sorunu onlara özel değildir.

Canon dijital kamera sürücüsüne sahip PC, her türlü bağlantıyla birbirine bağlı yaklaşık 10 Canon girişine sahip olacaktır. Visual Studio da önemli bir örnektir, tam kurulum için yaklaşık 50 kadar giriş vardır ve bu şeyi onarmak sadece tam nuking ile mümkündür. Ve bir kez bile VS2k8'den VS2k8SP1'e veya başka bir şeye yükseltme yaparken tüm OS yüklemesini mahvetmeyi başardı. Görünen o ki 5GB boş alan 300 Mb yama için yeterli değildi ...

Yani bu gerçekten yaygın bir problem gibi görünüyor. Günümüzde hemen hemen her uygulama genellikle paketleyicileri, yüklü birden fazla spywarish "arkadaş" içerir, sürücüler yazıcılar dahil her şey için genellikle 600Mb civarındadır.

Ama neden? Geliştirici hatası mı? Bunun gibi uygulamalar destek kabusu, günümüzde asla% 100 çalışmıyorlar ve tanıdığım neredeyse tüm kullanıcılar USB başparmak sürücüsü / Yazıcı / Kamera / Ses Kartı / Tarayıcı için zorunlu bir sürücü yüklemesi olarak aldıkları tüm şişkinlik hakkında çok olumsuz.

Nullsoft'tan NSIS, örneğin Firefox yüklemesi gibi bildiğim kadarıyla şişirilmemiş tek temiz kurulum sistemi gibi görünüyor. Sorunsuz, hemen hemen xcopy tabanlı kurulum sorunsuz.

Peki neden insanlar 30 ara bağlantı katmanı üzerinde köklenmemiş basit kurulumlar ve uygulamalar kullanmıyor? Geliştiriciler tembel olduğu için mi? Kodgen araçlarının kullanımı? Şirketler, kullanıcıların seveceği bir şey olarak ağır uygulamaları zorladığı için mi? Nedeni nedir ve yazılımın bir gün temel bilgilere döneceğine dair bir umut var mı? Sıfırdan yeni bir uygulamaya başladığınızda şişkinlik yazmayı önlemeye yönelik adımlar nelerdir?

Benim tahminim, birisinin iyi bir fikir olduğunu düşündüğü birçok özellik var. Bununla birlikte, birçok insanın tek bir uygulamada bir araya getirilen ayrı fikirleri varsa, bu böyle karmaşık hale gelebilir. Üründe ne olduğu ve çeşitli açılardan nasıl optimize edileceği konusunda sorumluluk sahibi olan ürün yöneticilerinin olması gereken büyük kurumsal ürünler söz konusu olduğunda geliştiriciyi suçlamam.

Bunun bir diğer yönü, büyük bir zaman yatırımı olarak görülmediği için çoğu durumda iyi yönetilemeyen teknik borç olacaktır. Yeni özelliklerin ve hata düzeltmelerinin, hemen hemen iş değeri düşük gibi görünen yeniden düzenleme veya diğer borç görevlerinden daha mantıklı olduğundan şüphelenirim. Geliştiricilerden oluşan bir ekip, kod tabanı oldukça eskiyse eski kodu temizlemek için birkaç hafta alır mı? Tahminim sık olmayacaktı.

Joel'i Strateji Mektubu IV'te alıntılamak : Bloatware ve 80/20 Efsanesi :

[...] bloatware için birçok harika neden var. Birincisi, programcılar kodlarının ne kadar büyük olduğu konusunda endişelenmek zorunda kalmazlarsa, daha erken gönderebilirler. [...] Yazılım satıcınız durmadan önce, göndermeden önce ve kodu% 50 daha küçük hale getirmek için iki ay harcıyorsa, size en büyük faydası farkedilmez olacaktır. [...] Ama yeni sürüm için fazladan iki ay beklemenin kaybı algılanabilir ve iki ay satıştan vazgeçmek zorunda olan yazılım firmasının kaybı daha da kötü.

Birçok yazılım geliştiricisi eski "80/20" kuralıyla baştan çıkarıldı. Çok mantıklı görünüyor : İnsanların% 80'i özelliklerin% 20'sini kullanıyor. Böylece, özelliklerin yalnızca% 20'sini uygulamanız gerektiğine kendinizi ikna edersiniz ve yine de% 80 kadar kopya satabilirsiniz.

Ne yazık ki, asla% 20 aynı değil. Herkes farklı özellikler kullanır . [...]

Eğer "lite" ürün pazarlama başlar ve insanlara anlatmak, "Hey, 's lite, sadece 1MB," Çok mutlu olma eğilimi o varsa, o zaman sormak onların önemli özelliği, ve o kadar olmuyorsa Ürününüzü almıyorlar.

Oldukça büyük bir kısmı bir ürünün bağımlılıklarıyla ilgilidir. İşletim sisteminiz her türlü şey için birçok standart kütüphaneyle birlikte gönderilir. Bununla birlikte, bu standart kütüphanelerin işletim sisteminin gelişimi boyunca farklı sürümleri vardır ve herhangi bir genel yükleyici, karşı inşa edildiği belirli sürümün işletim sisteminde mevcut olacağını varsayamaz.

Bu nedenle, tam yükleyicinin, hedef bilgisayardaki her bağımlılığın ilk durumu ne olursa olsun, kurulumdan sonra her şeyin kesinlikle çalışacağından emin olmak için her bağımlılığın doğru sürümünü içermesi gerekir. Bu, Windows XP sistemlerine dağıtılması gereken .NET tabanlı uygulamalar gibi belirli uygulama türleri için oldukça önemli bir şişkinlik olabilir.

Yakın zamana kadar, birlikte çalıştığım bir yükleyici sisteminin en son sürümü dağıtabilmek için önceki her .NET sürümünün yüklenmesi gerekiyordu, böylece herhangi bir .NET 3.5 uygulaması .NET 1, 2, 2.5 ve 3 için kurulum ikili dosyaları gerektiriyordu 3.5 ÜSTÜNDE. Bu durumda, yalnızca yükleyici şişirilir.

Çözümlerden biri, yalnızca hedef sistemde bulunmayan bileşenleri indiren bir web yükleyicisidir ve bu devasa bir boyut / bloat yararı olabilir. Elbette kurulumlarınızı internet bağlantısı olan sistemlerle sınırlar.

Ben bir sürü kütüphane kodu katmanı üzerine katmanı ile ilgili olduğunu düşünüyorum. Açıkçası bir kütüphane kullandığınızda, içindeki her şeyi kullanmazsınız, böylece daha fazla kütüphane ekledikçe fazlalık toplanır.

Bir programcıdan bir saatlik çalışma maliyetinin giderek pahalılaştığı gerçeğiyle birleştirerek, tipik bilgisayarın işlem gücü / depolaması yıl geçtikçe daha ucuz hale gelir, bunun bu şekilde daha uygun maliyetli olduğunu görürsünüz.

• "X yapmak için bir şeylere ihtiyacımız var. $ BIGFATLIBDESIGNEDFORSOMETHINGELSE kütüphanesini kullanalım, çünkü onu farklı bir projede kullandım"
• "Sanırım artık bu kod kısmına ihtiyacımız yok, ama hiçbir şeyin bozulmadığından emin olmak için sakla"
• Yeterli birim testi yok veya yok,
• Yeniden düzenleme yok
• Ayarların yıllar boyunca saklandığı izleme yok, bu yüzden şimdi ayarlar her yerde
• ...

Bu, umutsuzluk döngülerindeki herkesin suçlanabileceği kısır bir döngüdür . Bir umutsuzluk döngüsü aşağıdaki adımlardan oluşur:

1. İş adamları şişkin özellikler ister.
2. Geliştiriciler şişirilmiş özellikleri, yapmamaları gerektiğini bilmelerine rağmen uygularlar.
3. Müşteriler, aptal özelliği değil, yalnızca ürünü isteseler bile şişirilmiş özellikler için ödeme yaparlar.
4. İş adamları müşterilerin şişirilmiş özellikleri istediğine inanıyor.
5. Birinci adıma gidin ve tekrarlayın.

Bunu nasıl durdurursun? Nasıl yapılacağına dair kolay bir cevap yoktur, ancak döngüyü durdurmak için adımlardan birinin kırılması gerektiği açıktır. Böylece sadece iş, geliştiriciler veya devrimci bir eylemde bulunan tüketiciler tarafından kırılabilir.

1. Bir mühendis bir modülü optimize etmeye çalıştı ancak birkaç müşteri sorunu getirdi. Sonra menajeri hayır dedi. Daha sonra mühendis, sorun dert edene kadar “sorun çıkarmamaya” karar verdi.
2. Karmaşık bir sistem için satıcı, müşterinin ortamında kararlı olmasını sağlamak için birçok yama ekledi ve binlerce hata düzeltti. Yazılım açısından iyi bir kaliteye sahip değildir, ancak çalışır. Hiç kimse aynı miktarda hatayı tekrar düzeltmek için yeniden yazmak istemez.
3. geriye dönük uyumluluk nedeniyle, bir özellik piyasada popüler olmasa bile, onu orada tutmamız gerekir.

Her zaman tembellik, şişkinliğe neden olan şey budur. (veya bu konudaki seminal makalede olduğu gibi çamur, Büyük Çamur Topu )

Örneğin, çalıştığım yerde yine de oldukça iyi tasarlanmış bir "eski" C ++ uygulaması var, İstemciler DB çalıştıran bir sunucu ile konuşmak bir API konuşuyor. Hepsi mantıklı. Son zamanlarda ek bir modüle ihtiyacımız vardı, ancak doğru bir şekilde uygulamak yerine geliştirici bunu .NET'te uygulamaya karar verdi ve daha da kötüsü, API aracılığıyla verilere erişmenin çok zor olduğuna karar verdi (bu değil ama ...) direkt olarak. Yani bu tür bir karmaşa nasıl gerçekleşir. (ve hepsi "iyi" yerine "hızlı" koyan TA'nın anlaşmasıyla)

Daha önce de bu tür şeyleri gördüm - eski bir yerde, GUI'nin küçük bir kısmı html idi, çünkü bazı geliştiriciler html'ye veri yazmak ve GUI'yi görüntülemek için iyi bir fikir düşündü. Yani 1 küçük parça diğerlerinden farklı bir şey yapar.

Kısacası, tembellik kötüdür ve tutarlılık iyidir (kullanılan teknolojiden bağımsız olarak). Hepsini MFC ve kısmen MFC ve kısmen Winforms ve kısmen WebGL hepsini birbirine bağlayan birçok farklı arka uç mimarileri olan bir uygulama var.