कोडिंग करते समय कीड़े की संख्या कैसे कम करें?


30

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


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

जवाबों:


58

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

उपलब्ध पुस्तकालयों का उपयोग करें। उपयोगिता रूटीन लिखने में बग नहीं करने का सबसे आसान तरीका यह है कि इसे न लिखें।

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

मौजूदा कोड के लिए, जानें कि कैसे रिफ्लेक्टर करना है: कोड में छोटे बदलाव कैसे करें, अक्सर एक स्वचालित उपकरण का उपयोग करना, जो कोड को व्यवहार को बदलने के बिना अधिक पठनीय बनाते हैं।

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

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

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


x2 - रयान ने क्या कहा।
जेबीआरविलकिन्सन

2
अधिकांश भाषाएं कम या ज्यादा पिकी हो सकती हैं। आप चाहते हैं कि यह जितना संभव हो सके उतना picky हो।

1
"अधिक जटिल सामान के लिए कुछ औपचारिक तकनीक सीखें।" ... उदाहरण के लिए?
दान रोसेनस्टार्क

1
@ यार: मुझे उम्मीद है कि इस पुस्तक में बताई गई प्रणालियों की तरह: amazon.com/Verification-Sequential-Concurrent-Programs-Computer/… ; हालाँकि मुझे यह कहना होगा कि विशिष्ट पुस्तक अत्यधिक शुष्क और नीरस है, इसलिए वहाँ शायद बहुत बेहतर हैं (लेकिन यह केवल एक ही है जिसे मैंने पढ़ा है)।
जोएरी सेब्रेट्स ने

30

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


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

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

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

9

दोनों यूनिट परीक्षण टिप्पणियों पर +1।

उस से परे, अपने कंपाइलर ऑफ़र को उच्चतम चेतावनी स्तर सेट करें, और सुनिश्चित करें कि चेतावनी को त्रुटियों के रूप में माना जाता है। कीड़े अक्सर उन "गलत" त्रुटियों में छिपते हैं।

इसी तरह, स्थिर विश्लेषण उपकरणों में निवेश करें जो संकलन समय पर चलते हैं (मैं इन्हें एक अतिरिक्त स्तर के संकलक चेतावनी के रूप में देखता हूं)।


स्थैतिक विश्लेषण टिप्पणी के लिए +1। मुफ्त में वह सभी जानकारी प्राप्त करना अमूल्य है :)
मोर्टन जेन्सेन

9

इसके अतिरिक्त जो उल्लेख किया गया है:

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

अन्य चीजों के बहुत सारे मैं इस समय भूल रहा हूँ, लेकिन अन्य निश्चित रूप से उनके बारे में सोचेंगे। :)


7
और यदि आप सुनिश्चित हैं कि स्थिति X कभी नहीं होगी ... यह सुनिश्चित करने के लिए एक जोर का उपयोग करें कि जब स्थिति X होती है, तो आपको इसके बारे में पता चलेगा (अपवाद के माध्यम से, या लॉगिंग, या जो भी हो)।
फ्रैंक शीयर सेप

@MetalMikester: यूनिट परीक्षण अच्छे हैं। लेकिन उच्च स्तरीय भाषाओं और अच्छी पुस्तकालयों के साथ, अधिकांश कठिन कीड़े को नाखून के एकीकरण और प्रतिगमन परीक्षण की आवश्यकता होती है।
वेक्टर

9

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

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

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

गो फिगर, इन सभी चीजों का प्रदर्शन पर भी सकारात्मक प्रभाव पड़ता है। जीत!


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

उस मामले के थकाऊ होने का एक और विचार यह है कि शायद आप बहुत अधिक राज्य के आसपास से गुजरने की कोशिश कर रहे हैं। :)
डैश-टॉम-बैंग

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

8
  • कम कोड लिखें जो अधिक करता है।
  • निम्न-स्तरीय निहितार्थ और उच्च-स्तरीय प्रभाव के बारे में सोचें
  • अपने कोड में आपके द्वारा बनाई जा रही अमूर्तता को समाप्‍त करें।
  • यदि संभव हो तो केवल आवश्यक जटिलता लिखें।

मैं एक बड़ी पोस्ट लिखने जा रहा था जो कि "कम लिखो जो अधिक करता है" के रूप में गाया जाता है (IOW जानता है और आपके लिए उपलब्ध टूल का उपयोग करता है)। मैं इसके बजाय सिर्फ +1 करूंगा।
काज ड्रैगन

1
लेकिन कम कोड प्राप्त करने की कोशिश करते समय फैंसी कोड प्राप्त न करें।
गैबलिन

1
@ गैब्लिन: फैंसी कई तरह से देखने वाले की नज़र में है। मैं आज कोड लिख सकता हूं और पढ़ सकता हूं कि मुझे 4 साल पहले बेवकूफ बना दिया गया था। हास्केल आज मेरे लिए फैंसी है। :)
पॉल नाथन

8

थोड़ा कम तकनीकी जवाब: जब आप थके हुए हैं (9h / दिन पर्याप्त हैं), नशे में या 'बेक्ड' प्रोग्राम न करें। जब मैं थक जाता हूँ तो मुझे साफ कोड लिखने के लिए आवश्यक धैर्य नहीं होता है।


2
इसे महसूस करने के लिए आमतौर पर अधिकांश प्रोग्रामर को कई साल लगते हैं। यह एक महत्वपूर्ण बिंदु है।
जेफ डेविस

7

इकाई परीक्षण और एकीकरण परीक्षण लिखें ।


5

यूनिट टेस्टिंग और टूल्स के बारे में कुछ बेहतरीन जवाब। केवल एक चीज जो मैं उनसे जोड़ सकता हूं वह यह है:

अपने परीक्षकों को जितनी जल्दी हो सके सम्मिलित करें

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

  • पता करें कि उनकी परीक्षण योजना क्या है। उनके साथ उनके परीक्षण के मामलों की समीक्षा करें - क्या आप उन सभी को अपने कोड के साथ कवर कर रहे हैं?
  • आवश्यकताओं की उनकी समझ के लिए उनसे पूछें। क्या यह आपके जैसा ही है?
  • उन्हें जल्दी काम करने के लिए खोजपूर्ण परीक्षण करने के लिए बनाता है - आप उन सुधारों पर आश्चर्यचकित होंगे जो वे सुझाएंगे।

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


4

स्थैतिक विश्लेषण उपकरण

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

पुनश्च: हमेशा याद रखें कि कोई उपकरण आपको यह क्यों बताता है कि कोई चीज खराब है। सीखने के लिए कभी दर्द नहीं होता (और सभी स्थितियों में सब कुछ सही नहीं है)।


3

कोड निरीक्षण या सहकर्मी समीक्षा के अन्य रूप जैसे कि जोड़ी प्रोग्रामिंग।

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

सॉफ्टवेयर में कार्ल विएर्स द्वारा सहकर्मी समीक्षा इस विषय पर एक महान पुस्तक है।


2

यहां अन्य सभी सुझावों के अलावा , संवेदनशीलता के उच्चतम स्तर तक सभी संभव चेतावनियों को चालू करें और उन्हें त्रुटियों के रूप में मानें। इसके अलावा भाषा के किसी भी उपकरण का उपयोग करें।

आप इस बात से चकित होंगे कि चेतावनियों से कितनी सरल गलतियों को पकड़ा जा सकता है और उन सरल चीजों में से कितनी सरलता से आपके कोड में वास्तविक बग में तब्दील हो जाती हैं।


2

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

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

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


1

मुझे लगता है कि सबसे महत्वपूर्ण तकनीक आपका समय लेती है । यदि आपको लगता है कि आपको एक नया मॉड्यूल कोड करने के लिए दो दिनों की आवश्यकता है, लेकिन आप बॉस को केवल एक दिन में कोड करने के लिए बाध्य करते हैं ... आपका कोड संभावित रूप से अधिक छोटी गाड़ी होगी।

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


1

मैं कोड-टेस्ट-कोड-टेस्ट के बजाय टेस्ट-कोड-टेस्ट के अभ्यास का पालन करता हूं। यह मुझे उपयोग-मामलों के बारे में सोचने और तर्क को उचित रूप से फ्रेम करने में मदद करता है


1

उपयोग कोड निरीक्षण उपकरण की तरह ReSharper या की तरह IDEs IntelliJ विचार है कि के बारे में कई प्रतिलिपि और पेस्ट जैसे चर कि उनका कहना है द्वारा कीड़े और दूसरों "के लिए लिखा जाता है, लेकिन कभी नहीं पढ़ा" चेतावनी दी है। मुझे बहुत समय बचाया है।


1

हैरानी की बात है, निम्नलिखित तीन बहुत महत्वपूर्ण बिंदुओं का उल्लेख अभी तक नहीं किया गया है:

  • उदारतापूर्वक मुखरता का उपयोग करें। सवाल जो आपको हमेशा अपने आप से पूछना चाहिए वह यह है कि "क्या मुझे इस पर जोर नहीं देना चाहिए?" लेकिन "कुछ ऐसा है जिसे मैं कहना भूल गया?"

  • अपरिवर्तनशीलता का विकल्प। (अंतिम रूप से / आसानी से उदारतापूर्वक उपयोग करें।) आपके पास जितनी कम परस्पर स्थिति होगी, उतनी कम चीजें गलत हो सकती हैं।

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

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