शून्य-बग प्रोग्रामर कैसे बनें? [बन्द है]


168

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

मैं एक शून्य बग प्रोग्रामर कैसे हो सकता हूं और यह जान सकता हूं कि मेरे कोड का हर चरित्र क्या कारण और प्रभावित करेगा?


मेरे अलावा कोई भी वास्तव में पहली बार सही कोड नहीं बनाता है। लेकिन मेरा एक ही है। - टेक टॉक: लिनस टोरवाल्ड्स ऑन गिट, गूगल, 15 अगस्त 2007 izquotes.com/quote/273558
JensG


0-बग प्रोग्रामिंग जैसी कोई चीज नहीं है। समझने के लिए गणितज्ञ गोडेल पढ़ें।
माइकल मार्टिनेज

यह एक गलत लक्ष्य है, देखें: yegor256.com/2015/06/18/good-programmers-bug-free.html
yegor256

जवाबों:


365

कोड बिल्कुल नहीं।

यह एकमात्र तरीका है जिससे आप शून्य बग प्रोग्रामर बन सकते हैं।

कीड़े अपरिहार्य हैं क्योंकि प्रोग्रामर मानव हैं, हम सब कर सकते हैं उन्हें रोकने के लिए हमारी पूरी कोशिश है, बग होने पर जल्दी से प्रतिक्रिया करें, हमारी गलतियों से सीखें और अद्यतित रहें।


73
+1 का पालन करें: या आप एक गैर-कोडिंग (हाथी दांत टॉवर) आर्किटेक्ट बन सकते हैं और अभी भी बहुत भुगतान किया जा सकता है! वह तो सबसे अच्छा है।
मार्टिन विकमैन

26
गलती करने के लिए मानव है, अपने कीड़े दिव्य को ठीक करने के लिए।
वार्ड मुइलैर्ट

11
मेरे पास एक सह-कार्यकर्ता हुआ करता था जो बॉस का पक्षधर था क्योंकि उसके पास लगातार एक छोटी बग गिनती थी। उसने यह कैसे किया? सरल, वह बग्स को असाइन करती है जो वह किसी और को नहीं करना चाहती थी, और हमेशा सबसे आसान / सबसे छोटी सुविधाओं को लेती थी।
टोबी

46
मुझे नहीं पता कि यह पहले किसने कहा था, लेकिन, "यदि डिबगिंग कीड़े को हटाने की प्रक्रिया है, तो प्रोग्रामिंग को डालने की प्रक्रिया होनी चाहिए।"
ब्रूस एल्डरमैन

8
इससे भी बेहतर: एक बॉस बनें और अपनी अंडरगार्मेंट्स को किसी भी चीज की जिम्मेदारी लिए बिना दुखी महसूस करें।
बिजिकलोप

124

गैर-तुच्छ कार्यक्रम के लिए शून्य बग असंभव है।

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

यह सॉफ्टवेयर बग-फ्री है। यह एकदम सही है, जैसा कि इंसानों ने हासिल किया है। इन आँकड़ों पर विचार करें: कार्यक्रम के अंतिम तीन संस्करण - प्रत्येक 420,000 लंबी लाइनें - प्रत्येक में सिर्फ एक त्रुटि थी। इस सॉफ्टवेयर के अंतिम 11 संस्करणों में कुल 17 त्रुटियां थीं।

ग्लोबल पोजिशनिंग सैटलाइट्स के साथ नेविगेट करने के लिए शटल को अनुमति देने के लिए सॉफ़्टवेयर के अपग्रेड को लें, एक बदलाव जिसमें प्रोग्राम का सिर्फ 1.5% या कोड की 6,366 लाइनें शामिल हैं। उस बदलाव के लिए विनिर्देशों में 2,500 पृष्ठ हैं, जो फोन बुक की तुलना में अधिक मोटा है। वर्तमान कार्यक्रम के लिए विनिर्देश 30 खंडों को भरते हैं और 40,000 पृष्ठ चलाते हैं।


3
असंभव नहीं। लेकिन अत्यधिक संभावना नहीं है।
बिली ओनेल

36
आपको क्या लगता है कि FB बग-मुक्त है? फेसबुक का सिक्योरिटी और प्राइवेसी मॉडल एक बहुत बड़ा बग है। उदाहरण के लिए, सुरक्षा कमजोरियों के कारण पिछले हफ्ते फेसबुक के बॉस का फेसबुक अकाउंट हैक हो गया।
स्टीफन सी

6
@ ईलीन फेसबुक का दर्शन "जल्दी जाओ और चीजों को तोड़ो " ( geek.com/articles/news/… ) है और उनके पास अनगिनत बग ( facebook.com/board.php?uid=74769995908 ) हैं, जिनमें से कई मैं चला चुका हूं अपने आप में। ट्विटर अलग नहीं, बार-बार नीचे होने के लिए जाना (है engineering.twitter.com/2010/02/anatomy-of-whale.html इस तरह के "बग का पालन करें" (के रूप में) और कीड़े status.twitter.com/post/587210796/... )।
येवगेनी ब्रिकमैन

9
चलती गोलपोस्ट को मत भूलना। अपने परफेक्टप्रोग्राम 1.0 में एक फीचर 2.0 में बग
कार्लोस

4
@CodesInChaos: सिद्धांत कहता है कि ऐसे कार्यक्रम मौजूद हैं जिनके लिए उनके व्यवहार को साबित करना असंभव है। यह नहीं कहता कि सभी कार्यक्रमों के व्यवहार को साबित करना असंभव है । मुझे लगता है कि सामान्य कार्यक्रमों में से अधिकांश सिद्ध प्रकार के होते हैं, और दावा करते हैं कि "मेरे कोड के लिए बग-मुक्त होना असंभव है क्योंकि हॉल्टिंग समस्या के कारण" सिद्धांत का गलत उपयोग है।
एंडोलिथ

98

"ज़ीरो-बग प्रोग्रामर" एक ऑक्सिमोरॉन है, एक मूक गायक की तरह, लेकिन पिछले 60 या इतने सालों की प्रोग्रामिंग ने बुद्धिमानी के कुछ आसुत बिट्स का उत्पादन किया है, जो आपको एक बेहतर प्रोग्रामर बना देगा, जैसे:

  • विनम्र रहें - आप हैं और गलतियाँ करेंगे। बार-बार।
  • अपनी खोपड़ी के सीमित आकार के बारे में पूरी तरह से अवगत रहें। पूर्ण विनम्रता के साथ दृष्टिकोण का कार्य करें, और प्लेग की तरह चतुर चाल से बचें। [एद्गर दिक्स्ट्रा]
  • जुझारू विस्फोट लड़ो
  • परस्पर स्थिति से छुटकारा पाएं (जहां कभी संभव हो)। हां, कार्यात्मक प्रोग्रामिंग सीखें।
  • संभव कोड रास्तों की संख्या कम करें
  • इनपुट और आउटपुट रिक्त स्थान (आपके कार्यों के) के आकार को समझें, और 100% परीक्षण कवरेज के करीब लाने के लिए उन्हें कम करने का प्रयास करें।
  • हमेशा मान लें कि आपका कोड काम नहीं कर रहा है - इसे अन्यथा साबित करें!

2
मुझे यह साबित करने में खुशी होगी कि मेरा कोड काम कर रहा है ... लेकिन परीक्षण केवल यह साबित कर सकता है कि यह नहीं है। क्या आप औपचारिक प्रमाण की बात कर रहे हैं या डिबगिंग कार्य की कल्पना कर रहे हैं?
Matthieu M.

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

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

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

"प्लेग की तरह चतुर चाल से बचें" - यह अकेले ही यह अच्छा जवाब देगा। जैसा है - वैसा महान है।
B36ови36

25

TDD

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

TDD दृष्टिकोण कम से कम दो लाभ देता है।

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

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

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

मेरा मानना ​​है कि TDD में जो विकास टीमें अच्छी हैं, वे सबसे कम दोषों के साथ कोड प्रदान करती हैं।


19

बात यह है, कीड़े ऐसी चीजें हैं जिन्हें आप नहीं पहचानते हैं। जब तक आपके पास प्रोग्रामिंग भाषा / कंपाइलर के कुछ प्रकार के ज्ञानकोश होते हैं, साथ ही आपके द्वारा चलाए जाने वाले सभी वातावरणों में, आप वास्तव में 100% बग-मुक्त कोड का उत्पादन करने की उम्मीद नहीं कर सकते।

आप बहुत सारे परीक्षण के माध्यम से अपने बग की संख्या को कम कर सकते हैं, लेकिन अंत में कुछ फ्रिंज केस की संभावना होगी जिसका कोई हिसाब नहीं होगा। जोएल स्पोलस्की ने बग-फिक्सिंग पर एक विशेष रूप से अच्छा लेख लिखा ।


1
+1। ट्विस्टेड सिस्टर के शब्दों में, आप जो नहीं जानते हैं वह आपको चोट पहुंचा सकती है / जो आप नहीं देख सकते हैं वह आपको चिल्लाता है।
इंजीनियर

17

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

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

8

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

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

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

आप कितने पेशों का नाम ले सकते हैं जो हमेशा अपने कार्य को बिना सहकर्मी समीक्षा और / या परीक्षण के पहली बार ठीक करवाते हैं?


8

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

मुख्यधारा के कोडिंग वातावरण (जावा, सी #, पीएचपी, आदि) में बग-मुक्त कोड प्राप्त करना असाधारण रूप से कठिन है। मैं लघु नियंत्रित पुनरावृत्तियों में अच्छी तरह से परीक्षण किए गए और सहकर्मी-समीक्षित कोड के उत्पादन पर ध्यान केंद्रित करूंगा ।

कोड को सरल रखते हुए आप बग्स से बचने में मदद करेंगे।

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


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

मैं कहूंगा कि आपको एडा की आवश्यकता है, लेकिन लिस्प अधिक मजेदार है। ;-)
परिक्रमा

1
@ ईलाइन जहां मैं काम करता हूं वह एक जावा वातावरण है और कोड केवल टीम के साथ साझा किया जा सकता है यदि यह फाइंडबग्स और पीएमडी से गुजर चुका है। नई टीम के सदस्य पांच चरणों से गुजरते हैं: इनकार, क्रोध, सौदेबाजी, अवसाद और फिर स्वीकृति। बाद में उन्होंने कभी पीछे मुड़कर नहीं देखा।
गैरी रोवे

@ गैरी रोवे, मैं उन प्रतिक्रियाओं को समझता हूं, योग्य, मैं कभी भी एक कंपनी में रहा हूं एक क्यूए विभाग था, वहां के कर्मचारियों ने साप्ताहिक उस सप्ताह में उत्पादित सभी कोड की जांच की, यह देखने के लिए कि क्या कोड की हर लाइनें 'नियम के अनुरूप हैं। '(मुझे इस बारे में कोई जानकारी नहीं है कि वे कुछ उपकरण जैसे फाइंडबग्स / पीएमडी का उपयोग कर रहे थे), लेकिन यह उस कदम की तरह थोड़ा सा लगता है जो आप कर रहे हैं।
एलेन

1
@ गैरी: मुझसे कोई तर्क नहीं, लेकिन कई जगहों पर मैंने शैली के उल्लंघन को बग समतुल्य माना है। और उन्होंने "हर वर्ग को स्थिर क्षेत्र CLS_PKG और CLS_NAME जिसमें पैकेज और वर्ग के नाम शामिल हैं, घोषित करना चाहिए" जैसे शैली नियम हैं। मैं आम तौर पर कोडिंग मानकों का समर्थन करता हूं, लेकिन तब नहीं जब वे इस तरह सामान में विकसित होते हैं!
TMN

8

सभी "सभी पर कोड न करें।" उत्तर बिंदु पूरी तरह से गायब हैं। इसके अलावा, आपका बॉस निश्चित रूप से एक मूर्ख नहीं लगता है!

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

व्यक्तिगत रूप से, मैं कभी भी ऐसा कोड नहीं बनाऊँगा जहाँ मैं हर एक पंक्ति की व्याख्या न कर सकूँ। हर लाइन में एक कारण है, अन्यथा इसे हटा दिया जाना चाहिए। बेशक कभी-कभी आप अपने द्वारा बताए जाने वाले तरीकों के आंतरिक कामकाज की धारणा बना लेंगे, अन्यथा आपको पूरे ढांचे के आंतरिक तर्क को जानना होगा।

आपका बॉस यह कहने के लिए पूरी तरह से सही है कि आपको मौजूदा सिस्टम पर लिखे गए कोड के परिणाम और प्रभाव को समझना चाहिए। क्या बगिया में कीड़े पड़ेंगे? हां बिल्कुल। लेकिन ये बग आपके द्वारा काम किए गए सिस्टम / टूल की आपकी अधूरी समझ के कारण होंगे और हर बग फिक्स के साथ आपके पास बेहतर कवरेज होगा।


"आपके द्वारा सामना किए जाने वाले हर बग के साथ या उसके बारे में पढ़कर आप उसे उन चीजों से जोड़ सकते हैं जो आप अगली बार कुछ लिखने / बदलने के बारे में सोचना चाहते हैं" यह एक महान बिंदु है। मैंने बग के लिए एक Google दस्तावेज़ बनाया है जिसे मैंने देखा है या कोडित किया है, बस उस उद्देश्य के लिए।
बेन

7

जैसा कि अन्य टिप्पणियां पहले ही सही ढंग से बता चुकी हैं, बग के बिना कोई गैर-तुच्छ सॉफ़्टवेयर नहीं है।

यदि आप सॉफ़्टवेयर का परीक्षण करना चाहते हैं, तो हमेशा ध्यान रखें, कि परीक्षण केवल बग की उपस्थिति को साबित कर सकते हैं उनकी अनुपस्थिति नहीं।

अपने कार्यक्षेत्र के आधार पर आप अपने सॉफ़्टवेयर के औपचारिक सत्यापन की कोशिश कर सकते हैं। औपचारिक तरीकों का उपयोग करके आप यह सुनिश्चित कर सकते हैं कि आपका सॉफ़्टवेयर बिल्कुल विनिर्देश से मिलता है।

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

तो "बग" की अपनी परिभाषा के आधार पर आप औपचारिक सत्यापन की कोशिश कर सकते हैं या बस अपने सॉफ़्टवेयर में जितने कीड़े हो सकते हैं, खोजने की कोशिश करें।


6

या तो "हैलो वर्ल्ड!" या यदि आप सभी से कहते हैं कि इसका उपयोग कभी न करें।

अपने बॉस से इसके कुछ उदाहरणों के लिए पूछें जिन्हें तथाकथित बग फ्री कोड कहा जाता है।


5

मैं अन्य लोगों से सहमत हूं। यहां बताया गया है कि मैं इस समस्या से कैसे निपटूंगा

  • एक परीक्षक प्राप्त करें। क्यों के लिए जोएल टेस्ट देखें।
  • बड़े पैमाने पर पुस्तकालयों का उपयोग करें; शायद बेहतर डिबग किया गया है। मैं पर्ल के लिए CPAN का बहुत बड़ा प्रशंसक हूं।

1
... लेकिन अगर आप पुस्तकालयों का उपयोग करते हैं, तो सुनिश्चित करें कि उनके कीड़े आपको नीचे नहीं खींच सकते हैं (उदाहरण के लिए, स्रोत होने से आप इसे ऑडिट कर सकते हैं या यदि आवश्यक हो तो बग को स्वयं ठीक कर सकते हैं)।
मिलेनियो

5

आप शून्य बग प्रोग्रामर बनने का प्रयास कर सकते हैं। जब भी मैं कोड लिख रहा हूं, मैं एक शून्य बग प्रोग्रामर बनने का प्रयास करता हूं। हालाँकि, मैं नहीं

  • कई परीक्षण तकनीकें संलग्न करें (अन्य जो ATDD)
  • हमारे सॉफ्टवेयर के औपचारिक सत्यापन बनाएँ
  • एक अलग क्यूए टीम है
  • कोड आधार पर किए गए प्रत्येक परिवर्तन पर कठिन विश्लेषण करें
  • ऐसी भाषा का उपयोग करें जो सुरक्षा और सावधानी की ओर अधिक झुकती है

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

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

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


4

मुझे लगता है कि "जीरो-बग" प्रोग्रामर बनने की दिशा में एक अच्छा पहला कदम है, बग के प्रति अपना दृष्टिकोण बदलना। "वे होते हैं," कहने के बजाय, "बेहतर QA और परीक्षक प्राप्त करें," या "डेवलपर्स परीक्षण पर चूसना," कहते हैं:

कीड़े स्वीकार्य नहीं हैं, और मैं उन्हें खत्म करने के लिए अपनी शक्ति के भीतर सब कुछ करूंगा।

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


2

एक मायने में, आपका बॉस सही है। ऐसे सॉफ्टवेयर को लिखना संभव है जो शून्य बगों के करीब पहुंचते हैं।

लेकिन समस्या यह है कि है लागत लेखन (लगभग) शून्य बग कार्यक्रमों करने का है निषेधात्मक उच्च । आपको ऐसा करने की आवश्यकता है:

  • अपनी आवश्यकताओं के औपचारिक विनिर्देशों का उपयोग करें। औपचारिक, Z या VDM या कुछ अन्य गणितीय ध्वनि संकेतन के उपयोग के रूप में।

  • औपचारिक रूप से यह साबित करने के लिए कि आपके कार्यक्रम विनिर्देश को लागू करता है, प्रमेय साबित करने वाली तकनीकों का उपयोग करें।

  • बग के लिए हर तरह से परीक्षण करने के लिए व्यापक इकाई, प्रतिगमन और सिस्टम टेस्ट सूट और हार्नेस का निर्माण करें। (और यह अपने आप में पर्याप्त नहीं है।)

  • है कई लोग आवश्यकताओं (औपचारिक और अनौपचारिक), सॉफ्टवेयर (और सबूत) की समीक्षा करें। परीक्षण और तैनाती।

यह बहुत कम संभावना है कि आपका बॉस इस सब के लिए भुगतान करने के लिए तैयार है ... या यह सब करने में लगने वाले समय के साथ लगाया जाए।


1

मुझे "शून्य बग" का दर्जा मिला है। मैं अपने उपयोगकर्ताओं को बताता हूं कि यह एक बिना दस्तावेज वाली सुविधा है, या वे एक नई सुविधा के लिए पूछ रहे हैं और इसलिए यह एक वृद्धि है। यदि इनमें से कोई भी स्वीकृत प्रतिक्रिया नहीं है, तो मैं केवल उन्हें बताता हूं कि उन्होंने अपनी आवश्यकताओं को नहीं समझा है। इस प्रकार, कोई बग नहीं हैं। प्रोग्रामर परिपूर्ण हैं।


1

यहां बग फ्री-प्रोग्राम बनाने के चरण दिए गए हैं:

  1. जब तक आपके पास अपनी कार्यक्षमता के लिए UNAMBIGUOUS विनिर्देशन न हों, कोडिंग शुरू न करें।
  2. सॉफ्टवेयर में दोषों को पकड़ने के लिए परीक्षण न करें या न करें।
  3. परीक्षण के दौरान खोजे गए दोषों से सभी FEEDBACK लागू करें, एक प्रक्रिया और डेवलपर्स के लिए समीक्षा और उत्पादन जो पहले स्थान पर दोष डाले। दोष मिलते ही सभी दोषपूर्ण घटकों को त्याग दें। अपने चेकलिस्ट को अपडेट करें और अपने डेवलपर्स को फिर से लिखें ताकि वे फिर से उस तरह की गलती न करें।

परीक्षण केवल यह साबित कर सकता है कि आपके पास कीड़े हैं, लेकिन आमतौर पर अन्यथा साबित करना बेकार है। प्रतिक्रिया के बारे में - अगर आपके पास सिक्का बनाने वाली मशीन है जो सिक्के बनाती है और औसतन हर 10 के सिक्के में एक दोष है। आप उस सिक्के को ले सकते हैं, उसे समतल कर सकते हैं और मशीन में फिर से डाल सकते हैं। सिक्का जो कि पुनर्नवीनीकरण खाली बना है उतना अच्छा नहीं होगा, लेकिन शायद स्वीकार्य है। हर 100 के सिक्के पर 2 बार वगैरह लगाना होगा। क्या मशीन को ठीक करना आसान होगा?

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

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


अस्पष्ट विनिर्देशों का उल्लेख करने के लिए +1। मुझे पता है कि यह एक 2 साल पुराना विषय है, लेकिन मुझे इस बात पर जोर देना होगा कि तुम्हारा केवल एक ही जवाब है कि यह मान लेना गलत है कि बग एक प्रोग्रामिंग विफलता के बराबर है।
ब्रैंडन

0

कार्यक्रम रक्षात्मक: http://en.wikipedia.org/wiki/Defensive_programming

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


0

क्या यह एक अच्छी कार्यप्रणाली की गलतफहमी का परिणाम हो सकता है , न कि केवल सामान्य अस्थि-भंगता का?

मेरा क्या मतलब है कि यह संभव है कि आपके बॉस ने "शून्य दोष पद्धति" के बारे में सुना (देखें अनुभाग संख्या 5), और यह समझने की जहमत नहीं उठाई कि इसका क्या मतलब है?
बेशक, नई सुविधाओं के विकास को स्थगित करने के लिए प्रबंधन के लिए यह असुविधाजनक है, जिन बगों में आपको डाल देना चाहिए ...
और निश्चित रूप से, इससे उनके बोनस को खतरा है, इसलिए निश्चित रूप से आपको एक नहीं मिलेगा क्योंकि "अच्छे प्रोग्रामर नहीं करते हैं" कीड़े हैं "...

बग्स बनाना ठीक है , जब तक आप उन्हें ढूंढ सकते हैं और उन्हें ठीक कर सकते हैं (कारण के साथ, निश्चित रूप से)।


0

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

आपका बॉस उन लोगों में से एक लगता है जो "बस टाइपिंग के बाद से प्रोग्रामिंग के बारे में व्हाट्सएप को समझ नहीं पाता है"


0

अगर हम मानते हैं कि बड़े सॉफ्टवेयर हाउस जानते हैं कि शीर्ष पायदान डेवलपर्स कैसे प्राप्त करें (जैसा कि शून्य बग प्रोग्रामर में ) तो हम यह घटा सकते हैं कि Microsoft का सॉफ्टवेयर बग के बिना होना चाहिए । फिर भी हम जानते हैं कि यह सच्चाई से बहुत दूर है।

अपने सॉफ्टवेयर को विकसित करते हैं और जब वे कुछ कम प्राथमिकता वाले कीड़े के स्तर तक पहुंचते हैं तो वे केवल उत्पाद को छोड़ देते हैं और बाद में हल करते हैं।

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

कीड़े उसी तरह अपरिहार्य हैं जिस तरह से मानव स्वभाव है।

कोई बग नहीं होना 100% सुरक्षित प्रणाली की तरह है। यदि कोई प्रणाली 100% सुरक्षित है, तो यह निश्चित रूप से उपयोगी नहीं है (यह संभवतः टन और कंक्रीट के टन के अंदर है और बाहर से बिल्कुल भी जुड़ा नहीं है। वायर्ड नहीं है और न ही वायरलेस है। बस के रूप में वहाँ पूरी तरह से सुरक्षित नहीं हैं। , कोई जटिल बग-कम प्रणाली नहीं है।


-1

मैं केवल हमारे मानव होने के बारे में उत्तर देखता हूं और गलत करने के लिए प्रवृत्त होता हूं, जो बहुत सही है ... लेकिन मैं आपके प्रश्न को दूसरे दृष्टिकोण से देखता हूं।

मुझे लगता है कि आप बग-मुक्त प्रोग्राम लिख सकते हैं, लेकिन आमतौर पर वे प्रोग्राम हैं जो आपने पहले ही 10 या 12 बार लिखे हैं। 13 वीं बार जब आप स्क्रैच से एक ही प्रोग्राम लिखते हैं, तो आप पहले से ही जानते हैं कि यह कैसे करना है: आप समस्या को जानते हैं, आप तकनीकों को जानते हैं, आप पुस्तकालयों को जानते हैं, भाषा ... आप इसे अपने दिमाग में देखते हैं। सभी पैटर्न सभी स्तरों पर हैं।

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

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

हालाँकि, यदि आप कुछ ऐसा करने की कोशिश करते हैं जो नया है, लेकिन वह आपके स्तर से ठीक ऊपर है, तो आपको अपना कार्यक्रम एकदम सही या लगभग सही मिल सकता है। मुझे लगता है कि यह जानना बहुत मुश्किल है कि आपके "ज्ञान सीमा" में कौन से कार्यक्रम हैं, लेकिन सिद्धांत रूप में यह सीखने का सबसे अच्छा तरीका है। मैं वास्तव में खरोंच से कार्यक्रमों को फिर से लिखता हूं। कुछ लोग करते हैं, लेकिन आपको बहुत समय और धैर्य की आवश्यकता होती है क्योंकि तीसरी बार जब आप एक गैर-तुच्छ कार्यक्रम को दोहराते हैं तो आप पहली बार की तरह उत्साहित नहीं होते हैं।

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


-1

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


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

-1

हो सकता है कि आपको मिलने वाले कीड़े की प्रकृति के बारे में अधिक सोचें। यदि कीड़े आम तौर पर मामूली ओवरसाइट होते हैं, तो बेहतर परीक्षण और कोड प्रूफ-रीडिंग पर ध्यान केंद्रित करने में मदद मिलेगी।

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

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

मुझे लगता है कि कोड के बारे में एक प्रकार का अच्छा स्वाद आता है, जिसे आप अभ्यास और समीक्षा और समान समस्याओं वाले लोगों के बारे में पढ़कर विकसित कर सकते हैं।

अंतत:, बगैर किसी कीड़े के होने की उम्मीद करना निरर्थक है, लेकिन जब तक आपके पास पहले से ही कुछ निम्न स्तर पर नहीं है, तब तक अपनी बग गिनती को कम करने की कोशिश करने में कोई बुराई नहीं है, और फिर यह आपके समय और जो भी पाता है, के बीच एक व्यापार बंद हो जाता है। बग जो आप नहीं पकड़ते हैं।


-2

अगर मेरा मतलब है: "कोड लिखते समय शून्य कीड़े" -> यह एक अच्छा लक्ष्य है लेकिन बहुत असंभव है।

लेकिन अगर आपका मतलब है: "वितरित कोड पर शून्य कीड़े" -> यह संभव है, और मैंने ऐसे वातावरण में काम किया।

आप सभी की जरूरत है: insanely उच्च कोड गुणवत्ता और 100% परीक्षण कवरेज (इकाई परीक्षण + स्वीकृति परीक्षण + एकीकरण परीक्षण) के पास।

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

सबसे पहले आपको एक बॉस की ज़रूरत है जो वास्तव में उच्च गुणवत्ता में रुचि रखता है और इसके लिए भुगतान करने को तैयार है।


-3

प्रोग्रामर का समाधान:

  • प्रोग्रामिंग बंद करो।
  • एक यांत्रिक कंप्यूटर बनाएँ।
  • इसे हर 5 साल में बदल दें ताकि मैकेनिकल पहनना चलन में न आए।

उपयोगकर्ता का समाधान:

  • कंप्यूटर का उपयोग बंद करो।
  • सब कुछ मैन्युअल रूप से करें।
  • हमेशा दूसरे व्यक्ति के परिणामों की दोबारा जांच करें।

-3

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


-4

एक और इंजीनियर के साथ जोड़ी। एक असफल परीक्षा लिखें। फेल होने वाले टेस्ट पास करने के लिए आपके पास जो भी चरित्र है वह आवश्यक है। इसे सरल बनाने के लिए अपने कोड को रिफलेक्टर करें। एक और असफल परीक्षण लिखें, और इसी तरह आगे बढ़ें।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.