पहियों का पुनः आविष्कार करना क्यों उपयोगी है?

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

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

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

डेवलपर्स तैयार कोड को स्वयं-स्पष्ट मानते हैं

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

और आमतौर पर यह काम करता है, लेकिन जब चीजें मुश्किल हो जाती हैं, तो यांत्रिकी को समझने से अधिक लाभ मिलता है।

इस प्रकार, वरिष्ठ डेवलपर पद के लिए हमारे उम्मीदवार ने वादे की वस्तुओं को स्व-स्पष्ट माना। उन्हें शायद इस बात का अंदाज़ा था कि जब वे किसी और के कोड में कहीं घटित होते हैं तो उनसे कैसे निपटना है, लेकिन वह सामान्य सिद्धांत को नहीं समझ पाए और साक्षात्कार के दौरान इसे स्वयं नहीं दोहरा सके। शायद उसे यह अंश दिल से याद था - यह उतना मुश्किल नहीं है:

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

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

जड़ों की ओर वापस जाएँ

2012 में, जब फ्रंट-एंड फ्रेमवर्क का प्रभुत्व अभी तक स्थापित नहीं हुआ था, jQuery ने दुनिया पर राज किया, और मैंने किताब पढ़ी जावास्क्रिप्ट निंजा का राज, jQuery के निर्माता जॉन रेसिग द्वारा लिखित।

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

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

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

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

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

जब मैंने पहली बार वादों के साथ काम करना शुरू किया, तो यह मुझे शुद्ध जादू जैसा लगा। तब मुझे पता चला कि वे समान कॉलबैक पर आधारित थे, और मेरी प्रोग्रामिंग दुनिया उलट-पुलट हो गई। तो पैटर्न, जिसका उद्देश्य हमें कॉलबैक से बचाना है, स्वयं कॉलबैक का उपयोग करके कार्यान्वित किया जाता है?!

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

इस पहिये का पुनः आविष्कार करें

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

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

स्रोत: www.habr.com