👩‍👩‍👧 👩‍🌾 🏖️ आठ महत्वपूर्ण प्रोग्रामर आदतें ✋🏽 🌟 👩🏾‍⚕️

“एक व्यक्ति केवल शिक्षा के माध्यम से एक व्यक्ति बन सकता है। वह वही है जो शिक्षा उसे बनाती है। ”
आई। कांत

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

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

तो, चलिए एक प्रोग्रामर की आठ उपयोगी आदतों से गुजरते हैं जो आपको सर्वश्रेष्ठ पेशेवर बनाएंगे।

1. दोहराएं नहीं (DRY - खुद को दोहराएं नहीं)

आप शायद इस तथ्य के पार आ गए कि, कोड के अगले भाग को देखते हुए, आप सोचते हैं: "हम्म, यहाँ मैंने पहले से ही कुछ ऐसा ही किया था, लेकिन विभिन्न तर्कों के साथ, और सामान्य तौर पर एक अलग डेटा सरणी थी।"

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

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

धीरे-धीरे, इस तरह के खाली का पूरा पुस्तकालय आप में जमा हो जाएगा, और आप आसानी से किसी भी परियोजना में उनका उपयोग कर सकते हैं।

समग्र रूप से प्रोग्रामिंग में ऐसे छोटे प्रयास होते हैं जो प्रक्रिया में किए जाते हैं। वर्तमान में जो आवश्यक है, उससे थोड़ा अधिक अपने आप को निचोड़ें। तब तुम बढ़ने लगोगे।

समान सिद्धांतों की एक पूरी सूची है जो पालन करने के लिए बहुत उपयोगी है। लेकिन, मेरी राय में, प्रोग्रामर के काम में DRY बाकी सब चीजों के लिए मौलिक है।

2. एक बार जब आप तय कर लेते हैं कि सब कुछ हो चुका है, रिफ्लेक्टर

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

क्या कोड सही तरीके से काम करता है? हाँ! तो सौदा क्या है?

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

सिर्फ एक काम नहीं, एक सुंदर निर्णय लें। ड्राफ्ट लिखने के बाद अच्छे लेखकों की तरह: वे कई बार अपने काम को पढ़ते हैं और अनावश्यक खंडों को फेंक देते हैं ताकि पाठक को अनावश्यक विवरणों के बारे में बताए बिना बिंदु को पसंद और समझ सकें।

मैं इस विषय पर रॉबर्ट मार्टिन को पढ़ने की अत्यधिक सलाह देता हूं । एक ज्ञानवर्धक पुस्तक जो प्रत्येक प्रोग्रामर के पुस्तकालय में होनी चाहिए।

3. व्यावसायिक कार्यों पर ध्यान दें

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

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

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

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

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

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

बेहतर समझ के लिए, मैं आपको साइमन सिनक की पुस्तक "स्टार्ट विथ व्हाई" पढ़ने की सलाह देता हूं ।

4. छोटा कमिट करता है

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

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

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

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

5. समय गिनें

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

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

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

समय ट्रैकिंग में अगला चरण आवश्यक था जब मैंने प्रोग्राम कोड के साथ काम का सही समय तय करने का निर्णय लिया। इसके लिए, मैंने पहली बार hubstaff.com की कोशिश की । जैसा कि यह निकला, यदि आप किसी टीम में काम करते समय इसका उपयोग करते हैं तो यह एक महंगा समाधान है।

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

6. स्थिरता में निपुणता का संकेत है।

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

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

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

तो कब्ज के सिद्धांत का पालन करने के लिए क्या करने की आवश्यकता है?

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

कक्षाओं, विधियों और चर का नाम कैसे दें, इस पर भी साहित्य का अध्ययन करें। मैं स्टीव मैककोनेल की पुस्तक "परफेक्ट कोड" की सिफारिश करता हूं।

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

7. एक बार करो

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

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

8. कभी भी सीखना बंद न करें

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

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

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

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

निष्कर्ष

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

ऐसे छोटे प्रयोगों में, आप अपने कौशल को प्रशिक्षित करेंगे और सभी महत्वपूर्ण आदतें विकसित करेंगे।

आठ महत्वपूर्ण प्रोग्रामर आदतें