जटिल सॉफ्टवेयर को कितना अतिरेक / मजबूती से लागू किया जाना चाहिए?

12

इस प्रश्न का फोकस: कुछ सॉफ़्टवेयर सॉफ़्टवेयर में एक या एक से अधिक आंतरिक त्रुटियों के बावजूद, "अंततः सफल / संतोषजनक" परिणाम की संभावना को बढ़ाने के लिए "अतिरिक्त कार्य" करते हैं, जिसमें उन त्रुटियों के होने पर लंबे समय तक निष्पादन की आवश्यकता होती है। यदि परिणाम सफल रहा, तो ये सभी उपयोगकर्ता के ज्ञान के बिना होते हैं।

जटिल सॉफ्टवेयर की परिभाषा:

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

संपादित: क्या जटिल है? कृपया देखें कि कॉम्प्लेक्स और जटिल के बीच एक बड़ा अंतर है । (सीधा लिंक)

इस प्रश्न के भीतर अतिरेक / रोबस्टनेस की परिभाषा :
(टिप्पणियों पर आधारित रोबस्टनेस)

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

ऐसे सॉफ्टवेयर का उदाहरण:

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

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

संभवतः संबंधित:

— rwong
स्रोत

5

यही कारण है कि अतिरेक नहीं, मजबूती ...

5

क्या इसका उत्तर बस इतना नहीं है "जितना आवश्यक है?"

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

@ डीन - बिल्कुल, यह किसी अन्य की तरह एक आवश्यकता है। ट्रिक यह समझाने में है और उपयोगकर्ताओं को इसके परिणाम और लागत लेकिन यह किया जा सकता है।

— जॉन हॉपकिंस

धन्यवाद @ Thorbjørn प्रतिक्रिया के लिए। मैंने शीर्षक और परिभाषा में मजबूती जोड़ी है।

— रवांग

एक पुराने कोड आधार से दूर रहें, जब तक कि आपके पास खिलाने के लिए 5 बच्चे न हों।

— नौकरी

7

यह एक व्यावसायिक प्रश्न है, तकनीकी नहीं।

कभी-कभी मैं शोधकर्ताओं के साथ या एक प्रोटोटाइप पर कोडिंग करता हूं, इसलिए हम बहुत कम मजबूती के साथ कुछ का निर्माण करेंगे। यदि यह टूट जाता है, तो हम इसे ठीक कर देते हैं। अतिरिक्त जादू में निवेश करने का कोई मतलब नहीं है अगर हम जल्द ही कोड को दूर करने जा रहे हैं।

लेकिन अगर आपके सिस्टम के उपयोगकर्ताओं को इसे मजबूत बनाने की आवश्यकता है, तो आपको इसे इस तरह से बनाना चाहिए। और आपको इसे उन तरीकों से विशेष रूप से मजबूत बनाना चाहिए जो आपको और उन्हें दीर्घकालिक सफलता को अधिकतम करने की आवश्यकता है, जबकि अतिरेक / मजबूती के प्रकारों की अनदेखी करते हुए जिनकी उन्हें आवश्यकता नहीं है।

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

— विलियम पिएत्री
स्रोत

5

कॉम्प्लेक्स सॉफ्टवेयर आमतौर पर बेमानी है जैसा कि आप शायद जानते हैं, लेकिन स्पष्ट रूप से नहीं, क्योंकि ऐसा करने का सबसे अच्छा तरीका है, लेकिन क्योंकि डेवलपर्स बड़े विस्तार से समझने के प्रयास के बजाय मौजूदा कोड पर "सौदा" करते हैं कि सॉफ्टवेयर कैसे काम करता है।

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

हालाँकि यह कहा जाना चाहिए कि ऐसा करने पर, आपको अनावश्यक कोड का उत्पादन करना पड़ सकता है। यदि परियोजना पहले से ही अतिरेकपूर्ण है, तो वास्तव में पैटर्न को जारी रखने के लिए यह अधिक सरल हो सकता है कि आपके बॉस के पास पूरे प्रोजेक्ट के पुनर्गठन की अनुमति देने के लिए आपके पास कुछ हफ़्ते नहीं हैं।

संपादित करें: प्रश्न के रीफ़्रेशिंग के प्रकाश में, मैं मजबूती के बारे में थोड़ा जोड़ दूँगा। मेरी राय में, पैरामीटर जाँच केवल तभी की जानी चाहिए जब A) आप बहुत विशिष्ट प्रारूप स्वीकार करते हैं जैसे कि स्ट्रिंग या B के रूप में दिनांक मान) विभिन्न पैरामीटर संभावित रूप से एक दूसरे के साथ संघर्ष कर सकते हैं या पारस्परिक रूप से अनन्य हैं।

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

बी) के रूप में, पारस्परिक रूप से अनन्य पैरामीटर एक खराब संरचना का प्रतिनिधित्व करते हैं। वहाँ दो वर्गों होना चाहिए, एक जो एक मामले को संभालता है और दूसरा जो इसे दूसरे तरीके से संभालता है। सभी सामान्य ऑपरेशन अतिरेक से बचने के लिए एकल बेस क्लास में किए जा सकते हैं।

ऐसी स्थितियों में जब किसी पद्धति में मापदंडों की संख्या 10+ हो जाती है, तो मैं एक संपत्ति फ़ाइल पर विचार करना शुरू करता हूं जिसमें ये सभी पैरामीटर शामिल हैं जो कि संभवतः सबसे अधिक बार बदलने वाले नहीं हैं। यदि वे बदल जाते हैं, तो आप संपत्ति फ़ाइल में डिफ़ॉल्ट को बचा सकते हैं और "setPropertyName ()" विधि जोड़ सकते हैं जो आपको रनटाइम में डिफ़ॉल्ट को ओवरराइड करने देता है।

— नील
स्रोत

4

मुझे लगता है कि आप प्रश्न को गलत समझते हैं। उसका अर्थ है "अतिरेक" जैसा कि "आग की लपटों में मरना नहीं जब कोई त्रुटि होती है" जैसा कि "डुप्लिकेट कोड लिखना" नहीं है। जैसा कि दूसरों ने बताया है, इसके लिए रोबस्टनेस एक बेहतर शब्द है।

— एडम लेअर

अतिरेक महत्वपूर्ण कार्यों में एक सकारात्मक चीज है। मानव शरीर यहाँ का आदर्श उदाहरण है।

— क्लॉडिउ क्रेगना

3

सॉफ्टवेयर को उपयोगकर्ता की गलतियों को माफ करना चाहिए, और प्रोग्रामर की गलतियों के प्रति पूरी तरह से असहिष्णु होना चाहिए।

मतलब, सॉफ्टवेयर बहुत मजबूत होना चाहिए और उपयोगकर्ता इनपुट त्रुटियों, और सिस्टम कॉन्फ़िगरेशन त्रुटियों जैसी चीजों के लिए चिकनी वसूली की अनुमति देता है। कम से कम एक मैत्रीपूर्ण त्रुटि संदेश बताते हुए कि त्रुटि कहाँ हुई (इनपुट बॉक्स, कॉन्फिग फ़ाइल, कमांड लाइन तर्क, आदि ...) और किस बाधा का उल्लंघन किया गया ("X वर्णों से कम होना चाहिए," "वैध विकल्प हैं [X] , वाई, जेड] ", आदि ...) अतिरिक्त मजबूती के लिए, सॉफ्टवेयर एक विकल्प का सुझाव दे सकता है, या एक उचित डिफ़ॉल्ट का उपयोग कर सकता है (लेकिन यह हमेशा इंगित करना चाहिए कि यह वही उपयोग नहीं कर रहा है जो उपयोगकर्ता निर्दिष्ट करता है)।

मैं ऐसी बहुत सी स्थितियों के बारे में नहीं सोच सकता जहाँ अलग-अलग चूक के साथ एक स्वचालित रिट्री को वारंट किया गया हो, लेकिन कुछ हैं (संचार लिंक को स्थापित करने के लिए ऑटो रिट्रीट करना उचित लगता है)। मैं @William से सहमत हूं कि 'अतिरेक' का यह स्तर एक निर्णय है।

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

 int A(int x)
 {
   if (x==0) return -1
   ...
 }
 int B(int x)
 {
   if (x==0) return -1
   err = A(x)
   if (err) return err;
   ...
 }
 // and so on and so on....

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

— AShelly
स्रोत

3

यह आवश्यकताओं की बात है।

क्या मजबूती की आवश्यकता है?

"जब संचार लिंक विफल हो जाता है, तो गलत पैकेट को छोड़ दिया जाता है" "जब लिंक ऑपरेशन शुरू करता है, तो कोई लेनदेन दो बार संसाधित नहीं होता है"

त्रुटि पुनर्प्राप्ति के लिए मामलों का उपयोग होना चाहिए (अन्यथा आप कैसे जानते हैं कि यह कैसे होगा?)

प्रोग्रामर के पास छोड़ने के लिए मजबूती का आविष्कार करने के लिए क्योंकि वे जाते हैं (यदि आवश्यक हो) "जादुई" सिस्टम में परिणाम।

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

— टिम विलिसक्रॉफ्ट
स्रोत

2

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

— मैट एच
स्रोत

यदि रिट्री को बिना गिना और रिपोर्ट किए / दिखाई दिए बिना किया जाता है, तो आपके सिस्टम अपने जादुई आत्म-सुधार प्रकृति के कारण खराब हो जाएंगे और समाप्त हो जाएंगे। रिट्रीट और त्रुटियों की रिपोर्ट करने के लिए हमेशा टपका हुआ बाल्टी काउंटर (PLOPD4) का उपयोग करें। इस तरह, एक निम्न स्तर को नजरअंदाज कर दिया जाता है, लेकिन उपयोगकर्ताओं को समस्याएं दिखाई देती हैं।

— टिम विस्क्राफ्ट