क्या कोई सबूत है कि निर्भरता इंजेक्शन के उपयोग से सॉफ्टवेयर इंजीनियरिंग में परिणाम बेहतर होते हैं?

Question

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

Comments

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

— डॉक ब्राउन

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

— डॉक ब्राउन

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

— रॉबर्ट हार्वे

@DocBrown ईमानदारी से, मैं इसे न तो डुप्लिकेट के रूप में देखता हूं, न ही ऑफ-टॉपिक के रूप में, खुद के रूप में। विकास अभ्यास की औचित्य और प्रभावकारिता एसईएसई के लिए बहुत प्रासंगिक लगती है। और, मैं एक उत्तर देने जा रहा हूं। ओपी शायद मेरे जवाब को पसंद नहीं करेगा ... लेकिन, मुझे लगता है कि यह एक वस्तुनिष्ठ उत्तर (लगभग उत्तर) के लायक है कि क्या टीपीओ और पीएम अपनी टीमों की उत्पादकता को जादुई रूप से देखने की उम्मीद कर सकते हैं (या उनकी बग दरों में गिरावट) जैसे ही कोई चिल्लाता है "निर्भरता इंजेक्शन।"

— svidgen

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

— svidgen

Answer 1

TLDR

अनुभवजन्य डेटा अप्रासंगिक है। उपकरण और अभ्यास (जैसे DI) विशेष समस्याओं को हल करते हैं। अपनी समस्याओं को समझें, टूल का उपयोग करना सीखें, और यह तब स्पष्ट हो जाएगा जब कोई टूल मूल्यवान होगा - और आप परिणामों को किसी भी सामान्यीकृत, एकत्रित, आनुभविक डेटा की तुलना में अधिक स्पष्ट रूप से समझा पाएंगे।

---

और अब, बहुत अधिक वाचालता के साथ ...

क्या अनुभवजन्य साक्ष्य है?

ज़रूर, शायद। या कम से कम हो सकता है। लेकिन कौन परवाह करता है? यह प्रासंगिक नहीं है।

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

तो, हम कैसे जानते हैं कि डिपेंडेंसी इंजेक्शन बिल्कुल मूल्यवान है ?

अच्छा प्रश्न! महान सवाल, वास्तव में। और मैं आपके साथ हूं - मैं हठधर्मिता "सर्वोत्तम प्रथाओं" पर समय और मानसिक प्रयास को बर्बाद करने से नफरत करता हूं जिसे कोई भी उचित नहीं ठहरा सकता। इसलिए, मुझे खुशी है कि आपने पूछा।

उह। लेकिन, यहाँ शर्मनाक समस्या है ... सामान्य शब्दों में, आप नहीं जानते। और, इससे भी अधिक शर्मनाक, आपका कोड वास्तव में DI को शुरू करने से किसी भी तरह से बेहतर नहीं हो सकता है।

---

दम तोड़ देना!

    ⊙▃⊙     . . .      (╯°□°)╯︵ ┻━┻

...

---

तो, शायद अब आप सोच रहे हैं ...

मुझे परेशान क्यों होना चाहिए 'मुक्केबाज़ी की चीजें साबित नहीं हुईं हैं नथिन!'

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

... जिससे मेरा मतलब है, सिद्धांत लागू करने का सिद्धांत :

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

आपको यह समझने की आवश्यकता है कि आप जो कर रहे हैं वह क्यों कर रहे हैं!

(पीओएपी पीओएपी से छूट नहीं है।)

^{(मैं कहूंगा, "मेरा जोर," लेकिन यह मेरे अपने "ब्लॉग" से वैसे भी है। तो, यह सब मेरा है!)}

मुझे वहां मुख्य बिंदु को दोहराना चाहिए: आपको यह समझने की आवश्यकता है कि आप जो कर रहे हैं वह क्यों कर रहे हैं।

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

यदि डि की असहायता या संयुक्त राष्ट्र या कम से कम अपने तर्क शक्तियों से परे - - आप के लिए -helpfulness स्पष्ट नहीं है कि आप या तो डि समझ में नहीं आता, या आप अपने स्वयं की समस्याओं को नहीं समझते।

---

आइए एक वास्तविक दुनिया पर विचार करें "दृष्टांत।"

हमें एक बॉक्स बनाने की जरूरत है। हमारे पास लकड़ी है। हमारे पास नाखून हैं। और, हमारे पास दो उपकरण हैं: एक मानक पंजा हथौड़ा और एक पेचकश ।

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

और, यदि आपने कभी किसी को पहले किसी उपकरण का उपयोग करते देखा है, और यदि आप समझते हैं कि एक बॉक्स कैसा दिखता है, तो निर्णय स्पष्ट है।

टेलिकिनेज़ीस!

त्रुटि ... हम्म ...

---

हाँ-तो, निर्भरता इंजेक्शन क्या समस्या हल करता है?

यह कठोर, बिना-विन्यास वाले कोड को रोकने के लिए काम करता है, जो अक्सर इसलिए अन- टेस्टेबल होता है ।

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

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

इसलिए, निर्भरता इंजेक्शन के लिए ईर्ष्या धर्मयुद्ध ...

के। लेकिन, मैं ठीक-ठीक तर्क दे सकता हूं। चौखटे क्यों ?

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

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

लेकिन, मैं आपको Google को प्रोत्साहित करूंगा , हो सकता है कि यह SO उत्तर देखें , संभवतः आपके उद्योग में एक सुपर-अनुभवी और सफल डेवलपर से बात करें, और सीआरएसई के लिए विशिष्ट उदाहरण पोस्ट करें ।

Comments

क्या आप @ CandiedOrange के गोंद में से कुछ सूँघ रहे हैं? एप्लाइड प्रयोजनों के सिद्धांत के लिए +1।

— रॉबर्ट हार्वे

@RobertHarvey काश मैं नया कह सकता था कि हम किस गोंद के बारे में बात कर रहे थे! मैं विश्वास-आधारित इंजीनियरिंग के खिलाफ एक लंबे समय तक प्रतिशोध था ... जब तक आप कथा का उल्लेख कर रहे हैं - संभवतः यह भी - पद की प्रकृति?

— svidgen

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

— svidgen

@RobertHarvey यकीन नहीं है कि आप मेरी कई झलकियों में से एक का उल्लेख कर रहे हैं, लेकिन मैं खुद को इस के हर शब्द से सहमत हूं। जब आप शिकंजा पर इसका उपयोग करते हैं तो एक हथौड़ा चूसना आसान है।

— कैंडिड_ऑरेंज

विशेष रूप से DI के बारे में अधिक विवरण शामिल करने और शीर्ष पर TLDR को बुलबुले बनाने के लिए संपादन शुरू किया। और फिर बच्चों ने उपद्रव करना शुरू कर दिया, इसलिए मैंने सेव को मारा। ... अगर मैं अनजाने में आपके द्वारा किए गए (जो उन लोगों के लिए) का सार खो दिया है, तो कृपया मुझे बताएं!

— svidgen

Answer 2

मैंने Google, Google विद्वान, ACM, और IEEE को खोजा यहां ऐसे पेपर थे जिन्हें मैं खोजने में सक्षम था:

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

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

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

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

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

Comments

यह सीधे सवाल का जवाब देता है। +1

— मैथ्यू जेम्स ब्रिग्स

@MatthewJamesBriggs मैं नीच आदमी नहीं हूँ, लेकिन, सवाल का सीधा जवाब देने से क्या यह जवाब भ्रामक या अधूरा है ???

— svidgen

@svidgen मैं यह नहीं देखता कि उत्तर कैसे अधूरा है। सवाल था "क्या हमारे पास अनुभवजन्य साक्ष्य हैं जो DI काम करता है?" और जवाब नहीं है।" यह इस बारे में कुछ नहीं कहता है कि यह काम करता है या नहीं, बस इस पर कोई शोध नहीं है।

— होवरकॉच

अधूरा और भ्रामक है कि आप उत्तर दे रहे हैं कि "साक्ष्य" के दायरे को "कागज़ों" पर ले जाएँ, जिसे आप (sic) डीआई के वास्तविक उद्देश्यों के बिना "प्रभावशीलता" के लिए खोज रहे हैं और "प्रभावशीलता" पर कंबल कर रहे हैं, और जो आपके पास है इसलिए निष्कर्ष निकाला गया कि उत्तर योग्यता के बिना "नहीं" है ... मैं तर्क दूंगा कि, यदि आप "सीधे" सवाल का जवाब देने जा रहे हैं, जैसा कि @MatthewJamesBriggs ने आपको बताया है, आपके पास गहरी खुदाई करने और होने के लिए एक भारी खतरा है उच्च निश्चितता के साथ प्रदर्शित करने में सक्षम है कि आपने सभी रास्ते खोज लिए हैं ...

— svidgen

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

— svidgen