चाके पुन्हा शोधणे उपयुक्त का आहे?

दुसऱ्या दिवशी मी एका JavaScript डेव्हलपरची मुलाखत घेतली जो वरिष्ठ पदासाठी अर्ज करत होता. एका सहकाऱ्याने, जो मुलाखतीला देखील उपस्थित होता, त्याने उमेदवाराला एक फंक्शन लिहिण्यास सांगितले जे HTTP विनंती करेल आणि, अयशस्वी झाल्यास, अनेक वेळा पुन्हा प्रयत्न करा.

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

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

विकसक रेडीमेड कोड स्वयं-स्पष्ट मानतात

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

आणि सामान्यतः ते कार्य करते, परंतु जेव्हा गोष्टी अवघड होतात, तेव्हा मेकॅनिक्स समजून घेणे अधिक फायदेशीर ठरते.

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

return new Promise((resolve, reject) => {
  functionWithCallback((err, result) => {
   return err ? reject(err) : resolve(result);
  });
});

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

मुळांकडे परत जा

2012 मध्ये, जेव्हा फ्रंट-एंड फ्रेमवर्कचे वर्चस्व अद्याप स्थापित झाले नव्हते, तेव्हा jQuery ने जगावर राज्य केले आणि मी पुस्तक वाचले JavaScript निन्जाचे रहस्य, जॉन रेसिग यांनी लिहिलेले, jQuery चे निर्माता.

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

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

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

तुम्‍हाला मिळणारी प्रेरणा आणि तुम्‍हाला दिसणारे नमुने तुम्‍हाला विकसक म्‍हणून बदलतील. तुम्हाला असे आढळून येईल की तुम्ही सतत वापरत असलेली ती अद्भुत लायब्ररी आणि ज्याचा तुम्हाला जादुई कलाकृती म्हणून विचार करण्याची सवय आहे ती जादूवर अजिबात काम करत नाही, तर ती केवळ संक्षेपाने आणि संसाधनाने समस्या सोडवते.

काहीवेळा आपल्याला कोडवर छिद्र पाडावे लागेल, त्याचे चरण-दर-चरण विश्लेषण करावे लागेल, परंतु अशा प्रकारे, लहान, सातत्यपूर्ण चरणांमध्ये हलवून, आपण लेखकाच्या निराकरणाच्या मार्गाची पुनरावृत्ती करू शकता. हे तुम्हाला कोडींग प्रक्रियेत खोलवर जाण्यास अनुमती देईल आणि तुम्हाला तुमच्या स्वतःच्या उपायांसह येण्याचा अधिक आत्मविश्वास देईल.

जेव्हा मी पहिल्यांदा आश्वासने देऊन काम करायला सुरुवात केली तेव्हा मला ते शुद्ध जादूसारखे वाटले. मग मला कळले की ते त्याच कॉलबॅकवर आधारित आहेत आणि माझे प्रोग्रामिंग जग उलटे झाले. तर पॅटर्न, ज्याचा उद्देश कॉलबॅकपासून वाचवणे हा आहे, तो स्वतःच कॉलबॅक वापरून अंमलात आणला जातो?!

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

हे चाक पुन्हा शोधून काढा

म्हणून पुढे जा आणि चाके पुन्हा शोधून काढा: तुमचा स्वतःचा डेटा बाइंडिंग कोड लिहा, घरगुती वचन तयार करा किंवा तुमचा स्वतःचा राज्य व्यवस्थापन उपाय तयार करा.
हे सर्व कोणीही कधीही वापरणार नाही हे महत्त्वाचे नाही - परंतु आता तुम्हाला हे कसे करायचे ते माहित आहे. आणि जर तुम्हाला नंतर तुमच्या स्वतःच्या प्रकल्पांमध्ये अशा विकासाचा वापर करण्याची संधी असेल तर ते सामान्यतः छान आहे. तुम्ही त्यांचा विकास करू शकाल आणि आणखी काही शिकू शकाल.

इथे मुद्दा तुमचा कोड प्रोडक्शनला पाठवण्याचा नसून काहीतरी नवीन शिकण्याचा आहे. विद्यमान सोल्यूशनची तुमची स्वतःची अंमलबजावणी लिहिणे हा सर्वोत्तम प्रोग्रामरकडून शिकण्याचा आणि अशा प्रकारे तुमची कौशल्ये सुधारण्याचा एक उत्तम मार्ग आहे.

स्त्रोत: www.habr.com