एकल प्रोग्रामर का संगठन कार्य

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


अकेले काम करने वाले का क्या? एक स्पष्ट और कुशल वर्कफ़्लो बनाने के लिए क्या प्रयास करना है? किन सिद्धांतों और नियमों का पालन करना है? हम इन सवालों के जवाब एक साथ तलाशने का सुझाव देते हैं।

अकेले प्रोग्रामर के बारे में

यहाँ, "अकेला प्रोग्रामर," के बारे में बात करते हुए, मेरा मतलब उन सभी से है जो अनौपचारिक, असंरचित वातावरण में काम करते हैं। यह या तो एक एकल प्रोग्रामर हो सकता है या लोगों का एक छोटा समूह हो सकता है, कहते हैं, अपने खाली समय में, किसी तरह की परियोजना के साथ। यहाँ कुछ उदाहरण हैं:

• एक ओपन सोर्स प्रोजेक्ट का विकास, जैसे पैकेज या किसी तरह की लाइब्रेरी।
• किसी की व्यक्तिगत परियोजना, जो या तो व्यावसायिक या मुक्त हो सकती है।
• फ्रीलांस।

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

एकल प्रोग्रामर को नियमों की परवाह क्यों करनी चाहिए?

कुछ परियोजनाओं पर प्रोग्रामर के स्वतंत्र काम के लिए उन्हें लागू करने में नियम, कई कारणों से महत्वपूर्ण हैं। उन पर विचार करें।

Possible व्यक्तिगत नियम और संभव टीम वर्क

एक प्रोग्रामर जिसका स्वतंत्र काम अच्छी तरह से व्यवस्थित है, वह एक निश्चित टीम में शामिल हो सकता है। इस मामले में, संभावना अच्छी है कि वह ऐसी टीम का एक मूल्यवान सदस्य बन जाएगा। अर्थात्, हम निम्नलिखित के बारे में बात कर रहे हैं:

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

नतीजतन, एक अकेला प्रोग्रामर जो तर्कसंगत रूप से अपने काम को व्यवस्थित करता है, किसी भी मामले में विजेता है।

Program एक प्रोग्रामर के नियम और पेशेवर स्तर

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

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

सॉफ्टवेयर विकास के लिए सर्वोत्तम प्रथाओं के बारे में बात करें।

अपने वर्कफ़्लो का वर्णन करने वाले नियमों का पालन करें।

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

• जब किसी उत्पाद में बदलाव करने का निर्णय लिया जाता है - तो इसके क्रियान्वयन का क्रम क्या है?
• उपयोगकर्ताओं को उत्पाद के नए संस्करणों का स्थानांतरण कैसे किया जाता है?
• उत्पाद परिवर्तन कैसे ट्रैक किए जाते हैं?
• उपयोगकर्ताओं द्वारा आयोजित त्रुटि संदेशों और समस्याओं की निगरानी कैसे की जाती है?
• नए उत्पाद सुविधाओं की योजना बनाने की प्रक्रिया क्या है?

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

अब बात करते हैं कि सॉफ्टवेयर उत्पाद पर काम करने की प्रक्रिया को कैसे व्यवस्थित किया जाए।

SeUse कार्य ट्रैकर्स

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


कार्य

पुल अनुरोधों का उपयोग करें

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


अनुरोध का विवरण खींचें

Custom कस्टम कोड की समीक्षा करें

देशी कोड की समीक्षा के लिए सिफारिश अजीब लग सकती है, लेकिन इसके बावजूद, डेवलपर्स को अपने कोड का विश्लेषण करना चाहिए जैसे कि किसी और ने लिखा था। कुछ प्रोग्रामर एक पुल अनुरोध बनाने की सलाह देते हैं, कुछ समय के लिए ध्यान भंग करते हैं, और फिर कोड में इसे शामिल करने से पहले इसकी जांच करते हैं। अपने IDE के रूप में प्रोग्रामर के लिए सामान्य वातावरण के बाहर किए गए कोड चेक निष्पादित करना आपको कोड पर एक नया रूप लेने की अनुमति देता है। यह त्रुटियों को खोजने और कोड में कुछ का पता लगाने में मदद करता है जिसे सामान्य परिस्थितियों में अनदेखा किया जा सकता है। कोड समीक्षाएं, इसके अलावा, डेवलपर को अपने आप से विभिन्न प्रश्न पूछने के लिए मजबूर करती हैं: “इस अवसर को इस तरह से क्यों लागू किया गया था? यहां क्या गलत हो सकता है? क्या इस समस्या को हल करने के लिए एक अधिक कुशल तरीका है? ”

▍ भंडार में परियोजना का एक सार्थक इतिहास रखें

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

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

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

पुन: प्रयोज्य अवयव और मॉड्यूल बनाएँ

DRY , SOLID और FIRST के सिद्धांतों को लागू करें। पुन: उपयोग के लिए उपयुक्त छोटे, समझाया, परमाणु घटकों से कार्यक्रम बनाएं। इन घटकों को अद्यतित रखें, बिट जैसे उपयुक्त प्लेटफार्मों का उपयोग करके उन्हें संग्रह में इकट्ठा करें। यह सब आपको काम की गति और गुणवत्ता बढ़ाने में मदद करेगा।

दस्तावेज लिखें

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

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

निम्नलिखित विचार आपको अच्छे दस्तावेज लिखने में मदद करेंगे।

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

ग्राहकों और उन लोगों के साथ संवाद करें जो आपके साथ मिलकर उत्पाद विकास में शामिल हैं

यहां, जिसे हम "संचार" कहते हैं, मुख्य रूप से उन स्थितियों पर लागू होता है जब किसी परियोजना को एक छोटी टीम द्वारा विकसित किया जाता है या ऑर्डर करने के लिए बनाया जाता है।

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

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

यहां ग्राहकों के साथ और प्रोग्रामर टीम के सदस्यों के साथ संवाद करने के लिए कुछ दिशानिर्देश दिए गए हैं।

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

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

एक निगरानी प्रणाली व्यवस्थित करें

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

कार्यक्रम कैसे व्यवहार करते हैं, इसकी निगरानी के लिए यहां कुछ सुझाव दिए गए हैं:

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

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

परियोजना का निरीक्षण करें, टिप्पणियों के परिणामों से निष्कर्ष निकालें, और इसे सुधारें

आप देखते हैं, लेकिन निरीक्षण नहीं करते हैं, और यह एक बड़ा अंतर है।
आर्थर कॉनन डॉयल, "बोहेमिया में घोटाला"

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

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

. , . — , « — — ».

. , , . , UTC-. , .

, UTC. , , , 5:30 pm, 5:30 pm UTC. , . , . ? , . .

, , , — , . , , , . «5 » «2 ». , , , .

. , . , , , , , . , , .

परिणाम

, , — , . ( ), , , . , , ( , ), , . , , . , , , , .

प्रिय पाठकों! , «-»?