आप जो नहीं समझते हैं, उसे विकसित करने के लिए सहमत न हों

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

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

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

हालाँकि आपको नीचे दिए गए कोड की एक भी पंक्ति नहीं दिखाई देगी, फिर भी मुझे लगता है कि उच्च गुणवत्ता वाले, अभिव्यंजक कोड लिखने के लिए यहां पर कही गई हर बात का बहुत महत्व है।

समझ का पहला स्तर: यह काम क्यों नहीं करता है?

डेवलपर्स आमतौर पर इस स्तर पर अपने करियर के शुरुआती चरणों में आते हैं, कभी-कभी दूसरों की मदद के बिना भी - कम से कम, मेरी टिप्पणियों के अनुसार। कल्पना करें कि आपको एक बग रिपोर्ट मिली: आवेदन में कुछ फ़ंक्शन काम नहीं करता है, आपको इसे ठीक करने की आवश्यकता है। आप कैसे कार्य करेंगे?

मानक योजना इस प्रकार है:

1. कोड का टुकड़ा ढूंढें जो समस्या का कारण बनता है (यह कैसे किया जाता है यह एक अलग विषय है, मैं इसे अपनी पुस्तक में आउटडेटेड कोड पर प्रकट करता हूं)
2. इस स्निपेट में बदलाव करें
3. सुनिश्चित करें कि बग ठीक हो गया है और कोई प्रतिगामी त्रुटियां नहीं हैं

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

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

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

समझ का दूसरा स्तर: यह क्यों काम करता है?

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

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

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

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

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

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

तीसरे स्तर की समझ: यह क्यों काम करता है?

मेरी हाल की अंतर्दृष्टि इस स्तर के साथ ठीक से जुड़ी हुई है, और शायद इससे मुझे सबसे अधिक लाभ होगा अगर मैं इस विचार पर पहले आया था।

इसे स्पष्ट करने के लिए, आइए एक उदाहरण देखें: अपने मॉड्यूल को फ़ंक्शन X के साथ संगत बनाया जाना चाहिए। आप फ़ंक्शन X से विशेष रूप से परिचित नहीं हैं, लेकिन आपको बताया गया था कि आपको इसके साथ संगतता के लिए F. फ्रेमवर्क का उपयोग करने की आवश्यकता है। अन्य मॉड्यूल जो एक्स के साथ एकीकृत होते हैं, बिल्कुल काम करते हैं। उसके साथ।

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

और कुछ बिंदु पर आप अचानक महसूस करते हैं - या शायद किसी से सुनते हैं - कि शायद एफ फ्रेमवर्क आपको एक्स फ़ंक्शन के साथ बिल्कुल भी संगतता नहीं देगा। शायद यह सब समय और प्रयास पर लागू नहीं हुआ था। उस तक।

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

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

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

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

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