नवशिक्या प्रोग्रामरद्वारे केलेल्या सामान्य चुकांचे विश्लेषण, pt. १

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

1. अधिक अनुभवी सहकाऱ्यांकडून मदत घेण्याची भीती

आपण सर्व मानव आहोत. आम्हा सर्वांना मूर्ख दिसण्याची भीती वाटते, विशेषत: आमच्या नवीन, अधिक अनुभवी सहकाऱ्यांच्या नजरेत. जेव्हा विकासक त्यांची पहिली नोकरी घेतात, तेव्हा ते सहसा या भीतीने मार्गदर्शन करतात आणि, खूप ऐकून, स्वत: मध्येच माघार घेतात, स्वतःहून सर्वकाही शोधण्याचा प्रयत्न करतात. याव्यतिरिक्त, एखाद्याला अधिक अनुभवी सहकाऱ्यांनी वेढले जाऊ शकते, जे यामधून, त्याला किंवा तिला सर्वात आशादायक दिशेने निर्देशित करण्यास सक्षम आहेत, अधिक चुका आणि अनावश्यक "डोक्यावरील अडथळे" टाळण्यास मदत करतात. म्हणून लक्षात ठेवा: प्रश्न विचारण्यास घाबरू नका. तुम्ही नवशिक्या आहात आणि प्रत्येकाला हे उत्तम प्रकारे समजते. तुम्ही विचाराल तर तुम्हाला कोणी लाठ्या मारणार नाही. कदाचित अगदी उलट घडेल: तुम्ही तुमच्या सहकार्‍यांशी अधिक त्वरेने मित्र व्हाल आणि त्यांच्याशी अधिक सक्रिय संवादाचा आनंद घेण्यास सुरुवात कराल. मी' आणखी काही सांगेन: तुम्ही जेवढे जास्त विचाराल आणि विविध तांत्रिक समस्यांवर चर्चा कराल, तितक्या वेगाने तुम्ही तुमची हिरवीगार त्वचा काढून टाकू शकाल आणि तुमच्या क्षेत्रातील तज्ञ बनू शकाल. आणि आणखी एक सल्ला. साठी अनोळखी होऊ नकास्टॅकओव्हरफ्लो _ मी विशेषतः या संसाधनावर प्रश्न विचारण्याबद्दल बोलत आहे. एकीकडे, तुमच्या प्रश्नाचे उत्तर मिळण्यासाठी थोडा वेळ लागतो. परंतु दुसरीकडे, तुम्ही तुमच्या समस्येचे निराकरण करण्यासाठी अनेक पध्दती पटकन शिकू शकता आणि त्याकडे थोड्या वेगळ्या कोनातून पाहू शकता. मला हे देखील लक्षात घ्यायचे आहे की टिप्पणी/उत्तरे लिहिण्याचे आणि इतर विकासकांकडील स्टॅकओव्हरफ्लो प्रश्नांवर स्पष्टीकरण करणारे प्रश्न लिहिण्याचे व्यावहारिक फायदे आहेत: तुम्हाला वादविवाद करण्याची आणि मुद्द्यांचा सखोल अभ्यास करण्याची संधी मिळते, कर्म बूस्टचा उल्लेख न करता.

2. स्वतःहून माहिती शोधण्याचा प्रयत्न करत नाही

ही चूक मागील एकाची फ्लिपसाइड मानली जाऊ शकते.येथे मला असे म्हणायचे आहे की जेव्हा तुम्ही तुमच्या सहकाऱ्यांना आणि ओळखीच्या व्यक्तींना तुम्हाला येणाऱ्या प्रत्येक समस्येबद्दल किंवा अडचणींबद्दल त्रास देण्यास सुरुवात करता. विचारणे चांगले आहे, परंतु प्रश्नांच्या ओव्हरबोर्डमध्ये जाऊ नका. अन्यथा, लोक तुम्हाला त्रासदायक वाटतील. तुम्ही एखाद्या गोष्टीबद्दल गोंधळून गेल्यास, सर्वोत्तम शोध इंजिन - Google मध्ये तुमची शोध कौशल्ये वापरणे ही पहिली गोष्ट आहे. इतर कोणीतरी आधीच समजण्यायोग्य त्रुटी आणि इतर समस्यांचा प्रचंड बहुमताचा सामना केला आहे. आणि जर तुम्ही तुमचा प्रश्न गुगल केलात आणि अशाच समस्येशी परिचित असलेल्या लोकांची संख्या पाहिल्यास आणि ज्यांना तुम्ही तुमच्या स्वतःच्या कामात अर्ज करू शकता अशी सर्वसमावेशक उत्तरे आधीच प्राप्त केली असतील तर तुम्हाला आश्चर्य वाटेल. म्हणूनच तुम्ही तुमच्या सहकाऱ्यांना "Google it" सह उत्तर देताना अनेकदा ऐकू शकाल. करू नका या उत्तरावर नाराज होऊ नका - तुमचा सहकारी तुमचा वैयक्तिक शिक्षक नाही ज्याने तुमच्या कार्यक्षेत्रातील सर्व बारकावे सांगितल्या पाहिजेत. इंटरनेटचा अंतहीन विस्तार हा तुमचा मार्गदर्शक असेल. कधीकधी प्रोग्रामर म्हणून देखील संबोधले जातेगुगल सर्चमध्ये ब्लॅक बेल्ट असलेले लोक . त्यामुळे जर आम्हाला "हिचकी" आली असेल तर आम्ही प्रथम समस्या गुगल करतो. जर उपाय सापडला नाही (हे दुर्मिळ आहे, परंतु असे घडते), तरच आम्ही सहकाऱ्यांना विचारू लागतो. स्पीड बंप किंवा न समजण्याजोगा एरर मेसेज आल्यावर तुम्ही काय कराल यापेक्षा समस्या सोडवण्यासाठी तुम्ही कोणता दृष्टिकोन निवडावा याबद्दल सल्ला मिळवण्यासाठी त्वरित प्रश्न आहेत. शेवटी, ते तुमच्या पसंतीच्या दृष्टिकोनाच्या पलीकडे पाहण्यास सक्षम असतील आणि कोणताही दिलेला दृष्टीकोन दीर्घकाळात कुठे नेईल याचा अंदाज लावू शकतात.

3. आंधळेपणाने कॉपी आणि पेस्ट करणे

पण गुगलिंगच्या समस्या आणि त्यांचे निराकरण यात काही तोटे आहेत. उदाहरणार्थ, आंधळेपणाने कॉपी आणि पेस्ट करणे .हे सहसा घडते जेव्हा तुम्हाला समान समस्या आढळते (परंतु कदाचित तीच नाही) आणि संबंधित उपाय, उदाहरणार्थ, StackOverflow वर. तुम्ही हे सोल्यूशन मिळवा आणि तपशीलांमध्ये अधिक शोध न घेता कॉपी आणि पेस्ट करा. आणि मग तुम्ही किंवा तुमच्या सहकार्‍यांना तुमच्या कोडमध्ये काही विचित्र बग किंवा चुकीचे वर्तन सापडेल. आणि ते कोठून आले याचा कोणीही लगेच अंदाज लावू शकत नाही. अखेरीस, अर्थातच, कॉपी केलेल्या कोडसह जागा सापडेल, आणि तुमच्या समाधानासाठी तुमची नक्कीच प्रशंसा केली जाणार नाही. म्हणून, जेव्हा तुम्हाला स्टॅकओव्हरफ्लोवर (किंवा इतर कोठेही) रेडीमेड सोल्यूशन सापडेल तेव्हा तुम्ही प्रथम काय, कसे आणि का हे पूर्णपणे समजून घेतले पाहिजे. कदाचित संबंधित कार्यक्षमता गुगल करा आणि त्यासाठी कागदपत्रे वाचा. आणि तुम्ही ते पूर्ण केल्यानंतरच तुम्ही ते तुमच्या प्रोजेक्टमध्ये जोडले पाहिजे.

4. चुकीच्या सोल्यूशनसह चिकटणे

एक उपाय लिहिताना, काहीवेळा तुम्हाला असे आढळेल की ते सतत अधिकाधिक क्लिष्ट होत आहे, अखेरीस शेवटपर्यंत पोहोचते. आणि मग तुम्ही दुसरा, अधिक योग्य पर्याय शोधण्याऐवजी तो कसा तरी कार्यान्वित व्हावा यासाठी उपाय आणखी विस्तृत करण्याचा प्रयत्न करा. कदाचित तुम्हाला असे वाटेल की तुम्ही खूप वेळ आणि मेहनत गुंतवली आहे आणि म्हणून ठरवले आहे की, काहीही झाले तरी तुम्ही हार मानणार नाही आणि तुमच्या विद्यमान दृष्टिकोनाने समस्या सोडवाल. ही वृत्ती अगदी योग्य नाही. किमान प्रोग्रामिंगमध्ये. जितक्या लवकर तुम्ही वेगळा दृष्टीकोन वापरून पहाल, तितक्या लवकर तुमचा जास्त वेळ वाचेल. त्यामुळे तुम्ही तुमच्या सध्याच्या पद्धतीमध्ये कितीही वेळ गुंतवला आहे याची पर्वा न करता प्रयोग करण्यास आणि इतर पद्धती वापरण्यास घाबरू नका. इतकेच काय, अनेक पध्दती वापरून आणि या विषयात अधिक खोलवर जाऊन तुम्ही'

5. तुमच्या वर्तमान असाइनमेंटबद्दल प्रश्न विचारण्याची भीती

सॉफ्टवेअर डेव्हलपमेंट प्रकल्पावर काम करणे सहसा विशिष्ट कार्ये करण्यासाठी खाली उकळते. उदाहरणार्थ, जिरा मध्ये. ही कार्ये नेहमी स्पष्टपणे आणि तपशीलवार वर्णन केलेली नाहीत. कार्य वर्णने सहसा संघ नेत्यांनी लिहिलेली असतात, जे केवळ नश्वर देखील असतात. ते कदाचित काहीतरी जोडण्यास विसरतील किंवा आपण या किंवा त्या कार्यक्षमतेशी परिचित नसल्याचा हिशेब चुकवू शकतील. किंवा कदाचित तुमच्याकडे प्रकल्पात प्रवेश नसेल (उदाहरणार्थ, डेटाबेस, लॉग सर्व्हर आणि याप्रमाणे) प्रवेश. आणि आता, तुम्हाला कार्य प्राप्त झाले आहे, दोन तासांहून अधिक काळ त्याचा अभ्यास केला आहे, परंतु तरीही तुम्ही तिथेच बसून आहात, चकित होऊन स्क्रीनकडे पहात आहात. हे समजून घेण्याचा अयशस्वी प्रयत्न सुरू ठेवण्याऐवजी, तुम्ही हे कार्य ज्याने तयार केले आहे त्यांच्याकडून स्पष्टीकरण किंवा मार्गदर्शन मागायला सुरुवात केली पाहिजे. उदाहरणार्थ, तुमचा कार्यसंघ संवादासाठी वापरत असलेल्या अॅपमध्ये (उदाहरणार्थ, Microsoft Teams), तुम्ही प्रश्न विचारू शकता किंवा कार्याशी संबंधित थेट टिप्पणी करू शकता. एकीकडे, तुम्ही तुमचा प्रश्न वैयक्तिक संदेशात लिहिल्यास, तुम्हाला कदाचित जलद उत्तर मिळेल, कारण त्या व्यक्तीला तुमचा प्रश्न लगेच दिसेल. दुसरीकडे, जिरामध्ये प्रश्न विचारून, तुम्ही काहीतरी करत आहात याचा पुरावा तुम्ही प्रस्थापित करता, म्हणजे, समस्येचे विश्लेषण. या प्रक्रियेला गती देण्याचा एक मार्ग आहे: जिरामधील टिप्पणीमध्ये आणि नंतर DM मध्ये तुमचा प्रश्न विचारा, तुमच्या टिप्पणीची लिंक टाका आणि एक नजर टाकण्यास सांगा.

6. संघाच्या नेतृत्वावर अवास्तव उच्च अपेक्षा ठेवणे

पुन्हा, ही मागील बिंदूची फ्लिप बाजू आहे. टीम लीड हा विकास संघाचा प्रमुख असतो. नियमानुसार, तुमचा टीम लीड त्याचा किंवा तिचा बहुतेक वेळ विविध प्रकारच्या संवादावर घालवतो. तरीही, प्रोग्रामिंगबद्दल सर्व काही विसरू नये म्हणून तो किंवा ती कोड देखील लिहितात. जसे तुम्ही समजू शकता, टीम लीडचे आयुष्य खूप व्यस्त असते. प्रत्येक वेळी जेव्हा तुम्हाला शिंकण्याची आवश्यकता असेल तेव्हा तुमच्या टीम लीडच्या स्लीव्हवर टॅग करणे नक्कीच आनंददायक होणार नाही. कल्पना करा की संघातील प्रत्येक सदस्य अनेक प्रश्नांसह आघाडीवर भडिमार करत आहे. हे कोणालाही वेड लावू शकते, बरोबर? आणि जर तुम्ही बरेच प्रश्न विचारत असाल तर तुमच्या टीम लीडला तुम्हाला उत्तरे देण्यात बराच वेळ घालवावा लागेल. टीम लीडकडे निर्देशित केलेल्या प्रश्नांची संख्या कमी करण्यासाठी काय केले जाऊ शकते:

• ब्लाइंड स्पॉट्सची संख्या कमी करण्यासाठी प्रकल्प दस्तऐवजीकरण अधिक सखोलपणे एक्सप्लोर करा.
• तुमचे प्रश्न तुमच्या इतर टीम सदस्यांना पाठवा. ते कदाचित या कार्यक्षमतेशी परिचित असतील जितके लीड आहे, किंवा कदाचित त्याहूनही अधिक, कारण कार्यक्षमता बहुधा त्यापैकी एकाने लिहिलेली असेल.

वैकल्पिकरित्या, तुम्ही IDE मधील भाष्ये पाहू शकता की विशिष्ट ओळीतील कोड कोणी आणि कधी बदलला होता. तुमचा प्रश्न विचारण्यासाठी सर्वात योग्य व्यक्ती कोण आहे हे तुम्ही कसे शोधू शकता. तुम्हाला कदाचित आधीच लक्षात आले असेल की, जेव्हा टीम लीडच्या प्रश्नांचा प्रश्न येतो, ज्याप्रमाणे सहकार्‍यांच्या प्रश्नांबद्दल, तुम्हाला एक आनंदी माध्यम शोधण्याचा प्रयत्न करणे आवश्यक आहे — प्रश्न विचारण्यास घाबरू नका, परंतु खूप जास्त विचारू नका. त्यांना.

7. कोड पुनरावलोकनांची भीती

कोड पुनरावलोकनअसा एक टप्पा आहे जो तुम्ही तुमचा कोड एका सामान्य ऍप्लिकेशनवर (शेअर केलेल्या शाखेत, उदाहरणार्थ, मास्टर किंवा देव) सबमिट करण्यापूर्वी होतो. ही तपासणी एका विकासकाद्वारे केली जाते जो कार्यात गुंतलेला नाही, ज्यांचे ताजे डोळे तुमच्या कोड शैलीतील त्रुटी, अयोग्यता किंवा त्रुटी शोधू शकतात ज्या तुम्ही सुरुवातीला तुमचा कोड लिहिताना लक्ष न दिला गेला. टीका असल्यास, ते कोडच्या काही भागांवर टिप्पण्या म्हणून सोडले जातात. या प्रकरणात, कोड लिहिणाऱ्या विकसकाने पुनरावलोकनामध्ये ओळखल्या गेलेल्या त्रुटी दुरुस्त केल्या पाहिजेत (किंवा पुनरावलोकनकर्त्याशी त्याच्या निर्णयांवर चर्चा करा, शक्यतो त्याला किंवा तिला ते बरोबर असल्याचे पटवून द्या). नंतर पुनरावलोकनकर्त्याच्या अधिक टिप्पण्या होईपर्यंत कोड पुन्हा पुन्हा पुनरावलोकनासाठी सबमिट केला जातो. कोड कमिट होण्यापूर्वी पुनरावलोकनकर्ता "गेटवे" म्हणून कार्य करतो. आव्हान हे आहे की अनेक नवशिक्या प्रोग्रामर कोड पुनरावलोकनास टीका आणि निषेध म्हणून समजतात. ते कोड पुनरावलोकनांची प्रशंसा करत नाहीत आणि त्यांना घाबरतात. त्यांनी करू नये. कोड रिव्ह्यू म्हणजे नेमके तेच आम्हाला आमचा कोड सुधारू देतो. शेवटी, आम्ही काय चुकीचे करत आहोत आणि कशाकडे लक्ष देणे योग्य आहे याबद्दल आम्हाला महत्त्वाची माहिती मिळते. तुम्ही प्रत्येक कोड पुनरावलोकनाचा शिक्षण वक्रचा भाग म्हणून विचार केला पाहिजे, जे तुम्हाला अधिक चांगले होण्यास मदत करू शकते. जेव्हा कोणी तुमच्या कोडवर टिप्पणी करते, तेव्हा तो किंवा ती तुमच्यासोबत अनुभव आणि सर्वोत्तम पद्धती शेअर करत असते. कोड पुनरावलोकने न मिळाल्याशिवाय तुम्ही एक चांगला प्रोग्रामर होऊ शकता यावर माझा वैयक्तिक विश्वास नाही. कारण तुम्हाला तुमच्या कोडच्या गुणवत्तेची आणि अनुभवी बाहेरील व्यक्ती चुकांकडे लक्ष वेधेल की नाही याचीही जाणीव नसते. कोड पुनरावलोकनांचे कौतुक करू नका आणि त्यांना घाबरू नका. त्यांनी करू नये. कोड रिव्ह्यू म्हणजे नेमके तेच आम्हाला आमचा कोड सुधारू देतो. शेवटी, आम्ही काय चुकीचे करत आहोत आणि कशाकडे लक्ष देणे योग्य आहे याबद्दल आम्हाला महत्त्वाची माहिती मिळते. तुम्ही प्रत्येक कोड पुनरावलोकनाचा शिक्षण वक्रचा भाग म्हणून विचार केला पाहिजे, जे तुम्हाला अधिक चांगले होण्यास मदत करू शकते. जेव्हा कोणी तुमच्या कोडवर टिप्पणी करते, तेव्हा तो किंवा ती तुमच्यासोबत अनुभव आणि सर्वोत्तम पद्धती शेअर करत असते. कोड पुनरावलोकने न मिळाल्याशिवाय तुम्ही एक चांगला प्रोग्रामर होऊ शकता यावर माझा वैयक्तिक विश्वास नाही. कारण तुम्हाला तुमच्या कोडच्या गुणवत्तेची आणि अनुभवी बाहेरील व्यक्ती चुकांकडे लक्ष वेधेल की नाही याचीही जाणीव नसते. कोड पुनरावलोकनांचे कौतुक करू नका आणि त्यांना घाबरू नका. त्यांनी करू नये. कोड रिव्ह्यू म्हणजे नेमके तेच आम्हाला आमचा कोड सुधारू देतो. शेवटी, आम्ही काय चुकीचे करत आहोत आणि कशाकडे लक्ष देणे योग्य आहे याबद्दल आम्हाला महत्त्वाची माहिती मिळते. तुम्ही प्रत्येक कोड पुनरावलोकनाचा शिक्षण वक्रचा भाग म्हणून विचार केला पाहिजे, जे तुम्हाला अधिक चांगले होण्यास मदत करू शकते. जेव्हा कोणी तुमच्या कोडवर टिप्पणी करते, तेव्हा तो किंवा ती तुमच्यासोबत अनुभव आणि सर्वोत्तम पद्धती शेअर करत असते. कोड पुनरावलोकने न मिळाल्याशिवाय तुम्ही एक चांगला प्रोग्रामर होऊ शकता यावर माझा वैयक्तिक विश्वास नाही. कारण तुम्हाला तुमच्या कोडच्या गुणवत्तेची आणि अनुभवी बाहेरील व्यक्ती चुकांकडे लक्ष वेधेल की नाही याचीही जाणीव नसते. पुन्हा चुकीचे करत आहे आणि काय लक्ष देणे योग्य आहे. तुम्ही प्रत्येक कोड पुनरावलोकनाचा शिक्षण वक्रचा भाग म्हणून विचार केला पाहिजे, जे तुम्हाला अधिक चांगले होण्यास मदत करू शकते. जेव्हा कोणी तुमच्या कोडवर टिप्पणी करते, तेव्हा तो किंवा ती तुमच्यासोबत अनुभव आणि सर्वोत्तम पद्धती शेअर करत असते. कोड पुनरावलोकने न मिळाल्याशिवाय तुम्ही एक चांगला प्रोग्रामर होऊ शकता यावर माझा वैयक्तिक विश्वास नाही. कारण तुम्हाला तुमच्या कोडच्या गुणवत्तेची आणि अनुभवी बाहेरील व्यक्ती चुकांकडे लक्ष वेधेल की नाही याचीही जाणीव नसते. पुन्हा चुकीचे करत आहे आणि काय लक्ष देणे योग्य आहे. तुम्ही प्रत्येक कोड पुनरावलोकनाचा शिक्षण वक्रचा भाग म्हणून विचार केला पाहिजे, जे तुम्हाला अधिक चांगले होण्यास मदत करू शकते. जेव्हा कोणी तुमच्या कोडवर टिप्पणी करते, तेव्हा तो किंवा ती तुमच्यासोबत अनुभव आणि सर्वोत्तम पद्धती शेअर करत असते. कोड पुनरावलोकने न मिळाल्याशिवाय तुम्ही एक चांगला प्रोग्रामर होऊ शकता यावर माझा वैयक्तिक विश्वास नाही. कारण तुम्हाला तुमच्या कोडच्या गुणवत्तेची आणि अनुभवी बाहेरील व्यक्ती चुकांकडे लक्ष वेधेल की नाही याचीही जाणीव नसते.

8. रहस्यमय निर्णय घेण्याची प्रवृत्ती

विविध कार्ये/समस्यांमध्ये अनेकदा वेगवेगळे उपाय असू शकतात. आणि सर्व उपलब्ध सोल्यूशन्सपैकी, नवशिक्या सर्वात जटिल आणि रहस्यमय उपायांचा वापर करतात. आणि याचा अर्थ होतो: नवशिक्या प्रोग्रामरनी कालच बरेच वेगवेगळे अल्गोरिदम, नमुने आणि डेटा स्ट्रक्चर्स शिकले आहेत, त्यामुळे त्यांच्या हाताला खाज सुटली आहे. माझ्यावर विश्वास ठेवा, मी तसाच होतो, म्हणून मला माहित आहे की मी कशाबद्दल बोलत आहे :) माझी अशी परिस्थिती होती जिथे मी बर्याच काळापासून काही कार्यक्षमता अंमलात आणत होतो. हे खूप, खूप क्लिष्ट असल्याचे दिसून आले. मग वरिष्ठ विकासकाने माझा कोड पुन्हा लिहिला. अर्थात, त्याने काय आणि कसे बदलले हे पाहण्यात मला खूप रस होता. मी त्याची अंमलबजावणी पाहिली आणि ते किती सोपे आहे याबद्दल आश्चर्यचकित झाले. आणि तिप्पट कमी कोड होता. आणि आश्चर्यकारकपणे, या कार्यक्षमतेसाठी स्वयंचलित चाचण्या काढल्या किंवा बदलल्या गेल्या नाहीत! दुसऱ्या शब्दांत, सामान्य तर्क समान राहिले. यावरून मी या निष्कर्षाप्रत पोहोचलोसर्वात कल्पक उपाय नेहमी सोपे असतात . या अनुभूतीनंतर, कोडिंग खूप सोपे झाले आणि माझ्या कोडची गुणवत्ता लक्षणीयरीत्या उच्च पातळीवर गेली. मग डिझाइन पॅटर्न आणि फॅन्सी अल्गोरिदम लागू करणे केव्हा फायदेशीर आहे, तुम्ही विचारता? त्यांना लागू करताना सर्वात सोपा आणि सर्वात संक्षिप्त उपाय असेल.

9. चाक पुन्हा शोधणे

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

10. चाचण्या लिहिण्यात अयशस्वी

सर्व नवशिक्यांना लेखन चाचणी आवडत नाही. पण आपण इथे नवशिक्यांना का बाहेर काढावे? अधिक अनुभवी विकसकांना देखील चाचण्या लिहिणे आवडत नाही, परंतु चाचण्या का आवश्यक आहेत हे त्यांना चांगले समजते. जेव्हा तुम्ही पूर्णपणे हिरवे असता तेव्हा तुम्ही त्यांना का लिहावे असा प्रश्न पडतो. सर्व काही कार्य करते, त्यामुळे कोणतीही चूक होऊ शकत नाही. परंतु तुमचे बदल सिस्टीममध्ये इतरत्र कुठेही खंडित होणार नाहीत याची खात्री कशी कराल? चांगल्यापेक्षा जास्त नुकसान करणारे बदल तुम्ही पुढे ढकलल्यास तुमचे सहकारी त्याचे कौतुक करणार नाहीत. येथेच चाचण्या आमच्या बचावासाठी येतात. चाचण्यांद्वारे अनुप्रयोगाचा कोड जितका अधिक कव्हर केला जाईल तितके चांगले (याला कोड कव्हरेज किंवा चाचणी कव्हरेज म्हणतात). जर अनुप्रयोगामध्ये चांगले चाचणी कव्हरेज असेल, तर तुम्ही तुमच्या कोडद्वारे खंडित होणारी ठिकाणे शोधण्यासाठी सर्व चाचण्या करू शकता. आणि मी वरील उदाहरणात म्हटल्याप्रमाणे, जेव्हा वरिष्ठ विकासकाने कोड रीफॅक्टर केला तेव्हा चाचण्या अयशस्वी झाल्या नाहीत. कारण सर्वसाधारण तर्क बदलला नाही. विशिष्ट कार्यक्षमतेचे तर्क बदलले आहेत की नाही हे दाखवण्यासाठी आम्ही चाचण्या वापरतो. त्यामुळे तुम्हाला लिहिण्याच्या चाचण्या आवडत नसल्या तरी त्या निश्चितपणे उपयुक्त आहेत आणि त्यांवर घालवलेल्या वेळेस योग्य आहेत.

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

बरेच विकासक परिपूर्णतेने ग्रस्त आहेत आणि नवशिक्याही त्याला अपवाद नाहीत. जेव्हा ते प्रत्येकावर आणि प्रत्येक गोष्टीवर भाष्य करू लागतात तेव्हा ते कधीकधी या प्रवृत्तीचा फक्त एक पैलू प्रकट करतात. अनावश्यक टिप्पण्या करणे देखील, कारण कोड अगदी स्पष्ट आहे:

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

सर्व नवशिक्या प्रोग्रामरना लगेच लक्षात येत नाही की टिप्पणी करणारा कोड नेहमीच चांगला नसतो, कारण अनावश्यक टिप्पण्या कोडला गोंधळात टाकतात आणि वाचणे कठीण करतात. आणि जर कोड बदलला, परंतु जुन्या टिप्पण्या अद्यतनित केल्या नाहीत तर काय? मग ते फक्त आपली दिशाभूल करतील आणि गोंधळात टाकतील. मग अजिबात अशी टिप्पणी का करायची? सहसा, चांगल्या लिखित कोडवर टिप्पणी करणे आवश्यक नसते , कारण त्यातील सर्व काही आधीच स्पष्ट आणि वाचनीय असते. आपल्याला टिप्पणी लिहिण्याची आवश्यकता असल्यास, आपण कोडची वाचनीयता आधीच खराब केली आहे आणि कसा तरी परिस्थिती सुधारण्याचा प्रयत्न करीत आहात. सुरवातीपासून वाचता येण्याजोगा कोड लिहिणे हा सर्वात चांगला मार्ग आहे, म्हणजे टिप्पण्यांची आवश्यकता नसलेला कोड. मी देखील मदत करू शकत नाही परंतु पद्धती, व्हेरिएबल्स आणि वर्गांसाठी योग्य नामकरण नियमांचे पालन करण्याची आवश्यकता नमूद करू शकत नाही. हा माझा नियम आहे: सर्वोत्कृष्ट टिप्पणी म्हणजे एकतर कोणतीही टिप्पणी नाही किंवा योग्य नामकरण जे तुमच्या अनुप्रयोगातील कार्यक्षमतेचे स्पष्टपणे वर्णन करते.

12. वाईट नामकरण

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