एक नई प्रणाली बनाना एक बहु-चरण प्रक्रिया है: अवधारणा और डिजाइन, वास्तुकला डिजाइन, कार्यान्वयन, परीक्षण, रिलीज का विस्तार। आर्किटेक्चर डिज़ाइन और कार्यान्वयन ऐसे चरण हैं जो डेवलपर्स मुख्य रूप से चिंतित हैं।

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

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

परिचय

एक सुविचारित वास्तुकला का उपयोग ब्रेकडाउन कार्यों के लिए आधार के रूप में किया जा सकता है : प्रत्येक पर्याप्त रूप से अलग-अलग घटक का कार्यान्वयन एक अलग उपशीर्षक बन जाता है।

उदाहरण के लिए, यदि पाइप और फिल्टर की शैली में डिज़ाइन की गई क्वेरी प्रोसेसिंग पाइप लाइन है, तो सभी चरणों को एक साथ जोड़ने के लिए सभी कार्य अलग-अलग प्रसंस्करण चरणों (प्रत्येक चरण का अपना सबटास्क) का कार्यान्वयन और एक अन्य सबटैक होगा।

यद्यपि एक सुविचारित वास्तुकला और उप-प्रकारों में टूट-फूट एक सामान्य विचार है कि कैसे एक प्रणाली बनाई जाए और आपको श्रम लागतों का मूल्यांकन करने की अनुमति दी जाए, वे योजना को लागू करने के लिए पर्याप्त नहीं हैं। उपमा का वर्णन यह कहेगा कि घटक को क्या करना चाहिए, इसमें गति और स्मृति की खपत की आवश्यकताएं हो सकती हैं, लेकिन यह कैसे करना है, इस पर व्यापक निर्देश नहीं देगा।

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

कोड डिजाइन अवधारणा

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

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

कई वास्तुशिल्प और तकनीकी समस्याएं उत्पन्न होती हैं: जहां मैट्रिक्स को स्टोर करना है, उन्हें नेटवर्क पर कैसे ट्रांसफर करना है, क्या करना है अगर मेट्रिक्स स्टोर अनुपलब्ध है, तो बैकएंड सेवा मीट्रिक कैसे रिकॉर्ड करेगी, आदि। आर्किटेक्चर को बस इन सवालों का जवाब देने की जरूरत है, समाधान के घटकों को निर्धारित करें और उनके लिए आवश्यकताओं को निर्धारित करें।

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

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

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

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

कोडिंग से पहले कार्यान्वयन चरण पर कोड डिज़ाइन पर सोचने की आवश्यकता कार्यान्वयन को दिलचस्प बनाती है : कोड डिज़ाइन को डिज़ाइन करने के कार्य आर्किटेक्चर स्तर पर संपूर्ण सिस्टम को डिज़ाइन करने से कम दिलचस्प नहीं हो सकते हैं। यह विचार ब्रूक्स ने पौराणिक मानव-महीने में व्यक्त किया था।

बेशक, वास्तुकला और कोड डिजाइन के बीच एक रेखा खींचना इतना आसान नहीं हो सकता है, आइए इस मुद्दे पर करीब से नज़र डालें।

वास्तुकला और कोड डिजाइन के बीच की सीमा

वैचारिक रूप से, आर्किटेक्चर और कोड डिज़ाइन डिज़ाइन के विभिन्न स्तरों पर हैं: आर्किटेक्चर को बहुत ही प्रारंभिक अवस्था में सोचा जाता है, जब थोड़ी निश्चितता होती है, और कोड डिज़ाइन के बारे में सोचने से विवरण जुड़ जाता है। तदनुसार, उन्हें समय में विभिन्न बिंदुओं पर निष्पादित किया जाता है: आर्किटेक्चर बहुत शुरुआत के करीब है, और उप-कार्य के कार्यान्वयन के दौरान कोड डिज़ाइन।

डिजाइन के इन दो चरणों के बीच एक सीमा खींचना कई कारकों पर निर्भर करता है, यहां मुख्य हैं:

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

कई विशेष मामले हैं जिनमें आप वास्तुशिल्प डिजाइन और कोड डिज़ाइन के बीच एक अच्छी रेखा खींच सकते हैं।

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

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

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

antipattern

ऐसे परिदृश्य हैं जब वास्तुकला और कार्यान्वयन पर सोच के बीच वितरण सही नहीं है, उनमें से कुछ नीचे चर्चा की गई है।

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

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

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

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

निष्कर्ष

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

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

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