व्यवहार पैटर्न

(यह नोट तकनीकी ऋण , रिफैक्टिंग सिंड्रोम और दूसरी प्रणाली के प्रभाव वाले पदों की एक श्रृंखला का अंत है)

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

"तकनीकी ऋण" , "रीफैक्टरिंग सिंड्रोम" और "दूसरा सिस्टम प्रभाव" विशिष्ट परिस्थितियां हैं जो विकास टीम समय-समय पर सामना करती हैं। और उनसे मुख्य लाभ समस्या को देखने और सही लोगों तक इसके अस्तित्व को साबित करने के लिए ठीक है। यदि आप स्वयं महसूस करते हैं कि परियोजना का तकनीकी ऋण बहुत अधिक है, तो धन के रूपक का उपयोग करके प्रबंधक या ग्राहक को इस समस्या के महत्व को साबित करना बहुत आसान हो जाएगा। और फिर उसे ध्यान से विकासशील घटनाओं के वैकल्पिक तरीके दिखाएं: (1) सब कुछ छोड़ देना जैसा वह है; (2) उचित रीफैक्टरिंग के माध्यम से तकनीकी ऋण को कम करना; या (3) सब कुछ फिर से लिखना।


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

सही कार्यों और उचित व्यावहारिकता के लिए सही लोगों का उपयोग करने के अलावा, कुछ विचार हैं जिन्हें आपको सभी प्रकार के जोखिमों को कम करने और अनुचित तकनीकी निर्णय लेने के बारे में सोचना चाहिए।

जोखिम प्रबंधन और इनकैप्सुलेशन

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

हाँ, ऐसे सवाल हो सकते हैं कि "क्या होगा यदि वसीली ने ओक को विश्लेषण के चरण को पूरा करने या आवश्यकताओं को इकट्ठा करने से पहले दिया?" (**) बहुत कठिन हो सकता है और शायद ही सहयोगियों से तालियों के साथ मुलाकात की जा सकती है, लेकिन "क्या?" यदि हमारा वर्तमान समाधान गलत हो गया है? ”बहुत उपयोगी हो सकता है।

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

ऐसी त्रुटियों के जोखिम को कम करने का मुख्य विचार ऐसे समाधानों को कम से कम संख्या में मॉड्यूल में संलग्न करना है। यह उन मॉड्यूलों की संख्या को कम कर देगा जिन्हें किसी त्रुटि की स्थिति में बदलना होगा और तकनीकी ऋण और बाद के परिवर्तनों की लागत दोनों को कम करेगा।

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

यह इतना भयावह लग सकता है कि इसके बारे में (अच्छी तरह से, या लिखने के बारे में भी) बात करने लायक नहीं है, लेकिन, दुर्भाग्य से, इस तरह के उदाहरण बहुत बार यह सोचने के लिए आते हैं कि हर कोई इसके बारे में जानता है।

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

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

इंटरप्रोसेस संचार मॉड्यूल पर फिर से लौटते हुए, हम इस इंटरैक्शन के खुले इंटरफ़ेस को एकल कर सकते हैं और कार्यान्वयन विवरण के अनुसार WCF को जितना संभव हो सके छिपा सकते हैं। मुझे इस बात में कोई संदेह नहीं है कि इस उपक्रम से 100% कुछ भी नहीं निकलेगा, और “लीक अमूर्त के कानून” के अनुसार , निम्न-स्तरीय कार्यान्वयन विवरण के बारे में जानकारी अन्य स्तरों या मॉड्यूल पर लीक हो जाएगी। लेकिन यहां तक ​​कि सरल प्रश्न का उत्तर देने का प्रयास "क्या होगा अगर यह बकवास बंद नहीं होता है और आपको वर्तमान समाधान छोड़ना होगा?", यदि यह बकवास वास्तव में बंद नहीं होता है तो परिणामों को कम करना चाहिए।

एक सिर अच्छा है, और दो एक उत्परिवर्तन है

एक व्यक्ति को कई निर्णय लेने होते हैं। यह संभावना नहीं है कि कुछ यात्रा होगी यदि डिजाइनर चारों ओर चलता है और सभी पंद्रह डेवलपर्स से राय मांगता है और उनमें से प्रत्येक को खुश करने की कोशिश करता है। इसी समय, यह इस तरह के बकवास को बंद कर देगा कि इन दिनों विंडोज 3.11 को डिजाइन कला और एर्गोनॉमिक्स की ऊंचाई प्रतीत होती है। और अगर एप्लिकेशन आर्किटेक्ट हर किसी की सलाह मांगता है और हर कोई जो सिस्टम के आर्किटेक्चर पर अपनी राय रखता है (और, जैसा कि आप जानते हैं, प्रत्येक प्रोजेक्ट प्रतिभागी के पास है), इस काम का परिणाम भी लंबा नहीं लगेगा।

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

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

पहली समस्या यह है कि लोग धीरे-धीरे एक आदत विकसित कर रहे हैं कि "काली मिर्च" सही है, जबकि खुद "काली मिर्च" भी ऐसी आदत है। नतीजतन, हर कोई प्रवाह के साथ जाता है, कोई भी महत्वपूर्ण निर्णयों को विवादित नहीं करता है, क्योंकि उसके फैसलों पर भरोसा किया जाता है। इस तरह के रवैये के परिणामस्वरूप, इन निर्णयों की गुणवत्ता कम हो जाती है।

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

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

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

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

दृढ़तापूर्वक

निश्चित रूप से एक टन अन्य तरीके हैं जो पिछले नोटों में वर्णित समस्याओं को कम कर सकते हैं, लेकिन मुझे लगता है कि कुछ युक्तियां, हालांकि वे इन समस्याओं को हल नहीं करेंगे, उनकी घटना के जोखिम को काफी कम कर सकते हैं। तो, यहाँ वे संक्षिप्त रूप में हैं:

1) व्यावहारिकता नियम (कोई चरम सीमा की आवश्यकता नहीं है); यह सलाह हमेशा और हर जगह लागू होती है, और यह "रिफैक्टिंग सिंड्रोम" और "दूसरी प्रणाली प्रभाव" जैसी समस्याओं से बचने में भी मदद करती है।

2) पत्थर में अपने फैसलों में कटौती न करें (एक मौका है कि आपने कहीं पेंच किया है, और फिर आपको छेनी से निपटना होगा)

3) उचित रूप से उचित सहयोगियों के साथ परामर्श करें, क्योंकि बाहर से एक दृश्य हमेशा उपयोगी होता है

--------------------------------------

(*) लाभ के अलावा, डिजाइन पैटर्न हानिकारक हो सकते हैं। किसी भी सबसे उपयोगी उपकरण या प्रौद्योगिकी के विचारहीन और अनुचित उपयोग से "असावधानी और भ्रष्टाचार" को बढ़ावा मिलेगा। जब आप एक साधारण अवधारणा को लागू करने के लिए एक दर्जन डिजाइन पैटर्न का उपयोग कर चुके हैं, तो आपने कितनी बार "ओवरगेंरिंग" समस्या का सामना किया है? सामान्य तौर पर, यह इस तथ्य का एक और उदाहरण है कि व्यावहारिकता और सामान्य ज्ञान, हमेशा की तरह, सबसे अच्छा विकल्प हैं, और डिजाइन पैटर्न कोई अपवाद नहीं है।

(**) खुद जॉन के अनुसार, उन्होंने अपनी पहली रैलियों में यह सवाल पूछा था। वस्तुतः, उनका प्रश्न था: "क्या होगा अगर बॉब मर जाता है इससे पहले कि हम आवश्यकताओं के संग्रह के चरण को पूरा करें?", मोटे तौर पर विवरण के लिए मूल का संदर्भ लें: "डीबगिंग अनुप्रयोग .NET 2.0 अनुप्रयोग" , अनुभाग "कोड पहले, बाद में सोचो" दृष्टिकोण। "

(***) मैं जॉन स्केट द्वारा अल MiscUtils के पुस्तकालयों के बारे में बात नहीं कर रहा हूँ। सबसे पहले, वास्तविक समस्याओं को हल करने में उनकी लाइब्रेरी "बढ़ी", और दूसरी बात, मुझे बस यकीन है कि जॉन ने सहयोगियों और उपयोगकर्ताओं की प्रतिक्रिया के आधार पर इसमें बहुत सारे बदलाव किए। यदि आप कम से कम बड़े पुस्तकालयों को डिजाइन करने की जटिलताओं के बारे में थोड़ा सीखना चाहते हैं, तो अब्राम्स और कैवलिना द्वारा "फ्रेमवर्क डिज़ाइन दिशानिर्देश" देखें, इस विषय पर बहुत सारे दिलचस्प विचार हैं।