कई छोटे लोगों में एक संभावित अखंड आवेदन को विभाजित करने से कीड़े को रोकने में मदद मिलती है? [बन्द है]

Question

यह पूछने का एक और तरीका है; कार्यक्रम अखंड क्यों होते हैं?

मैं माया जैसे एनीमेशन पैकेज की तरह कुछ सोच रहा हूं, जो लोग विभिन्न विभिन्न वर्कफ़्लो के लिए उपयोग करते हैं।

यदि एनीमेशन और मॉडलिंग क्षमताओं को अपने स्वयं के अलग अनुप्रयोग में विभाजित किया गया था और अलग-अलग विकसित किया गया था, तो उनके बीच फ़ाइलों को पारित किया गया था, तो क्या उन्हें बनाए रखना आसान नहीं होगा?

Comments

If the animation and modelling capabilities were split into their own separate application and developed separately, with files being passed between them, would they not be easier to maintain?मॉड्यूल-सेपर को बनाए रखने के लिए आसान के साथ विस्तार करने के लिए आसान मिश्रण न करें- जटिलताओं या संदिग्ध डिजाइनों से मुक्त नहीं है। माया पृथ्वी पर नरक बनाए रखने के लिए हो सकती है जबकि इसके प्लगइन्स नहीं हैं। या ठीक इसके विपरीत।

— लैव

मैं जोड़ूंगा कि एकल एकल कार्यक्रम बेचने में आसान हो जाता है , और अधिकांश लोगों के लिए उपयोग करना आसान होता है ।

— डेर्थफेनेक

@DarthFennec सर्वश्रेष्ठ ऐप उपयोगकर्ता के लिए एक ऐप की तरह दिखते हैं लेकिन हुड के नीचे जो भी आवश्यक है उसका उपयोग करते हैं। आपके द्वारा देखी जाने वाली विभिन्न वेबसाइटों में कितने माइक्रोसेवर पावर हैं? उनमें से लगभग कोई भी अब मोनोलिथ नहीं है!

— corsiKa

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

— डेर्थफेनेक

@ कोर्सीका - मुझे लगता है कि मैं जिन वेबसाइटों का उपयोग करता हूं, उनकी संख्या अभी भी मोनोलिथ है। अधिकांश इंटरनेट, आखिरकार, Wordpress पर चलता है।

— --द्रालो

Answer 1

हाँ। आम तौर पर दो छोटे कम जटिल अनुप्रयोग एक एकल बड़े को बनाए रखने के लिए बहुत आसान होते हैं।

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

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

Comments

हां और प्रदर्शन के विचार भी हैं जैसे कि एक सूचक बनाम क्रमबद्ध डेटा के आसपास से गुजरने की लागत।

— जिमीजैम

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

— Doc Brown

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

— वू

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

— वू

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

— आर। श्मिट

Answer 2

कई छोटे लोगों में एक संभावित अखंड आवेदन को विभाजित करने से कीड़े को रोकने में मदद मिलती है

चीजें शायद ही कभी सच में सरल होती हैं।

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

हालाँकि,

• यहां तक ​​कि एक आवेदन जो बाहर से अखंड प्रतीत होता है, उसमें बहुत अधिक इकाई-परीक्षण योग्य घटक शामिल हो सकते हैं, इसलिए एक अखंड एप्लिकेशन के लिए यूनिट परीक्षण आवश्यक नहीं है

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

यह इस बात पर भी निर्भर करता है कि एक बड़ा ऐप कितने अच्छे से कंपोनेंट में विभाजित हो सकता है, और कंपोनेंट्स के बीच इंटरफेस कितना व्यापक है और उन इंटरफेस का उपयोग कैसे किया जाता है।

संक्षेप में, यह अक्सर एक व्यापार-बंद है, और कुछ भी नहीं है जहां "हाँ" या "नहीं" उत्तर सामान्य रूप से सही है।

कार्यक्रम अखंड क्यों होते हैं

क्या वे? अपने आस-पास देखें, दुनिया में वेब ऐप्स के गजिलियन्स हैं जो मुझे बहुत अखंड नहीं लगते हैं, बिल्कुल विपरीत। बहुत सारे प्रोग्राम भी उपलब्ध हैं जो एक प्लगइन मॉडल प्रदान करते हैं (AFAIK यहां तक ​​कि आपके द्वारा उल्लेख किया गया माया सॉफ्टवेयर)।

क्या उन्हें बनाए रखना आसान नहीं होगा

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

Comments

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

— वारबो

Answer 3

मुझे इस पर बहुमत से असहमत होना पड़ेगा। किसी एप्लिकेशन को दो अलग-अलग हिस्सों में विभाजित करना अपने आप में कोड को बनाए रखने या इसके बारे में कारण को आसान नहीं बनाता है।

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

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

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

Comments

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

— द ग्रेट डक

@ TheGreatDuck ऐसा लगता है कि यह उन उपयोगकर्ताओं की गैर-तुच्छ राशि को भी समाप्त कर देगा जो विभिन्न अनुप्रयोगों के बीच स्विच करना पसंद नहीं करते हैं। ;) लेकिन हाँ, सुविधाओं को समाप्त करने से आम तौर पर सरल कोड हो जाएगा। वर्तनी-जाँच को समाप्त करें और आप वर्तनी-जाँच बग होने की संभावना को दूर करेंगे। यह केवल शायद ही कभी किया जाता है क्योंकि सुविधा को जोड़ा गया था क्योंकि कोई इसे चाहता था।

— Odalrick

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

— वू

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

— एलेक्स

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

— वू

Answer 4

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

Comments

महान पद। मुझे लगता है कि आप जो बात करते हैं उसका एक क्लासिक / विहित उदाहरण जीयूआई अनुप्रयोग है। कई बार एक जीयूआई आवेदन एक कार्यक्रम है और बैकएंड / फ्रंटेंड कसकर-युग्मित हैं। जैसे-जैसे समय बीतता जाता है, वैसे-वैसे ... किसी और को बैकएंड का उपयोग करने की आवश्यकता होती है, लेकिन ऐसा नहीं हो सकता क्योंकि यह फ्रंटेंड से जुड़ा होता है। या बैकएंड प्रोसेसिंग में बहुत लंबा समय लगता है और फ्रंटएंड नीचे चला जाता है। अक्सर एक बड़ा जीयूआई एप्लिकेशन दो कार्यक्रमों में विभाजित होता है: एक फ्रंट जीयूआई है और एक बैकएंड है।

— ट्रेवर बॉयड स्मिथ

Answer 5

यह याद रखना महत्वपूर्ण है कि सहसंबंध कार्य-कारण नहीं है।

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

लेकिन एक अच्छा डिज़ाइन अक्सर एक सिस्टम को एक बड़े मोनोलिथ के बजाय कई छोटे भागों के रूप में बनाया जाता है। (एक मोनोलिथ सबसे अच्छा डिज़ाइन हो सकता है, यह होने की संभावना बहुत कम है।)

छोटे हिस्से बेहतर क्यों हैं? क्योंकि वे कारण के लिए आसान कर रहे हैं। और अगर सही होने के बारे में तर्क करना आसान है, तो आपको एक सही परिणाम मिलने की अधिक संभावना है।

कार होरे को उद्धृत करने के लिए:

एक सॉफ्टवेयर डिज़ाइन के निर्माण के दो तरीके हैं: एक तरीका यह है कि इसे इतना सरल बनाया जाए कि जाहिर तौर पर कोई कमी न हो, और दूसरा तरीका यह है कि इसे इतना जटिल बना दिया जाए कि कोई स्पष्ट कमी न रहे ।

यदि ऐसा है, तो कोई भी अनावश्यक रूप से जटिल या अखंड समाधान क्यों बनाएगा? होरे ने अगले वाक्य में उत्तर दिया:

पहली विधि कहीं अधिक कठिन है।

और बाद में उसी स्रोत में (1980 ट्यूरिंग अवार्ड लेक्चर):

विश्वसनीयता की कीमत अत्यंत सरलता का पीछा है। यह एक कीमत है जो बहुत अमीर भुगतान करने के लिए सबसे कठिन पाते हैं।

Answer 6

यह हां या ना में कोई सवाल नहीं है। प्रश्न केवल रखरखाव में आसानी नहीं है, यह कौशल का एक कुशल उपयोग भी है।

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

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

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

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

Answer 7

नहीं । इसे बनाए रखना आसान नहीं है। अगर कुछ भी अधिक समस्याओं का स्वागत करते हैं।

क्यों?

• कार्यक्रम ओर्थोगोनल नहीं हैं, उन्हें एक दूसरे के काम को संरक्षित करने की आवश्यकता है जहां तक ​​उचित है, जो एक सामान्य समझ का अर्थ है।
• दोनों कार्यक्रमों के अधिकांश कोड समान हैं। क्या आप एक साझा साझा पुस्तकालय बनाए रख रहे हैं, या दो अलग-अलग प्रतियां बनाए हुए हैं?
• अब आपके पास दो विकास दल हैं। वे कैसे संवाद कर रहे हैं?

• अब आपके पास दो उत्पाद हैं जिनकी आवश्यकता है:

  • एक आम यूआई शैली, इंटरैक्शन मैकेनिज्म, आदि ... तो अब आपके पास डिजाइन की समस्याएं हैं। (देव टीम फिर से कैसे संवाद कर रहे हैं?)
  • पिछड़ी संगतता (modeller v1 को एनिमेटर v3 में आयात किया जा सकता है?)
  • क्लाउड / नेटवर्क एकीकरण (यदि इसकी एक विशेषता है) को अब कई उत्पादों के रूप में दो बार अपडेट किया जाना है।

• अब आपके पास तीन उपभोक्ता बाजार हैं: मोडेलर्स, एनिमेटर्स और मोडेलर एनिमेटर्स

  • उनकी परस्पर विरोधी प्राथमिकताएँ होंगी
  • उनके पास परस्पर विरोधी समर्थन की आवश्यकता होगी
  • उनके पास परस्पर विरोधी उपयोग शैलियाँ होंगी
• क्या मोडेलर एनिमेटर्स को एक ही फाइल पर काम करने के लिए दो अलग-अलग एप्लिकेशन खोलने पड़ते हैं? क्या दोनों कार्यों के साथ एक तीसरा अनुप्रयोग है, क्या एक आवेदन दूसरे के कार्यों को लोड करता है?
• आदि...

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

यदि ऑर्केस्ट्रेशन स्तर पर समस्या को हल करना सरल है, तो प्रत्येक आवेदन स्तर पर इसे हल करना तब यह दो कोड आधारों में विभाजित करने और ऑर्केस्ट्रेशन मुद्दों से निपटने के लिए समझ में आता है।

अन्यथा नहीं, बस ऐसा मत करो, आप आवेदन के आंतरिक प्रतिरूपकता में सुधार करके बेहतर सेवा करेंगे। कोड को अलग करने में आसान है और पुस्तकालयों को बनाए रखने के लिए आसान है कि आवेदन एक प्लगइन के रूप में कार्य करता है। सब के बाद एक अखंड सिर्फ एक पुस्तकालय परिदृश्य की आर्केस्ट्रा परत है।

Answer 8

बहुत सारे अच्छे जवाब थे, लेकिन चूंकि लगभग एक मृत विभाजन है, मैं अपनी टोपी को रिंग में भी फेंक दूंगा।

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

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

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

Comments

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

— पीटर बी

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

— CL40

और यह भी: एक बार संकलित किए गए एक अखंड आवेदन के रूप में क्या सामने आ सकता है, एक बहुत ही मॉड्यूलर अनुप्रयोग, कोड वार हो सकता है।

— पीटर बी

Answer 9

UI ऐप्स के लिए यह बग्स की समग्र मात्रा को कम करने की संभावना नहीं है, लेकिन संचार के कारण होने वाली समस्याओं की ओर बग मिश्रण का संतुलन बदल देगा।

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

यदि डेटा की इकाइयाँ जिस कार्यक्रम से संबंधित हैं, वे बड़ी हैं (यानी चित्र) तो किसी भी क्रॉस-प्रोसेस में देरी को समाप्त करने के लिए लंबा और कठिन होगा - "10mb छवि में परिवर्तन लागू करें" जैसा कुछ तुरंत डिस्क के 20+ डिस्क / नेटवर्क IO के अतिरिक्त होगा 2-इन-मेमोरी फॉर्मेट से सीरियलिज़ेबे प्रारूप और बैक में रूपांतरण। उपयोगकर्ता से ऐसा करने के लिए आवश्यक समय छिपाने के लिए वास्तव में बहुत कुछ नहीं है।

इसके अतिरिक्त किसी भी संचार और विशेष रूप से डिस्क IO एंटीवायरस / फ़ायरवॉल जांच के अधीन है - यह अनिवार्य रूप से कीड़े और यहां तक ​​कि अधिक देरी को दोहराने के लिए कठिन की एक और परत जोड़ता है।

स्प्लिट मोनोलिथिक "प्रोग्राम" चमकता है जहां संचार देरी महत्वपूर्ण या पहले से मौजूद नहीं है

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

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

Answer 10

क्या [यह] बग को रोकने में मदद करता है ?

रोकें? खैर, नहीं, वास्तव में नहीं।

• यह कीड़े का पता लगाने में मदद करता है ।
  नाममात्र के सभी कीड़े जिन्हें आप जानते भी नहीं थे, कि आपने केवल तभी खोज की थी जब आपने उस पूरी गंदगी को छोटे भागों में विभाजित करने का प्रयास किया था। तो, एक तरह से, इसने उन बगों को उत्पादन में अपनी उपस्थिति बनाने से रोक दिया - लेकिन कीड़े पहले से ही थे।
• यह बग के प्रभाव को कम करने में मदद करता है ।
  अखंड अनुप्रयोगों में कीड़े पूरी प्रणाली को नीचे लाने और उपयोगकर्ता को आपके आवेदन के साथ बातचीत करने से रोकते हैं। यदि आप उस एप्लिकेशन को घटकों में विभाजित करते हैं, तो अधिकांश बग डिजाइन होंगे - केवल एक घटक को प्रभावित करते हैं।
• यह नए बग के लिए एक परिदृश्य बनाता है ।
  यदि आप उपयोगकर्ता को समान अनुभव रखना चाहते हैं, तो आपको उन सभी घटकों के लिए संचार के लिए नए तर्क शामिल करने होंगे (REST सेवाओं के माध्यम से, OS सिस्टम कॉल के माध्यम से, आपके पास क्या है) ताकि वे उपयोगकर्ता के POV से निर्बाध रूप से संपर्क कर सकें।
  एक सरल उदाहरण के रूप में: आपका अखंड ऐप उपयोगकर्ताओं को ऐप छोड़ने के बिना एक मॉडल बनाने और उसे चेतन करने देता है। आप एप्लिकेशन को दो घटकों में विभाजित करते हैं: मॉडलिंग और एनीमेशन। अब आपके उपयोगकर्ताओं को मॉडलिंग ऐप के मॉडल को एक फ़ाइल में निर्यात करना है, फिर फ़ाइल ढूंढें और फिर इसे एनीमेशन ऐप के साथ खोलें ... आइए इसका सामना करते हैं, कुछ उपयोगकर्ता ऐसा नहीं करने वाले हैं, इसलिए आपको नए तर्क शामिल करने होंगे फ़ाइल और निर्यात करने के लिए मॉडलिंग ऐपस्वचालित रूप से एनीमेशन ऐप लॉन्च करें और इसे फ़ाइल खोलें। और यह नया तर्क, जितना सरल हो सकता है, डेटा क्रमांकन, फ़ाइल पहुंच और अनुमतियां, ऐप्स के इंस्टॉलेशन पथ को बदलने वाले उपयोगकर्ता आदि के बारे में कई बग हो सकते हैं।
• यह बहुत जरूरी रिफैक्टिंग लागू करने का सही बहाना है ।
  जब आप एक अखंड एप्लिकेशन को छोटे घटकों में विभाजित करने का निर्णय लेते हैं, तो आप (उम्मीद है) बहुत अधिक ज्ञान और अनुभव के साथ सिस्टम के बारे में ऐसा करते हैं जब यह पहली बार डिज़ाइन किया गया था, और इसके लिए धन्यवाद कि आप कोड बनाने के लिए कई रिफ्लेक्टर लगा सकते हैं क्लीनर, सरल, अधिक कुशल, अधिक लचीला, अधिक सुरक्षित। और यह रीफैक्टरिंग, एक तरह से बग्स को रोकने में मदद कर सकता है। बेशक, आप एक ही बग को रोकने के लिए मोनोलिथिक ऐप पर एक ही रिफैक्टरिंग लागू कर सकते हैं, लेकिन आप ऐसा नहीं करते हैं क्योंकि यह इतना अखंड है कि आप यूआई में कुछ भी छूने और व्यापार तर्क को तोड़ने से डरते हैं _ \ _ (ツ) _ / ¯

इसलिए मैं नहीं कहूंगा कि आप केवल एक अखंड ऐप को छोटे घटकों में तोड़कर बग्स को रोक रहे हैं, लेकिन आप वास्तव में एक ऐसे बिंदु पर पहुंचना आसान बना रहे हैं जिसमें बग्स को अधिक आसानी से रोका जा सकता है।