कुछ ऐसा विकसित करने के लिए सहमत न हों जो आपको समझ में न आए

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

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

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

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

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

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

मानक योजना इस प्रकार दिखती है:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

स्रोत: www.habr.com