हमें कितना रक्षात्मक होना चाहिए?


11

हम कुछ कोड पर Pex चला रहे हैं , और यह कुछ अच्छी चीजों (अच्छी बुरी चीजों को दिखा रहा है, लेकिन उत्पादन से पहले इसे दिखा रहा है!)।

हालाँकि, Pex के बारे में एक अच्छी बात यह है कि यह जरूरी नहीं कि मुद्दों को खोजने की कोशिश करना बंद कर दे।

एक क्षेत्र हमने पाया है कि एक तार में गुजरते समय, हम खाली तारों की जांच नहीं कर रहे थे।

इसलिए हमने बदल दिया:

if (inputString == null)

सेवा

if (string.IsNullOrEmpty(inputString)) // ***

उसने शुरुआती मुद्दों को तय किया। लेकिन फिर, जब हमने फिर से Pex को दौड़ाया, तो उसने तय किया कि:

inputString = "\0";

समस्या पैदा कर रहा था। और तब

inputString = "\u0001";

हमने जो फैसला किया है वह यह है कि अगर हम मुठभेड़ करते हैं // ***और किसी भी अन्य अजीब इनपुट (और इसके साथ काम कर रहे हैं) के कारण अपवाद को देखकर हम खुश हो सकते हैं।

क्या यह पर्याप्त है?


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

@ तैयार: हाँ, निश्चित रूप से हम जो कर सकते हैं और कर रहे हैं, उस प्रोफ़ाइल के लिए ट्विक हैं। Pex एक महान उपकरण है, वैसे। परिणामों ने यह दिखाया बस सवाल पूछा।
पीटर के।

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

@WayneM: हां, यह बहुत अच्छा है, हालांकि मुझे यह समझने के लिए कुछ उदाहरणों से गुजरने की जरूरत है कि यह क्या कर रहा था। विरासत कोड के लिए, यह बहुत अच्छा है। यह नए कोड के लिए और भी बेहतर है!
पीटर के।

जवाबों:


9

तीन प्रश्न आपको यह निर्धारित करने में मदद करेंगे कि आपके कोडिंग में कितना रक्षात्मक है।

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

दूसरे, कितने लोग इस फ़ंक्शन या कोड के टुकड़े का फिर से उपयोग करेंगे? सिर्फ आप? आपका विभाग? आपकी कंपनी? आपके ग्राहक? कोड का व्यापक उपयोग अधिक रक्षात्मक है।

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

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


6

उपयोगकर्ता बुराई कर रहे हैं, और जो कुछ भी वे इनपुट करते हैं उसे अत्यंत कठोरता से जांचना चाहिए।

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

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


2

मैं उतना ही रक्षात्मक होऊंगा जितना आपको होना चाहिए। थोड़ा अस्पष्ट, मुझे लगता है लेकिन मैं समझाने की कोशिश करूंगा।

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

यदि विधि एक उजागर एपीआई डिट्टो है। आप नियंत्रित नहीं कर सकते हैं कि क्या आ रहा है, इसलिए आपको सभी पहलुओं और कार्यक्रम को उसी के अनुसार प्रयास करने और कवर करने की अपेक्षा करनी चाहिए।

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

1) क्या यह एकमात्र जगह है जिसे मुझे यह जांच करने की आवश्यकता होगी? क्या इस स्थिति के लिए इस चर को बहुत से अलग-अलग स्थानों में जाँचना होगा। यदि ऐसा है तो मैं एक बार श्रृंखला को ऊपर की तरफ चेक कर सकता हूं और फिर बाद में वैधता मान सकता हूं

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

3) कोड में इस बिंदु पर विफलता के परिणाम क्या हैं। क्या यह पूरी बात को विफल कर देगा? क्या कोई त्रुटि कहीं और पकड़ी जाएगी और क्या वह त्रुटि कम से कम पकड़ी जाएगी।

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

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


1

मैंने उन बग्स पर हफ्तों पहले बिताए हैं जो 5 मिनट के अतिरिक्त काम के साथ इस तरह सामने आ सकते हैं। मेरे दिमाग में यह अप फ्रंट वर्क हमेशा इसके लायक है। आप अंततः बग को ठीक कर देंगे। एकमात्र सवाल यह है कि आपको कितना समय लगेगा।

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

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

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