पाङ्ग्रा पुन: आविष्कार गर्न किन उपयोगी छ?

अर्को दिन मैले जाभास्क्रिप्ट विकासकर्तालाई अन्तर्वार्ता लिएँ जसले वरिष्ठ पदको लागि आवेदन दिइरहेको थियो। एक सहकर्मी, जो अन्तर्वार्तामा पनि उपस्थित थिए, उम्मेदवारलाई एउटा प्रकार्य लेख्न आग्रह गरे जसले HTTP अनुरोध गर्नेछ र, यदि असफल भएमा, धेरै पटक पुन: प्रयास गर्नुहोस्।

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

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

विकासकर्ताहरूले तयार कोडलाई आत्म-स्पष्ट मान्छन्

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

र सामान्यतया यसले काम गर्छ, तर जब चीजहरू कठिन हुन्छन्, मेकानिक्स बुझ्दा भुक्तान भन्दा बढी हुन्छ।

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

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

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

जरा मा फर्कनुहोस्

२०१२ मा, जब फ्रन्ट-एन्ड फ्रेमवर्कको प्रभुत्व स्थापित भएको थिएन, jQuery ले संसारमा शासन गर्यो, र मैले पुस्तक पढें। जाभास्क्रिप्ट निन्जा को रहस्य, जोन रेसिग द्वारा लेखक, jQuery को निर्माता।

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

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

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

तपाईंले प्राप्त गर्नुभएको प्रेरणा र तपाईंले देख्न थाल्नुभएको ढाँचाहरूले तपाईंलाई विकासकर्ताको रूपमा परिवर्तन गर्नेछ। तपाईंले त्यो अद्भुत पुस्तकालय पाउनुहुनेछ जुन तपाईंले निरन्तर प्रयोग गर्नुहुन्छ र जसलाई तपाईं जादुई कलाकृतिको रूपमा सोच्न अभ्यस्त हुनुहुन्छ, यसले जादूमा कुनै पनि काम गर्दैन, तर केवल समस्याको समाधान र संसाधनको रूपमा गर्छ।

कहिलेकाँही तपाईले कोडमा पोर गर्नुपर्नेछ, यसलाई चरण-दर-चरण विश्लेषण गर्दै, तर यो कसरी, साना, लगातार चरणहरूमा सर्दै, तपाइँ समाधानको लागि लेखकको मार्ग दोहोर्याउन सक्नुहुन्छ। यसले तपाइँलाई कोडिङ प्रक्रियामा गहिरो डुब्न अनुमति दिनेछ र तपाइँलाई तपाइँको आफ्नै समाधानहरु संग आउन थप आत्मविश्वास प्रदान गर्दछ।

जब मैले पहिलो पटक वाचाका साथ काम गर्न थालें, यो मलाई शुद्ध जादू जस्तो लाग्थ्यो। त्यसपछि मैले थाहा पाए कि तिनीहरू उही कलब्याकहरूमा आधारित थिए, र मेरो प्रोग्रामिङ संसार उल्टो भयो। त्यसोभए ढाँचा, जसको उद्देश्य हामीलाई कलब्याकहरूबाट बचाउनु हो, आफैले कलब्याकहरू प्रयोग गरेर लागू गरेको हो?!

यसले मलाई यो कुरालाई फरक आँखाले हेर्न र यो मेरो अगाडि कोडको कुनै अमूर्त टुक्रा होइन भनेर महसुस गर्न मद्दत गर्‍यो, जुन निषेधात्मक जटिलता मैले मेरो जीवनमा कहिल्यै बुझ्न सक्दिन। यी केवल ढाँचाहरू हुन् जुन कारण जिज्ञासा र गहिरो विसर्जन संग समस्या बिना बुझ्न सकिन्छ। यसरी मानिसहरूले कोड सिक्न र विकासकर्ताहरूको रूपमा बढ्छन्।

यो चक्र पुन: आविष्कार गर्नुहोस्

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

यहाँको बिन्दु तपाईको कोड उत्पादनमा पठाउनु होइन, तर केहि नयाँ सिक्नु हो। अवस्थित समाधानको आफ्नै कार्यान्वयन लेख्नु उत्तम प्रोग्रामरहरूबाट सिक्ने र यसरी आफ्नो सीपहरू सुधार्ने उत्तम तरिका हो।

स्रोत: www.habr.com