एक सही ढंग से काम करने वाला कार्यक्रम

1. प्रोग्रामर का काम

बहुत बार नौसिखिए प्रोग्रामर एक प्रोग्रामर के काम के बारे में पूरी तरह से अलग तरह से सोचते हैं कि अनुभवी प्रोग्रामर इसके बारे में कैसा सोचते हैं।

नौसिखिए अक्सर ऐसा कुछ कहते हैं "कार्यक्रम काम करता है, आपको और क्या चाहिए?" एक अनुभवी प्रोग्रामर जानता है कि "सही ढंग से काम करता है" एक कार्यक्रम के लिए केवल एक आवश्यकता है , और यह सबसे महत्वपूर्ण बात भी नहीं है !

कोड पठनीयता

सबसे महत्वपूर्ण बात यह है कि प्रोग्राम कोड अन्य प्रोग्रामरों के लिए समझ में आता है । यह सही ढंग से कार्य करने वाले कार्यक्रम से कहीं अधिक महत्वपूर्ण है। बहुत अधिक।

यदि आपके पास कोई प्रोग्राम है जो ठीक से काम नहीं करता है, तो आप उसे ठीक कर सकते हैं। लेकिन अगर आपके पास कोई प्रोग्राम है जिसका कोड समझ से बाहर है, तो आप उसके साथ कुछ नहीं कर सकते।

बस कोई भी संकलित प्रोग्राम लें, जैसे नोटपैड, और उसकी पृष्ठभूमि का रंग बदलकर लाल कर दें। आपके पास एक कार्यशील कार्यक्रम है, लेकिन आपके पास समझने योग्य स्रोत कोड नहीं है: इस तरह के कार्यक्रम में परिवर्तन करना असंभव है।

एक पाठ्यपुस्तक का उदाहरण है जब Microsoft डेवलपर्स ने विंडोज से पिनबॉल गेम को हटा दिया क्योंकि वे इसे 64-बिट आर्किटेक्चर में पोर्ट नहीं कर सके। और उनके पास इसका सोर्स कोड भी था। वे बस यह नहीं समझ पाए कि कोड कैसे काम करता है ।

प्रत्येक उपयोग के मामले के लिए लेखांकन

किसी कार्यक्रम के लिए दूसरी सबसे महत्वपूर्ण आवश्यकता हर परिदृश्य का लेखा-जोखा रखना है। कई बार चीजें जितनी दिखती हैं, उससे कहीं ज्यादा जटिल होती हैं।

कैसे एक नौसिखिए प्रोग्रामर एसएमएस संदेश भेजना देखता है:

एक पेशेवर प्रोग्रामर इसे कैसे देखता है:

"सही ढंग से काम करता है" परिदृश्य आमतौर पर केवल एक संभव है। और यही कारण है कि कई नए लोग CodeGym के टास्क वैलिडेटर के बारे में शिकायत करते हैं: 10 में से केवल एक परिदृश्य काम करता है, और नौसिखिया प्रोग्रामर को लगता है कि यह पर्याप्त है।

2. असामान्य स्थिति

किसी कार्यक्रम के क्रियान्वयन में असामान्य स्थिति उत्पन्न हो सकती है।

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

प्रत्येक असामान्य स्थिति के लिए, प्रोग्रामर (कार्यक्रम के लेखक) को a) इसका अनुमान लगाना चाहिए , b) यह तय करना चाहिए कि प्रोग्राम को वास्तव में इसे कैसे संभालना चाहिए , और c) एक समाधान लिखें जो वांछित के जितना करीब हो सके।

यही कारण है कि काफी लंबे समय तक कार्यक्रमों का बहुत ही सरल व्यवहार था: यदि कार्यक्रम में कोई त्रुटि हुई, तो कार्यक्रम समाप्त हो गया। और यह काफी अच्छा तरीका था।

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

• कार्यक्रम समाप्त होता है
• प्रोग्राम चलता रहता है, लेकिन फ़ाइल सहेजता नहीं है।

नौसिखिए प्रोग्रामर सोच सकते हैं कि दूसरा विकल्प बेहतर है, क्योंकि प्रोग्राम अभी भी चल रहा है। लेकिन हकीकत में ऐसा नहीं है।

कल्पना कीजिए कि आपने 3 घंटे के लिए वर्ड में एक दस्तावेज़ टाइप किया, लेकिन आपकी लेखन प्रक्रिया में दो मिनट में यह स्पष्ट हो गया कि प्रोग्राम दस्तावेज़ को डिस्क में सहेजने में सक्षम नहीं होगा। काम के दो मिनट गंवाना बेहतर है या तीन घंटे?

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

3. अपवादों के बारे में पृष्ठभूमि

केवल कार्यक्रम ही असामान्य स्थितियों का सामना नहीं करते हैं। वे प्रोग्राम के अंदर भी होते हैं - विधियों में। उदाहरण के लिए:

• एक विधि फ़ाइल को डिस्क पर लिखना चाहती है, लेकिन कोई स्थान नहीं है।
• एक विधि एक फ़ंक्शन को एक चर पर कॉल करना चाहती है, लेकिन चर शून्य के बराबर है।
• 0 से भाग देना एक विधि से होता है।

इस मामले में, कॉलिंग विधि संभवतः स्थिति को ठीक कर सकती है (वैकल्पिक परिदृश्य निष्पादित करें) यदि यह जानता है कि कॉल की गई विधि में किस प्रकार की समस्या हुई है।

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

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

त्रुटियों के इस दृष्टिकोण के साथ, लगभग हर फ़ंक्शन कॉल के बाद, प्रोग्रामर को यह देखने के लिए एक चेक जोड़ना पड़ा कि क्या फ़ंक्शन त्रुटि के साथ समाप्त हुआ। कोड गुब्बारे के आकार में और इस तरह दिखने लगा:

File file = new File("ca:\\note.txt");
file.writeLine("Text");
file.close();

File file = new File("ca:\\note.txt");
int status = file.writeLine("Text");
if (status == 1)
{
   ...
}
else if (status == 2)
{
   ...
}
status = file.close();
if (status == 3)
{
   ...
}

क्या अधिक है, अक्सर एक फ़ंक्शन जो पता चलता है कि एक त्रुटि हुई है, यह नहीं जानता कि इसके साथ क्या करना है: कॉलर को त्रुटि वापस करनी थी, और कॉलर के कॉलर ने इसे अपने कॉलर को वापस कर दिया, और इसी तरह।

एक बड़े कार्यक्रम में, दर्जनों फ़ंक्शन कॉलों की एक श्रृंखला आदर्श है: कभी-कभी आप सैकड़ों कार्यों की कॉल गहराई भी पा सकते हैं। और अब आपको एरर कोड को बहुत नीचे से बहुत ऊपर तक पास करना होगा। और अगर रास्ते में कहीं कोई फंक्शन एग्जिट कोड को हैंडल नहीं करता है, तो एरर खो जाएगा।

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