तपाईंले नबुझेको कुरा विकास गर्न सहमत हुनुहोस्

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

म यो बनाउन चाहन्छु कि कोडको गुणस्तर (र अन्तिम उत्पादन) कोड डिजाइन गर्ने र लेख्ने व्यक्तिहरू के गर्दैछन् भन्ने बारे कत्तिको सचेत छन् भन्ने कुरासँग नजिकको सम्बन्ध छ।

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

यद्यपि तपाईले तलको कोडको एक पङ्क्ति देख्नुहुने छैन, म अझै पनि विश्वास गर्छु कि यहाँ भनिएको सबै कुरा उच्च-गुणस्तर, अभिव्यक्त कोड लेख्नको लागि धेरै महत्त्वपूर्ण छ।

बुझाइको पहिलो स्तर: किन यसले काम गर्दैन?

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

मानक योजना यस्तो देखिन्छ:

1. समस्या निम्त्याउने कोडको टुक्रा फेला पार्नुहोस् (यो कसरी गर्ने छुट्टै विषय हो, म यसलाई लिगेसी कोडको बारेमा मेरो पुस्तकमा कभर गर्छु)
2. यस स्निपेटमा परिवर्तन गर्नुहोस्
3. निश्चित गर्नुहोस् कि बग फिक्स गरिएको छ र कुनै रिग्रेसन त्रुटिहरू देखा परेका छैनन्

अब दोस्रो बिन्दुमा फोकस गरौं - कोडमा परिवर्तनहरू गर्दै। यस प्रक्रियामा दुई दृष्टिकोणहरू छन्। पहिलो भनेको हालको कोडमा वास्तवमा के भइरहेको छ भनेर पत्ता लगाउनु हो, त्रुटि पहिचान गर्नुहोस् र यसलाई ठीक गर्नुहोस्। दोस्रो: अनुभूतिद्वारा सार्नुहोस् - सशर्त कथन वा लुपमा थप्नुहोस्, भन्नुहोस्, +1 गर्नुहोस्, कार्यले इच्छित परिदृश्यमा काम गर्छ कि गर्दैन हेर्नुहोस्, त्यसपछि अरू केहि प्रयास गर्नुहोस्, र यस्तै विज्ञापन अनन्तमा।

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

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

बुझाइको दोस्रो स्तर: किन यसले काम गर्छ?

यो स्तर अघिल्लो एक भन्दा धेरै कम सहज रूपमा बुझिएको छ। मैले, एक नौसिखिया विकासकर्ता हुँदा, यो मेरो मालिकको लागि धन्यवाद सिकें, र पछि बारम्बार नयाँ आउनेहरूलाई यस कुराको सार व्याख्या गरें।

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

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

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

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

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

बुझाइको तेस्रो स्तर: यसले किन काम गर्छ?

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

यसलाई स्पष्ट पार्नको लागि, एउटा उदाहरण हेरौं: तपाईँको मोड्युललाई प्रकार्य Xसँग मिल्दो बनाउन आवश्यक छ। तपाईँलाई विशेष रूपमा प्रकार्य Xसँग परिचित हुनुहुन्न, तर तपाईँलाई यससँग मिल्दो हुनको लागि तपाईँलाई F फ्रेमवर्क प्रयोग गर्न आवश्यक छ X सँग एकीकृत हुने मोड्युलहरू उहाँसँग ठ्याक्कै काम गर्छन्।

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

र कुनै बिन्दुमा तपाईंले अचानक महसुस गर्नुहुन्छ - वा हुनसक्छ कसैबाट सुन्नुहुन्छ - कि हुनसक्छ फ्रेमवर्क F ले तपाइँलाई सुविधा X सँग कम्प्याटिबिलिटी प्रदान गर्दैन सायद त्यो सबै समय र प्रयास पूर्ण रूपमा गलत थियो।

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

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

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

समझ को चौथो स्तर: ???

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

स्रोत: www.habr.com