तुम्हाला समजत नसलेली एखादी गोष्ट विकसित करण्यास सहमती दर्शवू नका

2018 च्या सुरुवातीपासून, मी टीममध्ये लीड/बॉस/लीड डेव्हलपर या पदावर आहे - तुम्हाला काय हवे आहे ते म्हणा, पण मुद्दा असा आहे की मी एका मॉड्यूलसाठी आणि काम करणाऱ्या सर्व डेव्हलपरसाठी पूर्णपणे जबाबदार आहे. त्यावर. ही स्थिती मला विकास प्रक्रियेकडे एक नवीन दृष्टीकोन देते, कारण मी अधिक प्रकल्पांमध्ये सामील आहे आणि निर्णय घेण्यात अधिक सक्रियपणे सहभागी आहे. अलीकडे, या दोन परिस्थितींबद्दल धन्यवाद, मला अचानक लक्षात आले की समजून घेण्याचे उपाय कोड आणि अनुप्रयोगावर किती परिणाम करतात.

मला सांगायचा मुद्दा असा आहे की कोडची गुणवत्ता (आणि अंतिम उत्पादन) कोड डिझाइन आणि लिहिणारे लोक ते काय करत आहेत याबद्दल किती जागरूक आहेत याच्याशी जवळून संबंधित आहे.

तुम्ही आत्ता विचार करत असाल, “धन्यवाद, कॅप. अर्थात, आपण सर्वसाधारणपणे काय लिहित आहात हे समजून घेणे चांगले होईल. अन्यथा, तुम्ही मनमानी चाव्या मारण्यासाठी माकडांच्या एका गटाला भाड्याने देऊ शकता आणि ते तिथेच सोडू शकता." आणि तुम्ही अगदी बरोबर आहात. त्यानुसार, मी हे गृहीत धरतो की तुम्ही काय करत आहात याची सामान्य कल्पना असणे आवश्यक आहे. याला समजण्याची शून्य पातळी म्हटले जाऊ शकते आणि आम्ही त्याचे तपशीलवार विश्लेषण करणार नाही. तुम्हाला नेमके काय समजून घेणे आवश्यक आहे आणि तुम्ही दररोज घेतलेल्या निर्णयांवर त्याचा कसा परिणाम होतो हे आम्ही तपशीलवार पाहू. मला या गोष्टी अगोदर कळल्या असत्या तर माझा बराच वेळ वाया गेला असता आणि शंकास्पद कोड वाचला असता.

जरी तुम्हाला खाली कोडची एक ओळ दिसणार नाही, तरीही मला विश्वास आहे की येथे सांगितलेली प्रत्येक गोष्ट उच्च-गुणवत्तेचा, अर्थपूर्ण कोड लिहिण्यासाठी खूप महत्त्वाची आहे.

समजून घेण्याचा पहिला स्तर: ते का काम करत नाही?

डेव्हलपर्स सहसा त्यांच्या करिअरमध्ये खूप लवकर या स्तरावर पोहोचतात, कधीकधी अगदी इतरांच्या मदतीशिवाय - किमान माझ्या अनुभवानुसार. कल्पना करा की तुम्हाला बग रिपोर्ट प्राप्त झाला आहे: अनुप्रयोगातील काही फंक्शन कार्य करत नाही, ते निश्चित करणे आवश्यक आहे. तुम्ही कसे पुढे जाल?

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

1. समस्या निर्माण करणार्‍या कोडचा तुकडा शोधा (हे कसे करायचे हा एक वेगळा विषय आहे, मी ते माझ्या लेगसी कोडबद्दलच्या पुस्तकात दिले आहे)
2. या स्निपेटमध्ये बदल करा
3. दोष निश्चित केला आहे आणि कोणतीही प्रतिगमन त्रुटी आली नाही याची खात्री करा

आता दुसऱ्या मुद्द्यावर लक्ष केंद्रित करू - कोडमध्ये बदल करणे. या प्रक्रियेसाठी दोन दृष्टिकोन आहेत. पहिले म्हणजे सध्याच्या कोडमध्ये नेमके काय घडत आहे याचा शोध घेणे, त्रुटी ओळखणे आणि त्याचे निराकरण करणे. दुसरा: फील द्वारे हलवा - कंडिशनल स्टेटमेंट किंवा लूपमध्ये जोडा, म्हणा, +1 करा, फंक्शन इच्छित परिस्थितीत कार्य करते का ते पहा, नंतर काहीतरी करून पहा, आणि जाहिरात अनंत.

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

जे सांगितले गेले आहे ते सारांशित करण्यासाठी, कोडची गुणवत्ता खराब होणार नाही असे चांगले दोष निराकरण करण्यासाठी, तुम्हाला कोडची संपूर्ण रचना आणि विशिष्ट समस्येचा स्रोत दोन्ही समजून घेणे आवश्यक आहे.

समजण्याची दुसरी पातळी: ते का कार्य करते?

ही पातळी मागील पातळीपेक्षा खूपच कमी अंतर्ज्ञानाने समजली जाते. मी, एक नवशिक्या विकसक असताना, माझ्या बॉसचे आभार मानून ते शिकलो आणि त्यानंतर वारंवार या प्रकरणाचे सार नवोदितांना समजावून सांगितले.

या वेळी, कल्पना करूया की तुम्हाला एकाच वेळी दोन बग अहवाल प्राप्त झाले आहेत: पहिली परिस्थिती A बद्दल आहे, दुसरी परिस्थिती B बद्दल आहे. दोन्ही परिस्थितींमध्ये, काहीतरी चूक होते. त्यानुसार, तुम्ही प्रथम प्रथम बग हाताळा. आम्ही स्तर XNUMX समजून घेण्यासाठी विकसित केलेली तत्त्वे वापरून, तुम्ही समस्येशी संबंधित कोडमध्ये खोलवर जा, ते अनुप्रयोगाला परिस्थिती 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