क्या कारण हैं जो एक अतिभारित सॉफ़्टवेयर का नेतृत्व करते हैं? [बन्द है]

Question

आज मैंने क्रिएटिव साउंड ब्लास्टर ड्राइवरों के लिए एक क्लीन इन्स्टॉल करने का फैसला किया, क्योंकि वे हमेशा कुछ समय के बाद अपने आप को सभी से अलग करना शुरू कर देते हैं। और इसका मतलब था कि मुझे पूरी सफाई प्रक्रिया से गुजरना होगा। और मुझे लगभग 2 घंटे लग गए।

और ईमानदारी से, मैं एक कारण नहीं देख सकता हूँ क्यों ?! और यद्यपि क्रिएटिव, IMHO, खराब गुणवत्ता वाले सॉफ़्टवेयर का उत्पादन करने के लिए एक निरपेक्ष 1 स्थान विजेता है, जो कभी काम नहीं करता है, ब्लोट समस्या उनके लिए अनन्य नहीं है।

कैनन डिजिटल कैमरा ड्राइवर के साथ पीसी में लगभग 10 कैनन प्रविष्टियां होंगी जो सभी प्रकार के कनेक्शनों के साथ जुड़ी हुई हैं। विजुअल स्टूडियो भी एक प्रमुख उदाहरण है, पूर्ण स्थापित करने के लिए लगभग 50 या तो प्रविष्टियाँ हैं, और उस चीज़ की मरम्मत केवल पूरी नक़्क़ाशी के साथ संभव है। और जब मैं VS2k8 से VS2k8SP1 या कुछ और के लिए अपग्रेड कर रहा था, तो एक बार यह भी पूरे ओएस को बर्बाद करने में कामयाब रहा। जैसा कि यह पता चला है कि 5 जीबी मुक्त स्थान 300Mb पैच के लिए पर्याप्त नहीं था ...

तो यह वास्तव में एक व्यापक समस्या प्रतीत होती है। आजकल लगभग हर एप्लिकेशन में आमतौर पर अनपैकर्स, कई स्पाइवेयर "मित्र" होते हैं जो इंस्टॉल किए जाते हैं, ड्राइवर आमतौर पर प्रिंटर और इतने पर सब कुछ के लिए लगभग 600Mb होते हैं।

लेकिन क्यों? क्या यह डेवलपर की गलती है? उस तरह के अनुप्रयोग समर्थन करने के लिए दुःस्वप्न हैं, वे आजकल 100% काम नहीं करते हैं, और लगभग सभी उपयोगकर्ताओं को मैं जानता हूं कि उन सभी के बारे में बहुत नकारात्मक हैं जो उन्हें यूएसबी थंब ड्राइव / प्रिंटर / कैमरा / साउंड कार्ड / ब्राउज़र के लिए अनिवार्य ड्राइवर के रूप में मिलते हैं।

ऐसा लगता है कि Nullsoft से NSIS एकमात्र स्वच्छ सेटअप प्रणाली है जो फूला हुआ नहीं है, जो मैं जानता हूं, उदाहरण के लिए, फ़ायरफ़ॉक्स स्थापित करता है। साफ, बहुत ज्यादा xcopy आधारित किसी भी समस्याओं के बिना स्थापित करें।

तो लोग साधारण सेटअप और एप्लिकेशन का उपयोग क्यों नहीं कर रहे हैं जो इंटरकनेक्शन की 30 परतों पर निहित नहीं हैं? क्या यह इसलिए है क्योंकि डेवलपर्स आलसी हैं? कोडजेन टूल्स का उपयोग? क्या ऐसा इसलिए है क्योंकि कॉर्पोरेशन भारी-भरकम ऐप्स को मजबूर करते हैं क्योंकि कुछ उपयोगकर्ता पसंद करेंगे? क्या कारण है, और क्या कोई आशा है कि सॉफ्टवेयर किसी दिन मूल बातें लौटाएगा? जब आप नए एप्लिकेशन को स्क्रैच से शुरू करते हैं तो ब्लोट लिखने से बचने के लिए क्या कदम हैं?

Comments

अनवरत वृद्धि # अनियंत्रित विस्तार। कोई नई सुविधाएँ, डेवलपर्स के लिए कुछ भी नहीं करना है।

— रॉबर्ट हार्वे

"खराब गुणवत्ता सॉफ्टवेयर है कि कभी नहीं काम करता है के उत्पादन के लिए पूर्ण 1 जगह विजेता" - जाहिर है आप को Samsung Kies उपयोग नहीं किया है ;-)

— डीन हार्डिंग

वही कारण है कि एक गन्दा रसोई के लिए नेतृत्व: बढ़ती एन्ट्रापी। चीजों को व्यवस्थित रखने के लिए बहुत अधिक ध्यान और ऊर्जा लगती है। संभावना है कि कुछ अतिरिक्त परिवर्तन अधिक क्रम से अधिक अराजकता पैदा करेंगे।

— नौकरी का

यह प्रश्न ब्लोट के बारे में नहीं लगता है, बल्कि सॉफ़्टवेयर स्थापित करने और अनइंस्टॉल करने की समस्याओं के बारे में है।

— डेविड थॉर्नले

साइट पर खराब प्रबंधन और वास्तुकला।

— पॉल

Answer 1

मेरा अनुमान है कि बहुत सारी विशेषताएं हैं जो किसी ने सोचा था कि यह एक अच्छा विचार है। हालांकि, अगर बहुत सारे लोगों के पास अलग-अलग विचार हैं जो एक आवेदन में एक साथ रखे जाते हैं, तो यह है कि यह कितना जटिल हो सकता है। मैं बड़े कॉर्पोरेट उत्पादों के मामले में डेवलपर को दोष नहीं दूंगा जहां उत्पाद प्रबंधक होने चाहिए जो उत्पाद में क्या है और विभिन्न दृष्टिकोणों से इसे कैसे अनुकूलित करें, के लिए एक जिम्मेदारी है।

इसका एक और पक्ष होगा तकनीकी ऋण जो कि ज्यादातर मामलों में अच्छी तरह से प्रबंधित नहीं होता है क्योंकि इसे समय के महान निवेश के रूप में नहीं देखा जाता है। मुझे नई विशेषताओं पर संदेह होगा और बग फिक्स रिफैक्टोरिंग या अन्य ऋण कार्यों की तुलना में अधिक समझ में आता है जो कि तत्काल व्यावसायिक मूल्य हो सकते हैं। यदि कोड का आधार पुराना है, तो डेवलपर्स की एक टीम को विरासत कोड को साफ करने के लिए कुछ हफ़्ते कैसे मिलेंगे? मेरा अनुमान अक्सर नहीं होगा।

Answer 2

जोएल को रणनीति पत्र IV में उद्धृत करने के लिए : ब्लोटवेयर और 80/20 मिथक :

[...] ब्लोटवेयर के कई बड़े कारण हैं। एक के लिए, यदि प्रोग्रामर्स को इस बात की चिंता नहीं है कि उनका कोड कितना बड़ा है, तो वे इसे जल्द ही शिप कर सकते हैं। [...] यदि आपका सॉफ़्टवेयर विक्रेता शिपिंग से पहले बंद हो जाता है, और दो महीने खर्च करता है, तो इसे ५०% छोटा बनाने के लिए कोड को निचोड़ कर, आपके लिए शुद्ध लाभ अपरिहार्य होने वाला है। [...] लेकिन नए संस्करण के लिए अतिरिक्त दो महीने इंतजार करने का नुकसान आपको बोधगम्य है, और सॉफ़्टवेयर कंपनी को दो महीने की बिक्री छोड़ देने का नुकसान और भी बदतर है।

बहुत सारे सॉफ्टवेयर डेवलपर पुराने "80/20" नियम से बहक जाते हैं। यह लगता है भावना का एक बहुत बनाने के लिए: 80% लोगों ने सुविधाओं के 20% का उपयोग करें। तो आप अपने आप को आश्वस्त करते हैं कि आपको केवल 20% विशेषताओं को लागू करने की आवश्यकता है, और आप अभी भी कई प्रतियों के रूप में 80% बेच सकते हैं।

दुर्भाग्य से, यह कभी भी 20% नहीं है। हर कोई सुविधाओं के एक अलग सेट का उपयोग करता है। [...]

जब आप अपने "लाइट" उत्पाद का विपणन शुरू करते हैं, और आप लोगों को बताते हैं, "हे, यह लाइट है, केवल 1 एमबी," वे बहुत खुश होते हैं, तो वे आपसे पूछते हैं कि क्या यह उनकी महत्वपूर्ण विशेषता है, और ऐसा नहीं है, इसलिए वे आपका उत्पाद नहीं खरीदते हैं।

Comments

यह केवल एक बात है "यदि केवल आवश्यक और सही कोड लिखने पर प्रोग्रामर को यह चिंता न हो कि उनका कोड कितना बड़ा है", और प्रोग्रामर के पास एक बहुत अलग बात है लापरवाही से लिखने और कोड जोड़ने की जो अनावश्यक रूप से एक प्रोग्राम का आकार बढ़ा देगा। बस जल्द ही शिपिंग के लिए। लेकिन कोड का आकार वास्तव में समस्या नहीं है; समस्या यह है कि अधिकांश यदि सभी फूला हुआ कार्यक्रम अक्षम, धीमा, छोटी गाड़ी, अविश्वसनीय, अक्सर दुर्घटना नहीं होते हैं, तो उपयोगकर्ताओं को बहुत असुविधाएं और निराशा होती हैं, या घातक परिणाम होते हैं। ब्लोटवेयर ख़राब है। जल्दी जहाज करना चाहते हैं? दुबले कार्यक्रम लिखिए।

— केवल आप

बोधगम्यता, लाभ और सुधार की बात करना? "यदि आपका सॉफ़्टवेयर विक्रेता शिपिंग से पहले बंद हो जाता है, और दो महीने खर्च करता है, तो कोड को निचोड़ कर इसे 50% छोटा कर दिया जाए, तो आपके लिए शुद्ध लाभ अपरिहार्य होने वाला है।" जाहिर है, हम इससे बचना चाहते हैं, विशेषकर तब जब कोई महत्वपूर्ण या महत्वपूर्ण आवश्यकता न हो।

— केवल आप

लेकिन हम इससे भी बचना चाहते हैं: "सॉफ्टवेयर ब्लोट एक ऐसी प्रक्रिया है जिससे कंप्यूटर प्रोग्राम के क्रमिक संस्करण अवधारणात्मक रूप से धीमे हो जाते हैं, अधिक मेमोरी / डिस्कस्पेस या प्रोसेसिंग पॉवर का उपयोग करते हैं, या केवल संदिग्ध उपयोगकर्ता-बोधगम्य बनाते हुए पिछले संस्करण की तुलना में उच्च हार्डवेयर आवश्यकताएं होती हैं सुधार। " आकार के लिए आकार अच्छा नहीं है। एक बड़े कार्यक्रम को छोटा बनाना जरूरी नहीं कि यह बेहतर या अधिक कुशल हो। फिर से महत्वपूर्ण लक्ष्य कार्यक्रम की क्षमता होनी चाहिए चाहे वह कार्यक्रम आकार ही क्यों न हो। en.wikipedia.org/wiki/Software_bloat

— केवल आप

झुक विकास को सात सिद्धांतों द्वारा संक्षेपित किया जा सकता है: 1 कचरे को हटा दें 2 सीखने को बढ़ाएं 3 यथासंभव देर से निर्णय लें 4 जितनी जल्दी हो सके 5 वितरित करें टीम 6 6 में 7 बनाएँ अखंडता पूरे en.wikipedia.org/iki/Lean_software_development

— केवल आप

Answer 3

इसका एक बड़ा हिस्सा किसी उत्पाद की निर्भरता के साथ करना है। आपका ऑपरेटिंग सिस्टम सभी प्रकार की चीजों के लिए बहुत सारे मानक पुस्तकालयों के साथ है। हालांकि, इन मानक पुस्तकालयों में ओएस के विकास के दौरान विभिन्न संस्करण हैं, और कोई भी सामान्य इंस्टॉलर यह नहीं मान सकता है कि इसके खिलाफ बनाया गया विशिष्ट संस्करण वास्तव में ओएस पर मौजूद होगा।

इसलिए पूर्ण इंस्टॉलर को यह सुनिश्चित करने के लिए हर निर्भरता के सही संस्करण को शामिल करने की आवश्यकता होगी कि स्थापना के बाद सब कुछ निश्चित रूप से काम करेगा, चाहे लक्ष्य कंप्यूटर पर प्रत्येक निर्भरता की प्रारंभिक स्थिति क्या हो। यह कुछ प्रकार के अनुप्रयोगों के लिए काफी महत्वपूर्ण ब्लोट हो सकता है, उदाहरण के लिए। .NET- आधारित एप्लिकेशन जिन्हें विंडोज एक्सपी सिस्टम में तैनात किया जाना है।

हाल तक तक, एक इंस्टॉलर प्रणाली जिसे मैंने हर एक पिछले .NET संस्करण की जरूरत के साथ काम किया था, नवीनतम संस्करण को तैनात करने में सक्षम होने के लिए स्थापित किया गया था, इसलिए इसका मतलब था कि .NET 1, 2, 2.5 और 3 के लिए किसी भी .NET 3.5 आवेदन की आवश्यकता है। 3.5 के ऊपर। इस मामले में, केवल इंस्टॉलर फूला हुआ है।

एक वर्कअराउंड एक वेब इंस्टॉलर है, जो केवल उन घटकों को डाउनलोड करता है जो वास्तव में लक्ष्य प्रणाली पर मौजूद नहीं हैं - और यह एक विशाल आकार / ब्लोट लाभ हो सकता है। बेशक यह आपके इंस्टॉलेशन को उन सिस्टमों तक सीमित करता है जिनमें इंटरनेट कनेक्टिविटी है।

Comments

यह लिनक्स प्लेटफॉर्म पर विशेष रूप से खराब है। विंडोज प्लेटफॉर्म पर कष्टप्रद, लेकिन लिनक्स आधारित परियोजनाओं पर काम करते समय मुझे अपने बालों को फाड़ देना पड़ता है!

— ब्रायन नोब्लुक 20

यह विशेष रूप से विंडोज प्लेटफॉर्म पर खराब है। लिनक्स मंच पर कष्टप्रद, लेकिन विंडोज आधारित परियोजनाओं पर काम करते समय मुझे अपने बालों को फाड़ देना पड़ता है!

— पॉल

कम से कम लिनक्स पर आप केवल apt-get या yum चला सकते हैं और सभी डिपो को शॉर्ट ऑर्डर में स्थापित किया जाता है। विंडोज ... लगभग इतना आसान नहीं है।

— gbjbaanb

Answer 4

मुझे लगता है कि लाइब्रेरी कोड की परत पर इसका बहुत कुछ करना है। जाहिर है जब आप एक पुस्तकालय का उपयोग करते हैं तो आप उसमें हर चीज का उपयोग नहीं करते हैं, ताकि अतिरिक्त जुड़ जाए क्योंकि आप अधिक से अधिक पुस्तकालयों को शामिल करते हैं।

इस तथ्य के साथ जोड़िए कि एक प्रोग्रामर से एक घंटे के काम की लागत लगातार महंगी हो रही है, जबकि ठेठ कंप्यूटर की प्रोसेसिंग पावर / स्टोरेज साल से सस्ती हो रही है, आप देखते हैं कि यह वास्तव में इस तरह से अधिक लागत कुशल है।

Answer 5

• "हमें एक्स करने के लिए कुछ चाहिए। चलो लाइब्रेरी $ BIGFATLIBDESIGNEDFORSOMETHINGELSE का उपयोग करें, क्योंकि मैंने इसे एक अलग परियोजना में उपयोग किया है"
• "मुझे लगता है कि हमें अब इस कोड भाग की आवश्यकता नहीं है, लेकिन यह सुनिश्चित करने के लिए कि कुछ भी नहीं टूटता है, बस इसे बनाए रखें"
• पर्याप्त या नहीं पर्याप्त इकाई परीक्षण, जो नेतृत्व करते हैं
• कोई रिफलेक्टरिंग नहीं
• कोई ट्रैकिंग नहीं, जहां सेटिंग्स वर्षों से संग्रहीत की गई हैं, इसलिए अब सेटिंग्स हर जगह हैं
• ...

Answer 6

यह एक दुष्चक्र है जहां निराशा के चक्र में हर किसी को दोषी ठहराया जा सकता है । निराशा के एक चक्र में निम्नलिखित चरण होते हैं:

1. कारोबारी लोग फूला हुआ फीचर्स पूछते हैं।
2. डेवलपर्स फूला हुआ सुविधाओं को लागू करते हैं, भले ही उन्हें पता हो कि उन्हें नहीं करना चाहिए।
3. ग्राहक फूला हुआ सुविधाओं के लिए भुगतान करते हैं, भले ही वे केवल उत्पाद चाहते हैं, लेकिन बेवकूफ सुविधा नहीं।
4. कारोबारी लोगों का मानना ​​है कि ग्राहक फूला हुआ फीचर चाहते हैं।
5. चरण एक पर जाएं और दोहराएं।

आप इसे कैसे रोकेंगे? कैसे, इस पर कोई आसान जवाब नहीं है, लेकिन यह स्पष्ट है कि चक्र को रोकने के लिए फिर एक चरण को तोड़ना होगा। इस प्रकार यह केवल क्रांतिकारी कार्रवाई करने वाले व्यवसाय, डेवलपर्स या उपभोक्ताओं द्वारा तोड़ा जा सकता है।

Answer 7

1. एक इंजीनियर ने एक मॉड्यूल को अनुकूलित करने की कोशिश की, लेकिन कई ग्राहक मुद्दों को पेश किया। तब, उनके प्रबंधक ने कहा कि नहीं। तब, इंजीनियर ने निर्णय लिया कि "परेशानी न करें" जब तक कि परेशानी उसे परेशान न करे।
2. एक जटिल प्रणाली के लिए, विक्रेता ने पहले से ही कई पैच जोड़े और ग्राहकों के वातावरण में इसे स्थिर बनाने के लिए हजारों बग को ठीक किया। इसमें सॉफ्टवेयर की दृष्टि से अच्छी गुणवत्ता नहीं है लेकिन यह काम करता है। कोई भी फिर से बग की समान मात्रा को ठीक करने के लिए इसे फिर से लिखना नहीं चाहता है।
3. पिछड़े अनुकूलता कारणों के लिए, भले ही कोई विशेषता बाजार में लोकप्रिय नहीं है, हमें इसे वहां रखने की आवश्यकता है।

Answer 8

इसका हमेशा आलस्य, यही कारण है कि सूजन का कारण बनता है। (या इस विषय पर सेमिनल लेख में कीचड़, बिग बॉल ऑफ मड )

उदाहरण के लिए, जहां मैं काम करता हूं, हमारे पास "विरासत" सी ++ एप्लिकेशन है जो कि काफी अच्छी तरह से डिज़ाइन किया गया है, क्लाइंट एक एपीआई से बात करते हैं जो एक सर्वर से बात करता है जो डीबी काम करता है। सब समझदारी से किया। हाल ही में हमें एक अतिरिक्त मॉड्यूल की आवश्यकता थी, लेकिन इसे सही ढंग से लागू करने के बजाय देव ने इसे .NET में लागू करने का फैसला किया, और इससे भी बदतर, उसने फैसला किया कि एपीआई के माध्यम से डेटा तक पहुंचना बहुत मुश्किल था (इसके नहीं ...) लेकिन वह डीबी कनेक्शन बनाएगा सीधे। तो देखा आपने कि इस तरह की गड़बड़ कैसे होती है। (और टीए के समझौते के साथ "अच्छा" "जल्दी" डाल दिया)

मैंने पहले भी इस तरह की चीज़ देखी है - एक पुरानी जगह पर, GUI का एक छोटा हिस्सा html था, क्योंकि कुछ देवों ने सोचा था कि html में डेटा लिखना और GUI का प्रदर्शन करना है। तो 1 छोटा हिस्सा बाकी के लिए कुछ अलग करता है।

संक्षेप में, आलस्य बुरा है, और स्थिरता अच्छी है (तकनीक का उपयोग किए बिना)। मैं इसके बजाय एक MFC अनुप्रयोग है जो एक भाग MFC और भाग Winforms और कई अलग-अलग बैक-एंड आर्किटेक्चर के साथ WebGL का हिस्सा है, यह सब एक साथ बांध देता है।