क्या एक सॉफ्टवेयर इंजीनियरिंग सिद्धांत है जो उत्पादन प्रणाली पर पुन: उपयोग और प्रतिगमन परीक्षण लागत से संबंधित है?

Question

मैंने एक बैंक के लिए एक बड़े वित्तीय लेनदेन प्रणाली पर काम किया है जो पेंशन और निवेश के बाद दिखता है। 15 साल के फीचर में बदलाव के बाद, मैनुअल रिग्रेशन टेस्ट की लागत 200K डॉलर प्रति रिलीज तक चढ़ गई थी। (10M LOC, $ 10M प्रति दिन लेनदेन)। यह प्रणाली 19 अन्य प्रणालियों के साथ इंटरफेस करती है, जो कंपनी के आसपास बहुत सारे डेटा को स्थानांतरित करती है। यह प्रणाली जावा में लागू की गई थी।

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

मेरा सवाल यह है कि एक सॉफ्टवेयर इंजीनियरिंग सिद्धांत है जो पुन: उपयोग और प्रतिगमन परीक्षण लागत के बीच संबंध का वर्णन करता है?

मैं यह प्रश्न पूछूंगा कारण यह है कि यकीनन सिस्टम को परीक्षण करने के लिए छोटे भागों में विघटित करने में लागत लाभ है।

मान्यताओं:

1. 'रिग्रेशन टेस्ट ’का अर्थ है test स्वीकृति परीक्षण’ - यानी पर्यावरण और डेटा सेटअप सहित व्यवसाय की ओर से सिस्टम के खिलाफ नए परीक्षण लिखने और पुराने परीक्षणों का पुन: उपयोग करने के लिए समय बिताने वाला दूसरा समूह।

2. मुझे पता है कि एक बड़े प्रतिगमन परीक्षण की लागत के लिए घुटने का झटका प्रतिक्रिया 'अधिक स्वचालित परीक्षण' है। यह एक अच्छा सिद्धांत है। इस माहौल में कुछ चुनौतियाँ हैं।

   (ए) स्वचालित परीक्षण सिस्टम सीमाओं के पार कम उपयोगी होते हैं, जब तक कि सिस्टम में उच्च स्वचालित परीक्षण कवरेज न हो। (प्रभाव चुनौती के क्षेत्र)।

   (b) जब आपका सिस्टम पहले से ही बड़ा और जटिल है, तो उच्च स्वचालित परीक्षण कवरेज पर प्रोग्रामर के समय या पूंजी निवेश पर गति प्राप्त करना सांस्कृतिक रूप से कठिन है।

   (c) स्वचालित परीक्षणों को बनाए रखने की लागत एक परियोजना पर छिपी हुई है, और इसलिए उन्हें परियोजना स्तर पर आसानी से छोड़ दिया जाता है।

   (d) यह बैंक में काम करने की सांस्कृतिक सच्चाई है।

   (e) मैं इस समस्या को एक अलग तरीके से हल करने के लिए काम कर रहा हूँ (अपघटन)।

Comments

आप हाथ से लहराने वाला बयान देते हैं कि " हम [...] देखते हैं कि हम जितना अधिक 'पुन: उपयोग' करते हैं, उतनी ही अधिक [स्वीकृति] परीक्षण लागत बढ़ती है " - क्या आप उस पर विस्तार कर सकते हैं? उदाहरण के लिए, उदाहरण के लिए, अनुवर्ती पदानुक्रमों जैसे कार्यान्वयन विवरणों का एक स्वीकृति परीक्षण अज्ञेय नहीं होना चाहिए, और इसके बजाय उपयोग परिदृश्यों के माध्यम से खेलना चाहिए?

— आमोन

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

— डॉक ब्राउन

धन्यवाद जो सहायक है। मैंने OO के संदर्भ हटा दिए हैं - और साझा कोड को छूने के विचार पर विस्तार किया है, (या कोड जो साझा कोड बन जाएगा)।

— हॉकआई

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

— Doc Brown

Answer 1

हम उस कोड को संशोधित नहीं करना चाहते हैं जिसे साझा किया जा सकता है, क्योंकि यह एक बड़ा प्रतिगमन परीक्षण प्रभाव पैदा करेगा

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

चूंकि आपका सिस्टम जावा में कार्यान्वित किया गया है, आप जावा मानक पुस्तकालयों (JDK) में, वहाँ ऊपर के लिए एक उदाहरण देख सकते हैं। इसके प्रमुख रिलीज़ अनारक्षित हैं, और बहुत ही प्रयास खपत परीक्षण के साथ हैं। और यहां तक ​​कि मामूली रिलीज भी regressions की अनुपस्थिति को सत्यापित करने के लिए बहुत व्यापक जेसीके टेस्ट सूट के माध्यम से चलती है ।

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

आदर्श रूप से, व्यापक रूप से साझा किए गए कोड के रिलीज की गुणवत्ता ऐसी होनी चाहिए कि इसमें बड़े बदलावों की जरूरत न हो (बचत बढ़ाने के लिए)। विचार की यह रेखा जोशुआ बलोच के एक प्रसिद्ध उद्धरण में परिलक्षित होती है :

सार्वजनिक एपीआई, हीरे की तरह, हमेशा के लिए हैं। आपके पास इसे पाने का एक मौका है इसलिए इसे अपना सर्वश्रेष्ठ दें।

---

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

केवल इन दो विकल्पों तक सीमित करना अनावश्यक है और, फिर से, आप इस उदाहरण को पा सकते हैं कि आपके द्वारा उपयोग किए जाने वाले जेडीके में यह कैसे बेहतर किया जा सकता है। java.util.concurrentपैकेज ( JSR 166 ) पर एक नज़र डालें - जावा 5 रिलीज़ होने तक, ये एक अलग लाइब्रेरी थे, कोर JDK रिलीज़ का हिस्सा नहीं थे।

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

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

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

---

कितना प्रयास (परीक्षण सहित) भारी पुन: उपयोग किए गए कोड को शामिल करने में शामिल हो सकता है, का एक ठोस उदाहरण, फिर से, JDK में पाया जा सकता है। रिलीज़ 7u6 में उन्होंने आंतरिक Stringप्रतिनिधित्व को बदल दिया जिसमें substringप्रदर्शन में बदलाव शामिल था । Reddit के फीचर डेवलपर की टिप्पणियां इस बदलाव में कितना प्रयास शामिल थीं:

प्रारंभिक विश्लेषण 2007 में जीसी समूह से बाहर आया था ...

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

मेरा जवाब संपूर्ण होने का इरादा नहीं है, लेकिन लगभग छह महीने के समर्पित कार्य का एक संक्षिप्त सारांश है ...

Comments

लगता है कि हम दोनों ने समान विचारों के साथ समानांतर में एक उत्तर पर काम किया ...

— डॉक्टर ब्राउन ने

@DocBrown हाँ, यह दिलचस्प है कि हमने लगभग एक साथ उत्तर दिया, प्रश्न के आकार में संपादित होने के लगभग एक घंटे बाद

— gnat

Answer 2

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

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

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

• वे घटक बहुत परिपक्व और स्थिर होते हैं

• वे पूरी तरह से अलग संगठन द्वारा विकसित और पूरी तरह से अलगाव में परीक्षण किए जाते हैं

• (पुनः) उनका उपयोग करें, आपको उन्हें बदलना नहीं है (वास्तव में आप चाहकर भी ऐसा नहीं कर सकते, क्योंकि आप स्रोत कोड को बनाए नहीं रखते हैं)

• आपको दैनिक नया संस्करण नहीं मिलता है, केवल मामूली अपडेट (प्रति माह अधिकतम), या प्रति वर्ष अंतराल में प्रमुख अपडेट

• अधिकांश अपडेट को 100% नीचे की ओर संगत, विशेष रूप से मामूली अपडेट के लिए डिज़ाइन किया गया है

तो अपने स्वयं के पुन: प्रयोज्य घटकों को और अधिक सफल बनाने के लिए, आपको अपने स्वयं के विकास के लिए ऊपर की कुछ चीजों को अनुकूलित करना चाहिए:

• किसी भी पुन: प्रयोज्य घटक के लिए, एक स्पष्ट ज़िम्मेदारी है जो रखरखाव करता है और यह सुनिश्चित करता है कि घटक का पुन: उपयोग करने वाले सभी लोग समस्या उत्पन्न होने पर तुरंत बगफिक्स प्राप्त करना सुनिश्चित कर सकें।

• एक सख्त संस्करण स्थापित करना और नीतियां जारी करना। एक पुन: प्रयोज्य घटक को विकसित करते समय, इसे "हर किसी को" हर दिन जारी न करें (कम से कम, ऐसा नहीं है कि इसका मतलब सिस्टम पर पूर्ण $ 200K प्रतिगमन परीक्षण चलाने के लिए होगा)। इसके बजाय, नए संस्करणों को केवल समय-समय पर प्रकाशित किया जाए, और उस घटक के उपयोगकर्ता को नए संस्करण में परिवर्तन को स्थगित करने के लिए तंत्र प्रदान करें।

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

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

इन चीजों का बहुत मतलब होगा कि घटक के निर्माण की लागत में वृद्धि होगी, लेकिन यह विफल शासन के कारण होने वाले परिवर्तनों की लागत को भी कम करेगा।

Answer 3

जबकि अधिक परीक्षण की आवश्यकता के कारण लागत में "अवलोकन योग्य" वृद्धि हो सकती है, उस प्रकार के रीफ़ैक्टरिंग आमतौर पर भविष्य में कोड को अधिक बनाए रखने योग्य बनाते हैं क्योंकि आप सिस्टम में तकनीकी ऋण को कम कर रहे हैं।

इससे भविष्य के बगों को कम करना चाहिए, और मौजूदा सुविधाओं को लागू करने के लिए नई सुविधाओं या परिवर्तनों को आसान बनाना चाहिए।

आसान से मेरा मतलब है कि उन्हें कम समय लेना चाहिए और इसलिए कम खर्च करना चाहिए।

कम, आसान और कम सभी बल्कि यहाँ पर अस्पष्ट शब्द हैं और भविष्य की किसी भी बचत (या बचत के लिए आशा की गई) की गणना करना असंभव है क्योंकि यह अभी तक नहीं हुआ है।

एक सरल कोड आधार को नए कर्मचारियों, या मौजूदा कर्मचारियों को परियोजना की ओर बढ़ने की अनुमति देनी चाहिए, विशेषकर बड़े सिस्टम के लिए।

यह कर्मचारियों के टर्नओवर को कम कर सकता है जिससे मौजूदा परियोजना सदस्यों का मनोबल बेहतर हो सके।

यह निश्चित रूप से गारंटी नहीं है कि आप इन लाभों को प्राप्त करेंगे, लेकिन ये ऐसी चीजें हैं जिन्हें लागतों के साथ माना जाना चाहिए (जैसे परीक्षण में वृद्धि) जिसे मापा जा सकता है।

वास्तव में, बेहतर कोड को अंततः समय के साथ परीक्षण की लागत को कम करना चाहिए, भले ही आप जो भी वर्णन करते हैं उसके कारण प्रारंभिक वृद्धि हो।