पहियों को सुदृढ़ करने के लिए यह उपयोगी क्यों है

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

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

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

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

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

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

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

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

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

जड़ों तक पहुँचें

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

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

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

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

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

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

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

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

इस पहिये को फिर से चालू करें

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

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