सोर्स कोड सोचने के तरीके के रूप में

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

एक ऐसा शब्द है जो हर साल उद्योग को भारी नुकसान पहुंचाता है। और शब्द बग है।

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

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

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

ऐसा क्यों हो रहा है? क्योंकि उद्योग में वे पूरी तरह से गलत समझते हैं कि स्रोत कोड क्या है और इसकी आवश्यकता क्यों है।

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

यदि आप प्रोग्रामर को पूर्ण नहीं बनाते हैं, तो आपको एक दिलचस्प बात मिलती है: कोड समाप्त परिणाम होना बंद हो जाता है। यह भी परिणाम होना बंद हो जाता है। और यह कार्य की स्थितियों के प्रोग्रामर द्वारा वर्तमान समझ और इसे हल करने के तरीके का प्रतिबिंब बन जाता है।

कोड दर्शाता है, वर्णन नहीं। उत्तरार्द्ध संभव है, लेकिन रिकॉर्डिंग प्रारूप से लेकर दिमाग तक पूरी प्रक्रिया के पुनर्गठन की आवश्यकता है।

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

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

और, निश्चित रूप से, यह कहना अधिक लाभदायक है, "हम संचार मॉड्यूल में बगों को ठीक करते हैं," दस्तावेज़ पढ़ने के बजाय, हमने कुछ महत्वपूर्ण बिंदुओं को याद किया और एक सप्ताह के लिए सभी चीज़ों को रीमेक करेंगे। "

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

गुणवत्ता उस समय से निर्धारित होती है जब सिस्टम में त्रुटि रहती है

जिदोका ।

दरअसल, यह इस विषय पर है। यह यूरोपीय अवधारणा द्वारा जादुई रूप से पारित की गई अवधारणा है।

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

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

और उद्योग मानक किसी भी सिस्टम विफलताओं को विशाल लॉग में छिपाने या दफनाने की प्रवृत्ति है, जहां कोई भी कभी भी स्वेच्छा से नहीं दिखता है। फिर उत्साह से कैच बग खेलते हैं।

और यहां आप एक और दिलचस्प गुणवत्ता का उल्लेख कर सकते हैं।

किसी भी इंटरफ़ेस को एक पर्याप्त स्तर पर एक त्रुटि वापस करनी चाहिए।

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

निष्पादन तर्क में त्रुटि के लिए एक पर्याप्त स्तर कार्यक्रम को रोकना है

क्योंकि यदि तर्क में विफलताएं हैं, तो उन्हें नजरअंदाज नहीं किया जा सकता है। समझने की जरूरत है।

हां, तब, जब समस्या स्पष्ट हो, तो आप इधर-उधर हो सकते हैं, आप प्रक्रिया या डेटा का हिस्सा निकाल सकते हैं। लेकिन प्रोग्रामर को यह बताने के लिए कि वह सही तरीके से नहीं सोचता है, कार्यक्रम को एक तरह से होना चाहिए - पूरी तरह से रोकें।

यह बहुत धीमा है और बहुत महंगा है। (और बहुत डरावना है।)

सिद्धांत रूप में।

व्यवहार में, यह महत्वपूर्ण रूप से लक्ष्य के लिए मार्ग को सीधा करता है और समय में गलत निर्णयों को काट देता है। (बस यहाँ चुस्त खींचें नहीं है, जो "हम प्रतिभाशाली हैं!" वाक्यांश के साथ रूसी में अनुवादित है।

उपयोगकर्ता त्रुटि के लिए पर्याप्त स्तर - वह स्थान जहां डेटा स्थित है

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

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

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

Fleas को पकड़ने की आवश्यकता नहीं है - त्रुटियों का अनुमान लगाया जा सकता है

उद्योग इकाई परीक्षण के लिए प्रार्थना करता है। यह फैशनेबल है, प्रगतिशील है, फुर्तीली है। यह सिर्फ सवाल का जवाब देने का उद्देश्य है "मैं वास्तव में एक प्रतिभाशाली हूं, ठीक है?"

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

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

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

इसलिए, मेरे लिए, किसी प्रोग्राम को डीबग करने का सबसे लगातार साधन स्ट्रिंग है

  मर "ठीक है!"  ; 

स्वाभाविक रूप से, ज्यादातर मामलों में, ऊपर की रेखा $ diag-> DBG (...) है, जो वह सब कुछ प्रदर्शित करती है जो मैं जानना चाहता था और जिसमें मुझे दिलचस्पी थी। कभी-कभी यह मानों की एक जोड़ी होती है, कभी-कभी आधा मेगाबाइट संरचना होती है, जो तब पेन या एक कार्यक्रम के साथ सावधानीपूर्वक अध्ययन की जाती है।

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

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

गलतियाँ पकड़ी जा सकती हैं जहाँ उन्हें समझना आसान है।

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

हमें पेन के साथ कुछ ऐसा करना होगा।

  
 $ डायग-> ASSERT (($ max_depth> = 1), "गहराई का पूर्णांक होना चाहिए> = 1"); 

सब कुछ सरल है। यदि पूर्व शर्त शर्त पूरी की जाती है, तो हम जारी रखते हैं। यदि आपको वह डेटा प्राप्त होता है, जिसके साथ हम काम नहीं कर सकते, तो रुकें।

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

यह भविष्य के लिए एक छोटा संदेश है। प्रोग्राम लिखने के समय से लेकर एक अनजान व्यक्ति तक एक अनजान व्यक्ति से, जिसे यह पता लगाना होगा कि शर्त काम क्यों नहीं करती।

यह अगले दिन लेखक हो सकता है, या यह अज्ञात कौशल और कार्यक्रम के अंदर क्या हो रहा है के बारे में अप्रत्याशित मान्यताओं के साथ दूर बैंगलोर में कारण का एक भाई हो सकता है। और इस मामले के लिए, यह न केवल कौवा के लिए महत्वपूर्ण है, बल्कि ज्ञान को स्थानांतरित करने के लिए भी महत्वपूर्ण है। हालाँकि, लेखक के लिए जानकारी लिखने के कुछ हफ़्ते बाद भी ताजा हो जाता है।

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

  
 $ डायग-> ASSERT (परिभाषित ($ नेटवर्क -> {$ first_vertex} -> {$ second_vertex})
                , "विलोपन की घातक त्रुटि"
                );

 $ डायग-> ASSERT (($ main_name और $ main_name! ~ / ^ NA $ / i)
                , "मुख्य नाम खाली है" 
                );

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

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

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

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

सिद्धांत रूप में, वह सब है। आप लंबे समय तक गहरे जा सकते हैं, लेकिन यह पहले से ही अन्य संस्करणों और एक अलग गुणवत्ता का पाठ है।