जैसे ही डेवलपर कंपनी में प्रवेश करता है और कार्य प्राप्त करता है, यह सबसे अधिक बार पता चलता है कि उसे कुछ टीम के आम प्रोजेक्ट में शामिल होने की आवश्यकता है, और खरोंच से अपना कोड नहीं लिखना चाहिए।
किसी भी कोड के अपने तर्क होते हैं, कुछ सिद्धांतों के आधार पर, इसमें टीम के पैटर्न और प्रौद्योगिकियां होती हैं, जिनसे प्रोग्रामर जुड़ता है। लेकिन जल्दी से किसी और की परियोजना को कैसे समझना शुरू करें, इस तथ्य के बावजूद कि यह शायद ही छोटा है, और अक्सर कोई भी दस्तावेज नहीं है, या क्या यह अपर्याप्त और गलत है?
हम आपको याद दिलाते हैं: "हैबर" के सभी पाठकों के लिए - "हैबर" प्रोमो कोड का उपयोग करके किसी भी स्किलबॉक्स कोर्स के लिए पंजीकरण करते समय 10,000 रूबल की छूट।
स्किलबॉक्स अनुशंसा करता है: फ्रंटेंड डेवलपर पेशे ऑनलाइन पाठ्यक्रम।
वास्तव में, सबसे अच्छा दस्तावेज स्वयं कोड है और जिन्होंने इस कोड को बनाया है (बशर्ते कि वे अभी भी आस-पास कहीं हैं और कंपनी को नहीं छोड़ा है)। मैं अपना योगदान देते हुए न्यूनतम समय तक कैसे कम कर सकता हूं और जल्दी से काम कर सकता हूं?
मैंने एक प्रोग्रामर के रूप में अपने काम के पिछले 15 वर्षों में इस स्थिति का बार-बार सामना किया है, और यहाँ इस विषय पर मेरे विचार हैं।
परियोजना के लक्ष्य और उद्देश्य
पहली चीज जो आपको करनी चाहिए वह यह समझने में थोड़ा समय बिताती है कि आप किस कोड (कोड) के लिए आवेदन कर रहे हैं। यह एक वैश्विक चुनौती है; इसे हल करने के बाद, आप हर चीज का सामना करेंगे।
आपको यह समझे बिना परियोजना पर काम नहीं किया जा सकता कि इसकी आवश्यकता क्यों है। सामान्य समझ आपको छोटी चीज़ों को जल्दी समझने की अनुमति देगा। इसके अलावा, आपका अपना काम बाकी टीम के साथ अधिक सामंजस्यपूर्ण तरीके से किया जाएगा। ईंट से ईंट - यह घर कैसे बनाया जाता है।
आर्किटेक्चर
जब आपने मुख्य कार्य सीख लिया है, तो अपने आप को कोड निष्पादन और उसके तर्क के विश्लेषण के लिए समर्पित करें।
कुछ परियोजनाओं की वास्तुकला बल्कि जटिल है, खासकर अगर इन परियोजनाओं की बुनियादी प्रौद्योगिकियां आपके लिए बहुत परिचित नहीं हैं। मूल तर्क को देखने के लिए, शुरुआत में, तकनीकी दस्तावेज (या अपने सहयोगियों से इसके बारे में पूछने) खोजने की कोशिश करें।
परियोजना की संरचना को ध्यान में रखते हुए, आप तेजी से काम शुरू करने में सक्षम होंगे, और इसलिए कि अन्य सभी टीम के सदस्यों के कामकाज में हस्तक्षेप न करें।
परियोजना में ऐसे टुकड़े हो सकते हैं जो सामान्य तर्क का उल्लंघन करते हैं, लेकिन, विचार और वास्तुकला को जानने के बाद, आप समस्या को ठीक कर सकते हैं, "ईंटों" को बदल सकते हैं या बदल सकते हैं ताकि वे पूरी तरह से सामान्य इमारत में फिट हो सकें।
पैटर्न (टेम्पलेट्स)
बड़ी संख्या में पैटर्न हैं जो डेवलपर्स कोड लिखते समय उपयोग करते हैं। ये संरचनात्मक पैटर्न हैं, "व्यवहार", तकनीकी और अन्य। कार्यक्रमों को डिजाइन करते समय सामान्य समस्याओं को हल करने के तरीकों को टाइप करने में ये सभी मदद करते हैं।
यह समझना कि आपके वर्तमान प्रोजेक्ट में कौन से पैटर्न का उपयोग किया जाता है, कक्षा स्तर पर, यह समझने में मदद करेगा कि कार्यों को कोड में कैसे बनाया जाना चाहिए। नतीजतन, आप एक सुसंगत कोड बनाने में सक्षम होंगे जो सामान्य तर्क और पैटर्न के अनुरूप होगा, जो अंततः कोड पर बहुत कम संख्या में टिप्पणियों का नेतृत्व करेगा, इसके बारे में बेहतर समझ और यदि आवश्यक हो तो त्रुटियों का शीघ्र उन्मूलन।
प्रोजेक्ट पर थोड़ा काम करने के बाद, आप एक नज़र में समझ पाएंगे कि कोड के कौन से सेक्शन समग्र संरचना में फिट होते हैं और रिफ़ॉर्मिंग की क्या आवश्यकता होती है।
दिशा निर्देशों
अधिकांश टीमों के कुछ नियम होते हैं, या बल्कि, नियमों का एक सेट जिसके अनुसार हर कोई कार्य करता है। यह न केवल काम के सामान्य सिद्धांतों के बारे में है, बल्कि कक्षाओं और अनुप्रयोग स्तरों के उपयोग के बारे में भी है। यदि टीम के प्रतिनिधियों को समान दिशानिर्देशों द्वारा निर्देशित किया जाता है, तो विकसित कोड समझना और पढ़ना आसान है।
सबसे अधिक संभावना है, आप जिस टीम में शामिल होते हैं, उसके पास दिशानिर्देश भी होते हैं जिन्हें आपको सीखने की आवश्यकता होती है। सबसे पहले, वे प्रोग्रामिंग भाषा से संबंधित हैं, जो विकास के दौरान मुख्य है।
आप पूछ सकते हैं कि परियोजना, इसकी वास्तुकला, टेम्पलेट्स और दिशानिर्देशों के बारे में सभी जानकारी कहाँ से प्राप्त करें। आवश्यक तरीकों को प्राप्त करने के लिए कई तरीके हैं, सिवाय उन लोगों के जो पहले से ही ऊपर उठाए गए हैं:
- किसी भी जानकारी के लिए देखो, यहां तक कि जिसे अप्रासंगिक माना जा सकता है; अपनी टीम द्वारा उपयोग किए जाने वाले सामान्य शब्दों, संक्षिप्ताक्षरों और अवधारणाओं का अपना ज्ञानकोष बनाएं।
- एक बार जब यह डेटाबेस तैयार हो जाता है, तो आप परियोजना प्रबंधक के साथ आपके हित के सभी मुद्दों पर चर्चा कर सकते हैं, क्योंकि आप पहले से ही एक ही भाषा बोलते हैं।
- इसके अलावा, यह आपके प्रोजेक्ट के समग्र आर्किटेक्चर के बारे में एप्लीकेशन आर्किटेक्ट्स और टीम लीडर्स के साथ बात करने लायक है। फिर इस वास्तुकला और इसके साथ जुड़े कोड अनुकूलन तकनीकों के बारे में अधिक जानने की कोशिश करें। यदि आप कुछ ऐसा देखते हैं, जो आपकी राय में, आवेदन के सामान्य तर्क का उल्लंघन करता है, तो टीम लीडर के साथ इस बारे में चर्चा करना सुनिश्चित करें।
- अपने टीम के साथियों से पता करें कि कोड पर काम के दौरान और भविष्य में रखरखाव के दौरान कौन से पैटर्न और नियमों का उपयोग किया जाता है। एक बार जब आप मुख्य बिंदुओं को जान लेते हैं, तो तुलना करें कि भविष्य में क्या सबसे अच्छा है और उसी के अनुसार कार्य करें।
- संभावित और वास्तविक समस्याओं से कोड के एक भाग को साफ करने की कोशिश करें - इससे आपको परियोजना और उसके कोड की गहरी समझ प्राप्त करने में मदद मिलेगी। आपकी टीम कोड को साफ करने के लिए क्या उपयोग करती है?
सामान्यतया, अपनी टीम को संलग्न करने का सबसे अच्छा मौका है कि किस दिशा-निर्देश की समीक्षा की जाए और भविष्य में किनका उपयोग किया जाए।
टीम के साथ अपने स्वयं के घटनाक्रम को साझा करें, सक्रिय रूप से कामकाजी बैठकों में भाग लें, वर्तमान समस्याओं, आवेदन की वास्तुकला और इसके तत्वों, टेम्पलेट्स और अन्य महत्वपूर्ण बिंदुओं पर चर्चा करें। अतिरिक्त जानकारी प्राप्त करने के लिए कार्य बैठक एक विश्वसनीय चैनल हो सकता है; यह उनकी टिप्पणियों / उपलब्धियों के बारे में बात करने लायक है, जो सभी के लिए उपयोगी हो सकती हैं।
नतीजतन, आप न केवल जल्दी से काम शुरू कर सकते हैं, बल्कि टीम में भी शामिल हो सकते हैं, थोड़े समय में इसके अपूरणीय भागीदार बन सकते हैं।
बेशक, आप उन लोगों से मिलेंगे जिनके साथ संवाद करना मुश्किल है; कोड के साथ समस्याएँ होंगी। लेकिन ऐसा लगभग हमेशा होता है - ऐसी टीमें हैं जहां सब कुछ सही है, लेकिन वे बहुत कम हैं।
स्किलबॉक्स अनुशंसा करता है: