लेख की निरंतरता "लिंक की बातचीत और उनके अलगाव।" भाग 1

मैं लेख को दो भागों में तोड़ने के लिए जनता से माफी मांगना चाहता हूं। लेकिन हाल ही में बड़े ग्रंथों को हबेरा द्वारा स्वीकार किया जाना बंद हो गया है। अगर कोई मुझे बताता है कि इस दुर्भाग्य से कैसे निपटें: मैं आभारी रहूंगा।

भूमिका वितरण

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

लिंक में काम के गलत वितरण को रोकने के लिए, डेवलपर्स एक विशिष्ट परत से बंधे हैं। एक विशिष्ट परत पर काम को एक भूमिका कहा जाता है।

डेटा स्टोरेज लेयर की भूमिका

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

व्यापार तर्क परत की भूमिका

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

परत की भूमिका देखें

यूआई कार्यान्वयन
व्यापार तर्क परत की भूमिका द्वारा प्रदान किए गए इंटरफेस का उपयोग करके उपयोगकर्ता इंटरफ़ेस को व्यावसायिक तर्क परत से जोड़ना।
आभासी डेटा सेट का विकास और प्रस्ताव या व्यावसायिक तर्क परत के लिए एक अन्य डेटा ट्रांसफर अनुबंध।

भूमिका हस्तांतरण

यद्यपि डेवलपर्स को एक विशिष्ट भूमिका से बंधा होना चाहिए, उन्हें विभिन्न भूमिकाओं के बीच प्रवास करने में सक्षम होने की आवश्यकता होती है।

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

हालांकि, भूमिकाओं का हस्तांतरण आवश्यक रूप से नहीं किया जाना चाहिए और नियंत्रण की आवश्यकता होती है। डेवलपर्स को एक निश्चित समय पर कुछ निश्चित भूमिकाएँ निभानी चाहिए। यदि संभव हो तो, एक डेवलपर को एकल मॉड्यूल के भीतर एक से अधिक भूमिका स्वीकार नहीं करनी चाहिए। यदि सिस्टम में क्रेता मॉड्यूल है, तो प्रत्येक डेवलपर को क्रेता मॉड्यूल के भीतर एक से अधिक भूमिका नहीं दी जानी चाहिए। हालाँकि, यदि कोई डेवलपर क्रेता मॉड्यूल में व्यावसायिक तर्क की एक परत पर काम करता है, और फिर आपूर्तिकर्ता मॉड्यूल में एक प्रस्तुति परत विकसित करने के लिए स्विच करता है, तो यह स्वीकार्य है और संसाधनों के अधिक कुशल आवंटन की अनुमति देता है।

निम्नलिखित आंकड़ा भूमिकाओं के सही वितरण का एक उदाहरण दिखाता है।

निम्न आंकड़ा गलत भूमिका वितरण दिखाता है। जो और एडम दोनों एक ही मॉड्यूल में विभिन्न भूमिकाओं में काम करते हैं। इस तरह की गड़बड़ी परतों के बीच निकट संबंध और अलगाव का कारण बनती है।

पिछला उदाहरण वर्णन करने के लिए बहुत सरल है और प्रति मॉड्यूल केवल एक डेवलपर और लिंक का उपयोग करता है। हालांकि, ऐसा मामला काफी दुर्लभ है, और वास्तव में, कई डेवलपर्स लोड वितरित करते हैं। हालाँकि, जब तक कोई भी डेवलपर्स एक ही मॉड्यूल के भीतर लिंक के बीच नहीं जाता है, तब तक सिद्धांत का सम्मान किया जाता है।

इन उदाहरणों में, पेट्या पूरी तरह से डेटा भंडारण परत विकसित कर रहा है। यह वैकल्पिक है, और वास्तव में पेट्या अन्य परतों पर काम कर सकती है। अन्य डेवलपर्स डेटा स्टोरेज लेयर पर भी काम कर सकते हैं। लेकिन आमतौर पर डीबीए और केवल डीबीए डेटा भंडारण परत में लगे होते हैं, जो कि वास्तव में मैंने चित्रित किया है।

छोटी टीमें

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

अल्ट्रा स्माल टीम्स एंड सिंगल्स

अल्ट्रा-छोटी टीमों और एकल के पास एक ही मॉड्यूल के भीतर विभिन्न भूमिकाओं में काम करने के अलावा कोई विकल्प नहीं है। डेवलपर्स को परत के भीतर रहने और उनके बीच स्पष्ट आंदोलन करने की आवश्यकता है।

एक विशिष्ट विधि एक मॉड्यूल को पूरा करना है और पिछले एक पूरा होने पर अगले पर जाना है। निम्नलिखित दृष्टिकोण मान लें:

फिर भी, डेवलपर क्षैतिज रूप से 2/3 आंदोलनों को करेगा। अगर कुछ गलत हुआ है, तो एक कदम पीछे लेने की प्रवृत्ति, एक समझौता समाधान बनाएं और वापसी प्रबल होगी:

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

ध्यान दें कि इस दृष्टिकोण के साथ, केवल दो क्षैतिज चरण होते हैं:

यदि आप वर्णित दृष्टिकोण का उपयोग करते हैं, तो परतों के बीच बढ़ने के बजाय, मॉड्यूल के बीच भी स्थानांतरित करना न भूलें। निम्नलिखित आंकड़ा सबसे अच्छा तरीका दिखाता है:

लिंक्स और उनके अलगाव की बातचीत। भाग २