अध्याय 9 — पैकेज, निर्भरता, तृतीय पक्ष

यह आर्ट ऑफ कोडिंग पर अध्याय 9 है, जो प्राचीन पुस्तक आर्ट ऑफ वॉर के अनुसार शिथिल रूप से स्वरूपित है और सॉफ्टवेयर कोड लिखने के तरीके पर अच्छे इरादों और राय को कैप्चर करने वाले लेखों की एक श्रृंखला का हिस्सा है।

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

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

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

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

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

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

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

अग्रिम पठन

लेखक के बारे में अधिक जानकारी

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

अगर आपको यह लेख अच्छा लगा हो तो कृपया ताली बजाएं और मुझे फॉलो करें।