आप सॉफ़्टवेयर दोषों का प्रमुख कारण क्या मानते हैं (और उन्हें कैसे कम करें) [बंद]

Question

मैं दोष को इस प्रकार परिभाषित करता हूं :

"एप्लिकेशन डिज़ाइन या कोड के भीतर कुछ जो इसे आवश्यकताओं के अनुसार कार्य करने से रोकता है।"

मैं दोषों के कारणों के बारे में विचारों की तलाश कर रहा हूं, जैसे मानव कारक, परीक्षण की कमी, प्रोटोटाइप की कमी, और इन को कम करने के लिए संभावित विचार।

Comments

मैं "उपयोगकर्ता की आवश्यकताओं" या "अपेक्षित व्यवहार" द्वारा "आवश्यकताओं" को बदल दूंगा क्योंकि यहां तक ​​कि आवश्यकताएं गलत भी हो सकती हैं।

— मौविसील

कि आवश्यकताएं गलत हैं? (और कोड सही?)

Answer 1

सॉफ्टवेयर दोषों का मुख्य कारण व्याख्या है।

फीचर की ग्राहक व्याख्या डिजाइनर व्याख्या से भिन्न होती है।

डिजाइनर व्याख्या प्रोग्रामर व्याख्या से अलग है।

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

परीक्षण केवल समस्याओं का जल्द पता लगा सकता है। लेकिन यहां तक ​​कि परीक्षक भी मानव हैं, और यह 100% परीक्षण करने के लिए असंभव है। यदि आप ब्रह्मांड के समाप्त होने से पहले जारी करना चाहते हैं।

Comments

अगर मैं केवल काम करने के लिए उस मन-पाठक मॉड्यूल को प्राप्त कर सका, तो सब ठीक हो जाएगा।

— HLGEM

@Gamecat: और पूरी दुनिया के लोगों के साथ काम करने पर यह और भी खराब हो जाता है। न केवल एक भाषा बाधा है (अक्सर प्रतिभागियों में से कम से कम एक भागीदार अंग्रेजी में कुशल नहीं है), लेकिन सांस्कृतिक अंतर भी हैं।

— Matthieu M.

आपने एक को याद किया - "प्रोग्रामर की व्याख्या संकलक की व्याख्या से भिन्न है" ...?)

— एलेक्स फेनमैन

@ एलेक्स: मुझे पता है कि कंपाइलर मेरे द्वारा लिखे गए कोड के साथ क्या करेगा। यह ज्ञान हासिल करना आसान नहीं था, लेकिन मैंने यह कर दिखाया। अब, मेरे पास उस कोड की मेरी व्याख्या है जो मैंने कंपाइलर और रनटाइम डेटा के विपरीत नहीं लिखा था।

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

@ डेविड, जब तक आपने कंपाइलर नहीं लिखा और बनाए रखा, तब तक आपका ज्ञान क्या हो रहा है, जो वास्तव में चल रहा है, उसका एक अमूर्त हिस्सा है - और यह शायद सबसे अच्छे के लिए है, क्योंकि यह आपको वास्तविक एप्लिकेशन पर दिमाग खर्च करने की अनुमति देता है।

— एलेक्स फेनमैन

Answer 2

मैं सॉफ्टवेयर दोषों के प्रमुख कारण को प्रोग्रामर मानता हूं।

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

इसका एक हिस्सा अंत उपयोगकर्ता की शब्दावली को सीखने / समझने के लिए तैयार नहीं होने से आता है, जिससे गलतफहमी पैदा होती है।

इसका एक हिस्सा उन लोगों के लिए प्रक्रिया में बहुत जल्दी बात करने से आता है जिनके पास कोई सुराग नहीं है कि आप किस बारे में बात कर रहे हैं या यह क्यों मायने रखता है।

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

Answer 3

दोष का प्राथमिक कारण खराब प्रबंधन है ;)

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

इसके अलावा खराब डेवलपर्स को प्रबंधित करने से प्रबंधन भी बग की संख्या बढ़ाने में मदद करता है।

खराब प्रबंधन ।

(अस्वीकरण: मैं डेवलपर्स को नियुक्त और प्रबंधित करने वाला हूं)

Comments

ऐसा मत सोचो कि प्राथमिक मुद्दा है, अधिकांश देव शांत परिस्थितियों में काम करते हैं। मैं AnonJr और Gamecat से सहमत हूं - समस्या डोमेन को पूरी तरह से समझने में असमर्थता, केवल त्वरित पुनरावृत्तियों और परीक्षण से मदद मिल सकती है।

— radekg

शांत स्थितियों में अधिकांश देव काम कैसे करते हैं? पिछले साल मैंने जिन दर्जन कंपनियों का दौरा किया है, उनमें से कोई भी शांत नहीं था।

अच्छा प्रबंधन आपको दूर ले जा सकता है, बुरा प्रबंधन आपको कहीं नहीं ले जा सकता है!

— क्रिस

चुप काम करने की स्थिति के बारे में +1। मैंने कभी भी जिस कंपनी में काम किया है, वह दिलबर्टस क्यूबिकल फार्म है, जहाँ आप लोगों से लगातार 4 फीट सुन सकते हैं, अपने नाखूनों को काटते हुए, उनके भोजन को कुतरते हुए, और फोन कॉल करते हुए।

— बॉबी टेबल्स

Answer 4

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

अधिकांश विकास पद्धतियां जिनका मैं अध्ययन करता हूं, वे कम करने के लिए उबलते हैं N, क्योंकि एक कार्यक्रम की जटिलता कम से कम O(N^2)और संभवतः है O(k^N)। परिभाषित करना Nपाठक के लिए एक अभ्यास के रूप में छोड़ दिया जाता है, लेकिन मैं यहां चक्रवाती जटिलता जैसी चीजों के बारे में सोच रहा हूं। तर्क और डेटा को एनकैप्सुलेट करने से समस्या को कम करके एन को कम करने का प्रभाव पड़ता है।

Answer 5

सब कुछ सोचने की अशुभता।

Answer 6

अधूरा होना

Answer 7

संवादहीनता। आवश्यकताओं के संग्रह में। अनुसूची में। डिज़ाइन दस्तावेज़ में। कार्यात्मक विनिर्देश में। कोड में (क्या प्रोग्रामर चाहता है और क्या वह संकलक बताता है) के बीच अंतर।

सामाजिक शिष्टाचार। किसी को असमर्थ कहने के लिए सामाजिक रूप से अस्वीकार्य है।

Answer 8

उन्हें पूरी तरह से समझे बिना चीजों में भागना। कार्यात्मक आवश्यकताओं या तकनीकी वास्तुकला को पूरी तरह से समझने के बिना कोड लिखना शुरू करना।

प्रोग्रामिंग लगभग स्वचालित होना चाहिए, बस यह लिखना कि जो स्वयं स्पष्ट है और पहले से ही दिमाग में काम किया गया है। व्यवहार में, मैं कोड में बहुत से प्रवाह को देखता हूं कि वास्तव में कोड क्या करना चाहिए, इस पर एक हैंडल पाने की कोशिश करता है। मैं कई बार खुद इसके लिए दोषी रहा हूं।

Comments

एक नई नौकरी में चार महीने, मैं अभी भी कुछ भी "पूरी तरह से समझने" में केवल एक छोटा% हूं। मैं जल्दी नहीं जा रहा हूँ; आप जो कहते हैं वह सच है। हालांकि लंबे समय तक अनुत्पादक रहना बेकार है।

— डेरेनव

मुझे (2 मिलियन लाइन सिस्टम) पर काम करने वाली प्रणाली पर पूरी गति से उठने में एक या दो साल लग गए। फिर भी इसके बड़े हिस्से हैं जो मुझे नहीं पता हैं।

— जोएरी सेब्रचेट्स

Answer 9

एरेरे ह्यूमनम एस्ट

Answer 10

अनुसूची दबाव प्रमाणित रूप से एक मजबूत स्रोत है।

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

Answer 11

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

Answer 12

ऐसा इसलिए है क्योंकि सॉफ्टवेयर इंजीनियरिंग स्वाभाविक रूप से जटिल है। "नो सिल्वर बुलेट" निबंध इस पर चर्चा करता है।

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

Answer 13

सॉफ्टवेयर को राज्य मशीनों के नेटवर्क के रूप में समझने में विफलता, उनके संचालन (राज्यों, उनके दृढ़ संकल्प और संक्रमण), और राज्य मशीनों के इंटरैक्शन को अंतर्निहित सिद्धांत।

Answer 14

कोड लिखना जो चुपचाप विफल रहता है बनाम कोड जो सभी त्रुटियों की रिपोर्ट करता है।

Answer 15

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

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

Answer 16

सॉफ्टवेयर दोषों का मुख्य कारण कोड लिखना है।

कम कोड लिखें और आपके पास कम कीड़े होंगे ;-)

Answer 17

एक स्तर पर, प्रबंधन। लेकिन यह सिर्फ PHB नहीं है। यह स्वयं कोड का प्रबंधन है, जो कॉर्पोरेट प्रबंधन का प्रतिबिंब हो सकता है या नहीं भी हो सकता है।

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