क्या कीड़े तकनीकी ऋण का हिस्सा हैं?

Question

हमारे स्क्रम मास्टर तकनीकी ऋण के रूप में बग का जिक्र करते रहते हैं। क्या वह सही है, एजाइल की दुनिया में बग को तकनीकी ऋण माना जाता है?

Comments

यह तय करना महत्वपूर्ण है कि क्या वे तकनीकी ऋण हैं या नहीं? क्या यह प्रभावित करेगा कि आप अपने स्क्रैम बोर्ड पर बग का प्रतिनिधित्व कैसे करते हैं, या प्रभावित करते हैं कि आप उन्हें कैसे ठीक करने की योजना बनाते हैं?

— ब्रायन ओकले

@BryanOakley कुछ कीड़े आपको इस तरह से अवरुद्ध कर सकते हैं जो आपको उनके आसपास काम करने के लिए मजबूर करता है, और भी अधिक तकनीकी ऋण पेश करता है। ये कीड़े ठीक करने के लिए बहुत महंगे हो सकते हैं

— B'ови

@BryanOkley - मैंने हमेशा सोचा था कि तकनीकी ऋण डिजाइन या रिफैक्टिंग था जिसे कार्यान्वयन में सुधार करने की आवश्यकता थी लेकिन वर्तमान समय / बजट की कमी के कारण संभव नहीं था। मुझे लगता है कि सही शब्दावली का उपयोग करना महत्वपूर्ण है। मैं गलत हो सकता हूं या वह गलत हो सकता है, यही वजह है कि मैंने सवाल पूछा।

— user86834

मैं समझता हूँ कि। उन्हें तकनीकी ऋण कहना महत्वपूर्ण क्यों है? क्या आप कह रहे हैं कि यदि आप उन्हें "तकनीकी ऋण" के रूप में वर्गीकृत करते हैं, तो आप उन बगों को अन्य बगों की तुलना में अलग तरह से मानेंगे?

— ब्रायन ओकले

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

— लुइस पेरेज

Answer 1

मुझे लगता है कि यहां उत्तर काफी सरल है - तकनीकी ऋण की प्रमुख विशेषता यह है कि इसका कुछ विकल्प हम पसंद करते हैं।

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

एक बग कुछ ऐसा नहीं है जिसे हम अपने कोड में चुनते हैं - इसलिए तकनीकी ऋण नहीं है।

बेशक कोई भी खोज के बाद के विकल्प के बारे में सभी प्रकार के दिलचस्प (और संभवतः मान्य) तर्क बना सकता है लेकिन मौलिक रूप से (और विशेष रूप से प्रश्न के संदर्भ में) नहीं, कीड़े तकनीकी ऋण नहीं हैं - मेरे लिए बुलबुल बिंगो के दुरुपयोग की तरह लगता है।

---

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

Comments

+1। मुझे लगता है कि B ,овић का जवाब बहुत सही है, लेकिन आपका जवाब वास्तव में सिर पर कील ठोकता है। (मैं थोड़ा अवधि के आपके उपयोग से उलझन में हूँ वास्तविक ।, हालांकि मुझे नहीं लगता कि आप कह जा सकता है कि है विधि सम्मत , एक बग है तकनीकी ऋण?)

— ruakh

भाषा का उपयोग इस तरह से मजेदार है ... यह कोशिश करें: en.wikipedia.org/wiki/De_facto - इसे "सभी इरादों और उद्देश्यों के लिए" के रूप में पढ़ें जो मेरे इरादे के काफी करीब है

— मर्फ़

"मुझे लगता है कि यहां उत्तर काफी सरल है - तकनीकी ऋण की प्रमुख विशेषता यह है कि इसका कुछ हम पसंद करते हैं।" आपने यह परिभाषा कहाँ से खींची? मुझे नहीं लगता कि यह सही है। यह तकनीकी ऋण का एक हिस्सा है, दूसरा हिस्सा निहित है और यह आमतौर पर अज्ञानता और बुरी प्रथाओं के कारण है।

— gphilip

दे जुरे दू जुरे। कल दे वास्तविक QED।

— राडारबॉब

मार्टिन फॉलर द्वारा तकनीकी ऋण चतुर्थांश के अनुसार आप बग्स और बुरे कोड को "लापरवाह अनजाने" ऋण: martinfowler.com/bliki/TechnicalDebtQuadrant.html के रूप में पहचान सकते हैं । मुझे लगता है कि बिंदु यह है कि यदि आप कुछ संवेदनशील बगों को कर्ज के रूप में चिह्नित करते हैं तो आप समझ सकते हैं कि वे आपको कितना खर्च करते हैं और आपको इसे खत्म करने की आवश्यकता है या नहीं। उदाहरण के लिए, क्या आपके पास मैला लिखा हुआ मॉड्यूल है जिसे केवल एक वर्ष में एक बार बदला जाता है और इसे फिर से लिखने के लिए सप्ताह लगेंगे - आपको शायद इसे रखना चाहिए क्योंकि यह इस ऋण पर ब्याज भुगतान बहुत छोटा है

— शेरशेन

Answer 2

हाँ।

तकनीकी ऋण (जिसे डिजाइन ऋण या कोड ऋण के रूप में भी जाना जाता है) एक कोडक के भीतर खराब या विकसित सॉफ्टवेयर वास्तुकला और सॉफ्टवेयर विकास के अंतिम परिणामों का जिक्र करते हुए एक नवशास्त्रीय रूपक है।

स्रोत: विकिपीडिया

तकनीकी ऋण को पढ़ें क्योंकि एक बेहतर वर्कफ़्लो होने से आप कुछ बचा सकते थे (उदाहरण के लिए कोडिंग में कूदने से पहले ठीक से आर्किटेक्चर करना, टीडीडी करना, आदि), बेहतर कोडिंग प्रैक्टिस आदि।

अधिकांश बग्स को अतिरिक्त समीक्षा या अधिक औपचारिक तरीकों के उपयोग से बचा जा सकता था। सब कुछ नहीं करने से आप पहली बार में कीड़े नहीं हो सकते हैं, आप परियोजना की तत्काल / अल्पकालिक लागत को कम करते हैं, लेकिन तकनीकी ऋण को बढ़ाते हैं।

---

BЈовић द्वारा उत्तर को पढ़ने के बाद , मैं देखता हूं कि यह उतना आसान नहीं है जितना मैंने सोचा था।

• उदाहरण के लिए क्या कीड़े तकनीकी ऋण का हिस्सा हैं? लेख का दावा है कि केवल बग के बारे में आप जानते हैं, लेकिन तय नहीं करना तकनीकी ऋण का हिस्सा है।

• एक और उदाहरण, तकनीकी ऋण पर क्रिस्टोफर के विचार तकनीकी ऋण के परिणाम के रूप में बग को योग्य बनाते हैं , इसका हिस्सा नहीं। यह कहा जा रहा है, "सूचीबद्ध नई सुविधा को लागू करने की लागत" जैसे कई सूचीबद्ध परिणाम, बग की संख्या से प्रभावित हैं।

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

यह कहा जा रहा है, मैं अभी भी जवाब देने के लिए इच्छुक हूं कि बग-कोई कीड़े- तकनीकी ऋण का हिस्सा हैं।

पहला तर्क:

जेफ एटवुड के उद्धरण को पढ़ते हुए, अधिकांश कीड़े इस प्रकार होंगे:

अतिरिक्त प्रयास जो हमें त्वरित और गंदे डिजाइन विकल्प के कारण भविष्य के विकास में करना है

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

दूसरा तर्क:

यदि हम किसी कंपनी के साधारण ऋण के बीच समानता रखते हैं जो किसी कंपनी को दूसरे को बेचा जाता है, और तकनीकी ऋण, जो किसी परियोजना को किसी अन्य कंपनी को बेचा जाता है या दिया जाता है, तो खाते में लेना भी उतना ही महत्वपूर्ण है। किसी अन्य टीम में, हम आसानी से देख सकते हैं कि बग तकनीकी ऋण का हिस्सा हैं, क्योंकि नई टीम:

• या तो नए फीचर्स बनाने से पहले उन बग्स से निपटना है (जोएल टेस्ट के पॉइंट 5: क्या आप नए कोड लिखने से पहले बग्स को ठीक करते हैं?)

• या इस तरह, तकनीकी ऋण को बनाए रखने / बढ़ाने के लिए बग को बनाए रखें।

Comments

मैं व्यक्तिगत रूप से तकनीकी ऋण के रूप में दोषों के बारे में नहीं सोचता, भले ही इस उत्तर में प्रस्तुत तर्क ध्वनि है, लेकिन क) यह वास्तव में कोई फर्क नहीं पड़ता कि हम तकनीकी ऋण आईएमओ को कैसे परिभाषित करते हैं, और ख) यह इस तरह का एक लिखित उत्तर है ' वैसे भी मैं मतदान कर रहा हूँ। +1!

— ब्रायन ओकले

Answer 3

अपने लेख में जेफ Atwood नीचे आपका तकनीकी ऋण भुगतान क्या तकनीकी कर्ज है पर काफी अच्छा जवाब देता है:

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

कड़ाई से बोलना, बग तकनीकी ऋण का हिस्सा नहीं हैं, अगर वे आगे सॉफ्टवेयर विकास (नई चीजों को जोड़ना, आदि) को धीमा नहीं करते हैं। वे सॉफ्टवेयर दोष हैं।

हालांकि, जब बग को ठीक करना बहुत महंगा होता है, या यह आपको इसके चारों ओर काम करने के लिए मजबूर करता है (और इससे भी अधिक तकनीकी ऋण का परिचय देता है), तो यह एक तकनीकी ऋण का हिस्सा बन जाता है।

Comments

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

— मार्जन वेनेमा

@MarjanVenema अच्छा बिंदु। मैंने ऐसा नहीं सोचा है।

— B46овиЈ

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

— ऊऊओ U

Answer 4

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

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

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

वार्ड कनिंघम और केपर्स जोन्स के साथ तकनीकी ऋण बहस

एक और लेख पढ़ने लायक है जो मार्टिन फॉलर ने दिया है

तकनीकी ऋण पर मार्टिन फाउलर

मार्टिन के लेख के भीतर, कृपया OOPSLA92 से वार्ड कनिंघम द्वारा तकनीकी ऋण के मूल उल्लेख का लिंक देखें:

व्याकैश पोर्टफोलियो मैनेजमेंट सिस्टम

उपरोक्त लेख का एक उद्धरण:

हालांकि अपरिपक्व कोड ठीक काम कर सकता है और ग्राहक के लिए पूरी तरह से स्वीकार्य हो सकता है , अतिरिक्त मात्रा एक प्रोग्राम को असम्बद्ध बना देगा, जिससे प्रोग्रामर के चरम विशेषज्ञता और अंत में एक अनम्य उत्पाद हो जाएगा। शिपिंग पहली बार कोड ऋण में जाने जैसा है।

अंत में, तकनीकी ऋण कुछ लोगों के लिए बग को शामिल करने के लिए आया हो सकता है, और मुझे लगता है कि यह ठीक है। मुझे नहीं लगता कि यह मूल इरादा था।

Comments

"सॉफ़्टवेयर को पहली बार में बग के साथ वितरित नहीं किया जाना चाहिए।" सभी सॉफ्टवेयर लेकिन बहुत सरल प्रोग्राम में बग होते हैं। आप इस बार को बहुत ऊंचा सेट करें।

— bhspencer

Answer 5

कड़े शब्दों में, आपके प्रश्न का उत्तर नहीं है।

तकनीकी ऋण (और शायद) बग को जन्म देगा, लेकिन यह निष्कर्ष निकालना कि कोई भी बग तकनीकी ऋण का परिणाम है, दो तथ्यों के बीच एक व्याख्या डाल रहा है: एक बग है और तकनीकी ऋण है (यह मानते हुए कि इसे तथ्य के रूप में निष्कर्ष निकाला जा सकता है)।

यदि आपका स्क्रम मास्टर 'एक सिद्धांत के रूप में' कह रहा है कि बग तकनीकी ऋण का परिणाम है, तो वह कोनों को काट रहा है। यदि वह विशिष्ट बगों के बारे में यह कह रहा है कि फिर से दिखाई देते रहें तो वह ठीक हो सकता है - हम यहां से कोड गुणवत्ता नहीं देख सकते हैं;;

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

Answer 6

मेरी राय में, यह वास्तव में कोई फर्क नहीं पड़ता कि आप कहते हैं कि बग तकनीकी ऋण का हिस्सा हैं ... या नहीं।

सादा तथ्य यह है कि मौजूदा कीड़े अतिरिक्त काम है कि प्रतिनिधित्व है हो सकता है उन्हें या उनके आसपास काम करने के लिए तय करने के लिए, भविष्य में प्रदर्शन किया जा करने की जरूरत है या तो।

तकनीकी ऋण (जैसा कि लेबल आमतौर पर उपयोग किया जाता है) भी अतिरिक्त काम का प्रतिनिधित्व करता है जिसे भविष्य में प्रदर्शन करने की आवश्यकता हो सकती है ... एक तरीका या दूसरा।

तो क्या आप जानते हैं कि (या अज्ञात) कीड़े तकनीकी ऋण हैं ... या नहीं ... वास्तव में परिभाषा की बात है। और चूंकि "तकनीकी ऋण" की कोई आधिकारिक परिभाषा ¹ नहीं है , इसलिए पूरी चर्चा व्यर्थ है।

जैसा कि लुईस कैरोल ने लिखा है:

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

यह वास्तव में प्राकृतिक भाषा कैसे काम करती है। शब्दों का मतलब है कि लोग क्या सोचते हैं। शब्दकोश की परिभाषाएं और इतने पर केवल उस तरीके से दस्तावेज़ करें जैसे कि शब्दों का उपयोग किया जाता है, और वे आवश्यक रूप से सटीक दस्तावेज नहीं हैं। यदि आपका स्क्रम मास्टर ज्ञात बग को तकनीकी ऋण के रूप में संदर्भित करना चाहता है, तो कौन कहता है कि वह "गलत" है?

---

^{1 - वार्ड कमिंघम और कापर जोन्स जैसे लोगों को उद्धृत करना भी मदद नहीं करता है। सबसे अच्छा यह बताता है कि जब वे वाक्यांश का उपयोग (उपयोग) करते हैं तो उनका क्या मतलब है (या मतलब)। वे वाक्यांश को "अपना" नहीं करते हैं। हालांकि वे इन मुद्दों पर निस्संदेह अधिकारी हैं, यह अभी भी उनकी राय है।}