विशाल अखंड आवेदन के खतरों


20

अब मैं एक दो साल से जिस बड़े प्रोजेक्ट पर काम कर रहा हूं, वह एक एडवांस डिवाइस का कंट्रोल (और सब कुछ) है, इसके फर्मवेयर का दिल।

डिवाइस काफी उन्नत है, जिसमें मैं मेमोरी से कह सकता हूं कि विभिन्न प्रकार की कार्यक्षमताएं हैं, और उनमें से 98% को इस एक विशाल निष्पादन योग्य द्वारा नियंत्रित किया जाता है। एक हाथ में, कार्यक्रम काफी रखरखाव योग्य है, अच्छी तरह से अंदर modularized है, ठीक से प्रलेखित है, निर्देशिका और फ़ाइलों और इसी तरह कार्यात्मकताओं का एक उचित पृथक्करण है।

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

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

एक हाथ में, यह काम करता है, और यह ठीक काम करता है। एकाधिक बायनेरिज़ के निर्माण को बनाए रखने के बिना प्रोजेक्ट अधिक सरल है। आंतरिक संरचना भी आसान है, जब आप बस एक विधि को कॉल कर सकते हैं या सॉकेट्स या साझा की गई मेमोरी पर बात करने के बजाय एक चर पढ़ सकते हैं।

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

मैंने किन अन्य खतरों की अनदेखी की? यह मुझे क्यों रेंगता है? क्या यह अज्ञात का सिर्फ तर्कहीन डर है? क्या गंभीर बड़ी परियोजनाओं को इस तरह से एक स्वीकृत अभ्यास बनाया जा रहा है? या तो मेरे डर को शांत करो या मुझे एक छोटे से द्विपदीय में संस्करण 2.0 को रीफैक्टर करने का अच्छा कारण दो।


7
यदि सूरज बहुत जल्दी उगता है, तो इंग्लैंड समुद्र में बह जाएगा।
मैक्समू

1
या पृथ्वी के कोर में दबाव थोड़ा बढ़ जाता है।
स्टुपरयूज़र

1
@Maxpm मैं देखता हूं कि आपने वहां क्या किया ... xkcd.com/687
tto

3
@Maxpm: सौभाग्य से, हमारा ऐप सूर्योदय और सूर्यास्त ड्राइव नहीं करता है। हमें विश्वास है कि राजकुमारी सेलेस्टिया अपनी नौकरी में असफल नहीं होगी।
एसएफ।

1
@rwong: 1. डिवाइस को अपग्रेड के लिए रोका गया है। हालांकि यह मक्खी पर अपडेट से बचेगा, हम नहीं चाहते कि किसी भी कारण से केस अपडेट में कोई अप्रत्याशित परिणाम गलत हो। 2. एम्बेडेड लिनक्स के साथ सिंगल-कोर ARM9। एक दूसरा, सीपीयू ओएस के बिना चल रहा है, मुख्य सीपीयू को सत्यापित करने से साने आउटपुट का उत्पादन होता है।
एसएफ।

जवाबों:


5

अंत में छोटी टिप्पणी को छोड़कर (दूसरा, सीपीयू की निगरानी) आप मेरी कंपनी का वर्णन कर सकते हैं। हाँ, हमें ईस्टर भी चाहिए।

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

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


धन्यवाद - कोई "सर्वोत्तम प्रथाओं का पालन / बलिदान" और "संभावित नुकसान बनाम संभावित नुकसान" प्रविष्टियां कभी भी उतनी ही मददगार होती हैं जितनी कि बाड़ के दूसरी तरफ से पहले अनुभव वाले व्यक्ति के रूप में सहायक होती हैं।
एसएफ।

23

डिवाइस काफी उन्नत है, जिसमें मैं मेमोरी से कह सकता हूं कि विभिन्न प्रकार की कार्यक्षमताएं हैं, और उनमें से 98% को इस एक विशाल निष्पादन योग्य द्वारा नियंत्रित किया जाता है। एक हाथ में, कार्यक्रम काफी रखरखाव योग्य है, अच्छी तरह से अंदर modularized है, ठीक से प्रलेखित है, निर्देशिका और फ़ाइलों और इसी तरह कार्यात्मकताओं का एक उचित पृथक्करण है।

आपने खुद कहा - यह काफी सुव्यवस्थित, अच्छी तरह से संशोधित है ...

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

हां, यह एक बड़ा कार्यक्रम है ... कई पहले भी रहा है। यह अच्छी तरह से प्रलेखित भी है, इसलिए आपको केवल इसके आंतरिक संगठन का अध्ययन करना है और आप इसमें तर्क देखेंगे। मुझे संदेह है कि आपके लिखे जाने से पहले वे सभी अक्षम थे। तो, इसे थोड़ा एक्सप्लोर करें, इसे जानें ... उसके बाद, इसे बनाए रखें क्योंकि यह फिर से लिखने के लिए एक ठोस कारण है जब तक कि यह पॉप न हो जाए। एक अच्छी लागत / प्रभाव अनुपात के लिए आपका प्रबंधक आपका आभारी रहेगा।

मैंने किन अन्य खतरों की अनदेखी की? यह मुझे क्यों रेंगता है? क्या यह अज्ञात का सिर्फ तर्कहीन डर है? क्या गंभीर बड़ी परियोजनाओं को इस तरह से एक स्वीकृत अभ्यास बनाया जा रहा है? या तो मेरे डर को शांत करो या मुझे एक छोटे से द्विपदीय में संस्करण 2.0 को रीफैक्टर करने का अच्छा कारण दो।

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

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


16

मुझे अच्छा लगेगा अगर आपने कहा कि आपके पास सब कुछ यूनिट परीक्षणों में लिपटा हुआ है। यदि आप नहीं करते हैं, तो आपको एप्लिकेशन को खोज करने के बारे में सोचने से पहले एक परीक्षण सूट का निर्माण करना चाहिए।

टेस्ट सूट होने से एप्लिकेशन की आपकी समझ में सुधार होगा, और यह आपको बताएगा कि आवेदन में बदलाव से कुछ टूट जाता है।


2
लेकिन यह दोनों संभव आर्किटेक्चर पर लागू होता है ...
एसएफ।

3
हाँ, यह करता है ...
रॉबर्ट हार्वे

10
... और इसलिए यह उत्तर इकाई परीक्षण को बढ़ावा देने के अलावा चर्चा में कुछ भी नहीं जोड़ता है।
बेन्जादो

2
@बेनज़ादो: ओपी के परिदृश्य में, जो सर्वोपरि है।
रॉबर्ट हार्वे

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

8

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

एम्बेडेड सिस्टम के लिए, आपकी एक प्रक्रिया आपके द्वारा बनाई जा रही सभी प्रक्रियाओं को चलाने के लिए O / S को लागू करने की आवश्यकता को समाप्त कर सकती है। आपको यह भी जाँचने के लिए एक प्रणाली लागू करने की आवश्यकता होगी कि सभी प्रक्रियाएँ जहाँ चल रही हैं, और यदि संभव हो तो उन्हें पुनः आरंभ करें। यदि यह संभव नहीं था, तो आपको तदनुसार प्रतिक्रिया करने की आवश्यकता होगी।

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

परीक्षण यहाँ एक लाल हेरिंग की तरह है, क्योंकि समस्याएँ अभी भी परीक्षण के साथ या बिना होंगी। डिजाइन की पसंद के साथ अच्छे परीक्षण को निश्चित रूप से प्रोत्साहित किया जाना चाहिए। मुझे उम्मीद है, अखंड संहिता के साथ परीक्षण सरल है।

एक दुर्घटना को मजबूर करना जब एक अखंड निष्पादन योग्य के साथ भी आसान होता है।


1
+1, इंजीनियरिंग ट्रेडऑफ़ के बारे में है, छोटे बायनेरिज़ की लागत भी है,
बेंजो

+1 मैं पूरे दिल से मानता हूँ। वारंट के कई निष्पादन के लिए कोई विशेष कारण नहीं दिया गया है। निष्पादनयोग्य के बीच संचार और समन्वय की कीमत है।
एरिक रॉबर्टसन

+1: यदि यह टूटा नहीं है, तो इसे ठीक न करें।
बॉब मर्फी

1

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

एक बार जो हो रहा है, परीक्षण एक बुरा सपना बन जाता है और आप अप्रचलन में सड़क पर अच्छी तरह से होते हैं।

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

आप जगह में अच्छा परीक्षण करना चाहते हैं, यद्यपि।


1

आदर्श रूप से, इसका उत्तर हां है। कई बायनेरिज़ होने से इसे और अधिक स्थिर बनाने की क्षमता है ...।

... हालाँकि, आपने यह भी उल्लेख किया है कि अखंड कोड आधार के भीतर कोड अच्छी तरह से लिखा और संशोधित किया गया है, जिसका अर्थ है कि एक विशाल पेचीदा गड़बड़ से निपटना, बस एक विशाल कोड आधार ...

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

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


1

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

यदि आप विभिन्न प्रक्रियाओं का उपयोग कर रहे हैं, तो आप कम से कम एक ही हीप या कॉल स्टैक का उपयोग नहीं कर रहे हैं, और एकल उपप्रकार को पुनरारंभ करना भी आसान हो सकता है।

आंतरिक संरचना भी आसान है, जब आप बस एक विधि को कॉल कर सकते हैं या सॉकेट्स या साझा की गई मेमोरी पर बात करने के बजाय एक चर पढ़ सकते हैं।

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

कहा जा रहा है कि यह एक कठिन काम है।

आप जो करना शुरू कर सकते हैं, वह तय करता है कि हर नए मॉड्यूल को एक अलग प्रक्रिया होनी चाहिए।


आप रनटाइम हार्डवेयर और OS वातावरण के बारे में एक बहुत कुछ मान रहे हैं, खासकर जब फ़िरवेयर और एम्बेडेड डिवाइस शामिल होते हैं।
पैट्रिक ह्यूजेस

0

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.