नौसिखिए प्रोग्रामर द्वारा की गई सामान्य गलतियों का विश्लेषण, पीटी। 1

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

1. अधिक अनुभवी सहयोगियों से मदद लेने का डर

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

2. स्वयं जानकारी खोजने का प्रयास नहीं करना

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

3. आँख बंद करके कॉपी और पेस्ट करना

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

4. गलत उपाय से चिपकना

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

5. अपने वर्तमान असाइनमेंट के बारे में प्रश्न पूछने का डर

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

6. टीम लीड पर अवास्तविक रूप से उच्च अपेक्षाएं रखना

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

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

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

7. कोड समीक्षा का डर

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

8. रहस्यमय निर्णयों की प्रवृत्ति

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

9. पहिए का पुन: आविष्कार करना

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

10. परीक्षण लिखने में असफलता

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

11. अत्यधिक टिप्पणियाँ

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

Cat cat = new Cat(); // Cat object

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

12. खराब नामकरण

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