डिफेंडर प्रोग्रामर एन्ट्रापी से अधिक मजबूत होता है

© ड्रैगन बॉल। गोकू।

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

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

आइए अधिक विस्तार से समझें कि "शान से गिरना" की अवधारणा में क्या शामिल है।

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

लेकिन आपका एक सवाल हो सकता है।

भविष्य में आने वाली समस्याओं पर समय क्यों बर्बाद करें? अब वे वहां नहीं हैं, कोड एकदम सही काम करता है। इसके अतिरिक्त, समस्याएं कभी भी नहीं हो सकती हैं। आखिरकार, इंजीनियरिंग के लिए पेशेवर इंजीनियरिंग नहीं करते हैं ( YAGNI - आपको इसकी आवश्यकता नहीं है)!

मुख्य बात व्यावहारिकता है

"प्रोग्रामर-प्रैग्मटिस्ट" पुस्तक में एंड्रयू हंट रक्षात्मक प्रोग्रामिंग की निम्न परिभाषा देता है - " व्यावहारिक व्यामोह ।"

अपने कोड को इससे सुरक्षित रखें:

• खुद की गलतियाँ;
• अन्य लोगों की गलतियाँ;
• अन्य सिस्टम में त्रुटियाँ और विफलताएँ जिनके साथ आपका एकीकरण है;
• लोहे, पर्यावरण और प्लेटफार्मों की त्रुटियां, जिस पर आपका एप्लिकेशन काम करता है।

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

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

किसी पर भरोसा न करें

उपयोगकर्ता डेटा डिफ़ॉल्ट रूप से अविश्वसनीय है। उपयोगकर्ता अक्सर गलत समझते हैं कि हमें क्या स्पष्ट लगता है (सिस्टम डेवलपर्स के रूप में)। गलत इनपुट की अपेक्षा करें और इसे हमेशा जांचें।

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

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

डेटाबेस, फाइलें, कॉन्फ़िगरेशन के केंद्रीकृत भंडारण, रजिस्ट्री - इन सभी स्थानों को अन्य लोगों द्वारा एक्सेस किया जा सकता है, और जल्द ही या बाद में वे वहां ( मर्फी का नियम ) कुछ बदल देंगे।

कचरा इनलेट → कचरा इनलेट

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

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

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

पर्यावरण के आसपास अलग-अलग विन्यास

समस्याओं का एक सामान्य कारण वातावरण या इस तरह के अलगाव की अनुपस्थिति के बीच कॉन्फ़िगरेशन का अपर्याप्त अलगाव है।

यह कई समस्याओं का कारण बन सकता है, उदाहरण के लिए:

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

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

पर्यावरण द्वारा विन्यास डेटा के जिम्मेदार पृथक्करण से संबंधित समस्याओं की एक पूरी श्रेणी को तुरंत कम कर सकते हैं:

• सुरक्षा;
• विश्वसनीयता;
• समर्थन और तैनाती (DevOps इंजीनियर आपको धन्यवाद देंगे)।

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

कैस्केडिंग प्रभाव याद रखें

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

कुछ सुरक्षात्मक तरकीबें:

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

समस्याओं की रिपोर्ट शीघ्रता से दें

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

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

अन्य सभी तकनीकी समस्याओं और विचलन को मानक तरीकों से नियंत्रित किया जाना चाहिए - निगरानी, ​​चेतावनी, लॉगिंग।

कैश का अक्सर उपयोग और / या हाल ही में डेटा

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

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

महंगे ऑपरेशन को सस्ते के साथ बदलें

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

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

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

इसी समय, अनुकूलन को स्वस्थ व्यावहारिकता के साथ व्यवहार किया जाना चाहिए:

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

समयपूर्व अनुकूलन सभी बुराई (डोनाल्ड नथ) की जड़ है

निचले स्तर की भाषा में फिर से लिखना

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

अकेले क्षेत्र में एक योद्धा नहीं है

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

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