तकनीकी ऋण: Difference between revisions
From Vigyanwiki
(Created page with "{{short description|Software development concept}} सॉफ्टवेयर विकास में, तकनीकी ऋण (डिजाइन ऋण के रूप...") |
No edit summary |
||
| Line 1: | Line 1: | ||
{{short description|Software development concept}} | {{short description|Software development concept}} | ||
सॉफ़्टवेयर विकास में '''तकनीकी ऋण''' (डिज़ाइन ऋण या कोड ऋण के रूप में भी जाना जाता है<ref name="Girish 2014">{{cite book|last1=Suryanarayana|first1=Girish|title=सॉफ्टवेयर डिजाइन गंध के लिए रिफैक्टरिंग|date=November 2014|publisher=Morgan Kaufmann|isbn=978-0128013977|pages=258|edition=1st}}</ref> एक बेहतर दृष्टिकोण के अतिरिक्त एक आसान लेकिन सीमित समाधान का चयन करते समय आवश्यक भावी पुनर्विक्रय की निहित लागत है जिसमें अधिक समय लग सकता है।<ref>{{cite web|url=https://www.techopedia.com/definition/27913/technical-debt|website=Techopedia|title="तकनीकी ऋण" शब्द की परिभाषा (प्लस, कुछ पृष्ठभूमि की जानकारी और एक "स्पष्टीकरण")|access-date=August 11, 2016}} </ref> | |||
मौद्रिक ऋण के अनुरूप यदि तकनीकी ऋण का भुगतान नहीं किया जाता है<ref name="Managing_Technical_Debt">{{cite journal|last1=Allman|first1=Eric|title=तकनीकी ऋण का प्रबंधन|journal=Communications of the ACM|date=May 2012|volume=55|issue=5|pages=50–55|doi=10.1145/2160718.2160733|s2cid=53246391 }}</ref>, तो यह "ब्याज" जमा कर सकता है, जिससे परिवर्तनों को लागू करना कठिन हो जाता है। अनएड्रेस्ड टेक्निकल डेट [[सॉफ्टवेयर एन्ट्रापी]] और आगे के रीवर्क की लागत को बढ़ाता है। इसी तरह मौद्रिक ऋण के लिए, तकनीकी ऋण एक बुरी चीज नहीं है, और कभी-कभी (उदाहरण के लिए अवधारणा के प्रमाण के रूप में) परियोजनाओं को आगे बढ़ाने की आवश्यकता होती है। दूसरी ओर, कुछ विशेषज्ञों का दावा है कि "तकनीकी ऋण" रूपक प्रभाव को कम करता है, जिसके परिणामस्वरूप इसे ठीक करने के लिए आवश्यक कार्य की अपर्याप्त प्राथमिकता होती है।<ref name="Knesek 2016">{{cite web| last=Knesek|first=Doug|access-date=April 7, 2016|url=https://www.linkedin.com/pulse/averting-technical-debt-crisis-part-1-doug-knesek|title=Averting a 'Technical Debt' Crisis}}</ref><ref><nowiki><ref> = जेफरीज़ 2015></nowiki>{{cite web| last=Jeffries|first=Ron|access-date=November 10, 2015|url=http://ronjeffries.com/articles/015-11/tech-debt/|archive-url=https://web.archive.org/web/20151111011323/http://ronjeffries.com/articles/015-11/tech-debt/|archive-date=November 11, 2015 |title=तकनीकी ऋण – बुरा रूपक या सबसे बुरा रूपक?}}<nowiki></ref></nowiki></ref> | |||
जैसे ही एक कोडबेस पर बदलाव शुरू किया जाता है, कोडबेस या दस्तावेज़ीकरण के अन्य भागों में प्रायः अन्य समन्वित परिवर्तन करने की आवश्यकता होती है। आवश्यक परिवर्तन जो पूरे नहीं हुए हैं, उन्हें ऋण माना जाता है, और जब तक भुगतान नहीं किया जाता है, तब तक ब्याज के ऊपर ब्याज लगेगा, जिससे परियोजना का निर्माण बोझिल हो जाएगा। हालाँकि यह शब्द मुख्य रूप से सॉफ्टवेयर विकास में उपयोग किया जाता है, इसे अन्य व्यवसायों पर भी लागू किया जा सकता है। | |||
2016 में आयोजित एक डगस्टुहल संगोष्ठी में, तकनीकी ऋण को विषय के अकादमिक और औद्योगिक विशेषज्ञों द्वारा निम्नानुसार परिभाषित किया गया था: "सॉफ्टवेयर-गहन प्रणालियों में, तकनीकी ऋण डिजाइन या कार्यान्वयन निर्माणों का एक संग्रह है जो अल्पावधि में समीचीन है, लेकिन निर्धारित है एक तकनीकी संदर्भ जो भविष्य के परिवर्तनों को अधिक महंगा या असंभव बना सकता है। तकनीकी ऋण एक वास्तविक या आकस्मिक दायित्व प्रस्तुत करता है जिसका प्रभाव आंतरिक प्रणाली गुणों, मुख्य रूप से संरक्षण और अस्थिरता तक सीमित है।<ref>{{cite journal |last1=Avgeriou |first1=Paris |last2=Kruchten |first2=Philippe |last3=Ozkaya |first3=Ipek |last4=Carolyn |first4=Seaman |title=Managing technical debt in software engineering (dagstuhl seminar 16162) |journal=Dagstuhl reports |date=2016 |volume=6 |issue=4 | url=https://drops.dagstuhl.de/opus/volltexte/2016/6693/pdf/dagrep_v006_i004_p110_s16162.pdf#page=3}}</ref> | |||
== कारण == | == कारण == | ||
{{more references needed section|date=October 2022}} | {{more references needed section|date=October 2022}} | ||
तकनीकी ऋण के सामान्य कारणों में | तकनीकी ऋण के सामान्य कारणों में सम्मिलित हैं: | ||
* चल रहे विकास, समय के साथ परियोजना संवर्द्धन की लंबी श्रृंखला पुराने समाधानों को उप-इष्टतम बना देती है। | * चल रहे विकास, समय के साथ परियोजना संवर्द्धन की लंबी श्रृंखला पुराने समाधानों को उप-इष्टतम बना देती है। | ||
* अपर्याप्त अप-फ्रंट परिभाषा, जहां विकास के दौरान आवश्यकताओं | * अपर्याप्त अप-फ्रंट परिभाषा, जहां विकास के दौरान आवश्यकताओं को अभी भी परिभाषित किया जा रहा है, किसी भी डिजाइन के होने से पहले विकास शुरू हो जाता है। यह समय बचाने के लिए किया जाता है लेकिन प्रायः बाद में इसे फिर से काम करना पड़ता है। | ||
* व्यावसायिक दबाव, | * व्यावसायिक दबाव, जहां आवश्यक परिवर्तन पूर्ण होने से पहले व्यवसाय जल्द ही कुछ जारी करने पर विचार करता है, उन अधूरे परिवर्तनों को सम्मिलित करते हुए तकनीकी ऋण का निर्माण करता है।{{r|SuryanarayanaSamarthyam2014|p=4}}{{r|Sterling2010|p=22}} | ||
* प्रक्रिया या समझ का अभाव, जहां व्यवसाय तकनीकी ऋण की अवधारणा के प्रति अंधे होते हैं, और निहितार्थों पर विचार किए बिना निर्णय लेते हैं। | * प्रक्रिया या समझ का अभाव, जहां व्यवसाय तकनीकी ऋण की अवधारणा के प्रति अंधे होते हैं, और निहितार्थों पर विचार किए बिना निर्णय लेते हैं। | ||
* [[ युग्मन (कंप्यूटर प्रोग्रामिंग) ]], जहां कार्य [[मॉड्यूलर प्रोग्रामिंग]] नहीं हैं, सॉफ्टवेयर इतना लचीला नहीं है कि वह व्यावसायिक जरूरतों में बदलाव के अनुकूल हो सके। | * [[ युग्मन (कंप्यूटर प्रोग्रामिंग) ]], जहां कार्य [[मॉड्यूलर प्रोग्रामिंग]] नहीं हैं, सॉफ्टवेयर इतना लचीला नहीं है कि वह व्यावसायिक जरूरतों में बदलाव के अनुकूल हो सके। | ||
| Line 36: | Line 36: | ||
|page = 155 | |page = 155 | ||
|isbn = 978-0-13-704329-3}}</ref> | |isbn = 978-0-13-704329-3}}</ref> | ||
* हुआ-तकनीकी ऋण-ऋण कि विकास दल अनजान था जब तक कि उत्पाद पर काम करने के सामान्य | * हुआ-तकनीकी ऋण-ऋण कि विकास दल अनजान था जब तक कि उत्पाद पर काम करने के सामान्य पाठ्यक्रम के दौरान इसका खुलासा नहीं हुआ। उदाहरण के लिए, टीम उत्पाद में एक नई सुविधा जोड़ रही है और ऐसा करने पर यह महसूस होता है कि किसी ऐसे व्यक्ति द्वारा कोड वर्षों पहले वर्क-अराउंड बनाया गया था जो लंबे समय से विदा हो चुका है। | ||
* ज्ञात तकनीकी ऋण—ऋण जो विकास दल को ज्ञात है और कई दृष्टिकोणों में से एक का उपयोग करके दृश्यमान बनाया गया है। | * ज्ञात तकनीकी ऋण—ऋण जो विकास दल को ज्ञात है और कई दृष्टिकोणों में से एक का उपयोग करके दृश्यमान बनाया गया है। | ||
* लक्षित तकनीकी ऋण—ऋण जो ज्ञात है और विकास दल द्वारा सर्विसिंग के लिए लक्षित किया गया है। | * लक्षित तकनीकी ऋण—ऋण जो ज्ञात है और विकास दल द्वारा सर्विसिंग के लिए लक्षित किया गया है। | ||
== परिणाम == | == परिणाम == | ||
"ब्याज भुगतान" आवश्यक स्थानीय संरक्षण और परियोजना के अन्य उपयोगकर्ताओं द्वारा संरक्षण की अनुपस्थिति दोनों के कारण होता है। अपस्ट्रीम परियोजना में चल रहे विकास से भविष्य में "ऋण चुकाने" की लागत बढ़ सकती है।{{Clarify|Which upstream project?|date=October 2013}} केवल अपूर्ण कार्य को पूरा करके ऋण का भुगतान किया जा सकता है।{{Citation needed|date=May 2018}} | |||
तकनीकी ऋण का निर्माण परियोजनाओं की समय सीमा से चूकने का एक प्रमुख कारण है।{{Citation needed|date=April 2013}} यह अनुमान लगाना मुश्किल है कि ऋण का भुगतान करने के लिए कितना काम आवश्यक है। प्रत्येक परिवर्तन के लिए जो शुरू किया गया है, परियोजना के लिए अपूर्ण कार्य की अनिश्चित राशि प्रतिबद्ध है। समय सीमा समाप्त हो जाती है जब परियोजना को पता चलता है कि इसे पूरा करने के लिए समय की तुलना में अधिक अपूर्ण कार्य (ऋण) है। पूर्वानुमेय रिलीज शेड्यूल के लिए एक विकास टीम को अपूर्ण की मात्रा को बनाए रखने के लिए कार्य की मात्रा को सीमित करना चाहिए। काम (या कर्ज) हर समय छोटा।{{Citation needed|date=May 2018}} | |||
यदि एक परियोजना पर पर्याप्त काम पूरा हो जाता है जो प्रस्तुत करने में बाधा उत्पन्न नहीं करता है, तो एक परियोजना जारी की जाएगी जो अभी भी पर्याप्त मात्रा में तकनीकी ऋण वहन करती है। यदि यह सॉफ्टवेयर उत्पादन तक पहुंचता है, तो तकनीकी ऋण को संबोधित करने वाले किसी भी भविष्य के रिफ्लेक्टर को लागू करने का जोखिम नाटकीय रूप से बढ़ जाता है। यदि अनुबंधों में सेवा-स्तरीय समझौते (SLA) सम्मिलित हैं, तो उत्पादन कोड को संशोधित करने से आउटेज, वास्तविक वित्तीय नुकसान और संभवतः कानूनी नतीजों का जोखिम होता है। इस कारण से हम तकनीकी ऋण को उत्पादन तक ले जाने को लगभग इस तरह देख सकते हैं जैसे कि यह ब्याज दर में वृद्धि थी और केवल एक बार यह घटता है जब तैनाती को ठुकरा दिया जाता है और सेवानिवृत्त कर दिया जाता है। | |||
{{quotation |"एक विकसित कार्यक्रम के रूप में लगातार परिवर्तन होता रहता है, इसकी जटिलता, बिगड़ती संरचना को दर्शाती है, जब तक इसे बनाए रखने या कम करने के लिए काम नहीं किया जाता है।"<ref>{{cite journal|last1=Lehman|first1=MM|title=Laws of Software Evolution Revisited|journal=EWSPT '96 Proceedings of the 5th European Workshop on Software Process Technology|date=1996|pages=108–124|isbn=9783540617716 |url=http://dl.acm.org/citation.cfm?id=681473|access-date=19 November 2014}}</ref> |[[मीर मैनी लेहमन]], 1980}} | |||
जबकि [[ मीर मैनी लेहमन |मीर मैनी लेहमन]] के कानून ने पहले ही संकेत दिया था कि विकसित कार्यक्रम लगातार उनकी जटिलता और बिगड़ती संरचना को जोड़ते हैं जब तक कि उन्हें बनाए रखने के लिए काम नहीं किया जाता है, [[वार्ड कनिंघम]] ने पहली बार 1992 की अनुभव रिपोर्ट में तकनीकी जटिलता और ऋण के बीच तुलना की: | |||
{{quotation |"शिपिंग पहली बार कोड कर्ज में जाने जैसा है। एक छोटा सा ऋण विकास को तब तक गति देता है जब तक इसे पुनर्लेखन के साथ तुरंत वापस भुगतान किया जाता है... खतरा तब होता है जब ऋण चुकाया नहीं जाता है। बिल्कुल सही नहीं कोड पर बिताया गया प्रत्येक मिनट उस ऋण पर [[ब्याज]] के रूप में गिना जाता है। संपूर्ण इंजीनियरिंग संगठनों को एक असमेकित कार्यान्वयन, [[ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग|ऑब्जेक्ट-ओरिएंटेड]] के ऋण भार के तहत स्थिर किया जा सकता है या अन्यथा "<ref name='oopsla92'>{{cite web|url=http://c2.com/doc/oopsla92.html|title=The WyCash Portfolio Management System|date=1992-03-26|access-date=2008-09-26|author=Ward Cunningham|author-link=Ward Cunningham}}</ref> |[[वार्ड कनिंघम]], 1992}} | |||
अपने 2004 के पाठ में, रिफैक्टरिंग टू पैटर्न्स, [[जोशुआ केरिवेस्की]] वास्तु लापरवाही से जुड़ी लागतों के संबंध में एक तुलनीय तर्क प्रस्तुत करता है, जिसे वह "डिजाइन ऋण" के रूप में वर्णित करता है।<ref name="rtp">{{cite book|isbn=978-0-321-21335-8|first=Joshua|last=Kerievsky|title=पैटर्न के लिए रिफैक्टरिंग|year=2004}}</ref> | |||
जिन गतिविधियों को स्थगित किया जा सकता है उनमें दस्तावेज़ीकरण, [[ परीक्षण स्वचालन |परीक्षण स्वचालन]], टीओडीओ टिप्पणियों पर ध्यान देना और संकलक और स्थैतिक कोड विश्लेषण चेतावनियों से निपटना सम्मिलित है। तकनीकी ऋण के अन्य उदाहरणों में ज्ञान सम्मिलित है जो संगठन के आसपास साझा नहीं किया जाता है और कोड जो आसानी से संशोधित करने के लिए बहुत भ्रामक है।{{Citation needed|date=May 2018}} | |||
जिन गतिविधियों को स्थगित किया जा सकता है उनमें | |||
2014 में PHP के विकास के बारे में लिखते हुए, [[जुनादे अली]] ने कहा: | 2014 में PHP के विकास के बारे में लिखते हुए, [[जुनादे अली]] ने कहा: | ||
{{quotation| | {{quotation|इस तकनीकी ऋण को कभी न चुकाने की कीमत स्पष्ट है; अंततः कार्यक्षमता प्रदान करने की लागत इतनी धीमी हो जाएगी कि एक अच्छी तरह से डिज़ाइन किए गए प्रतिस्पर्धी सॉफ़्टवेयर उत्पाद के लिए सुविधाओं के मामले में खराब डिज़ाइन किए गए सॉफ़्टवेयर से आगे निकलना आसान हो जाएगा। मेरे अनुभव में, खराब तरीके से डिज़ाइन किया गया सॉफ़्टवेयर भी एक अधिक तनावग्रस्त इंजीनियरिंग कार्यबल का कारण बन सकता है, जिसके परिणामस्वरूप उच्च कर्मचारी मंथन होता है (जो सुविधाओं को वितरित करते समय लागत और उत्पादकता को प्रभावित करता है)। इसके अतिरिक्त, किसी दिए गए कोडबेस में जटिलता के कारण कार्य का सटीक अनुमान लगाने की क्षमता भी गायब हो जाएगी। ऐसे मामलों में जहां विकास एजेंसियां फीचर-टू-फीचर के आधार पर चार्ज करती हैं, कोड डिलीवर करने के लिए लाभ मार्जिन अंततः खराब हो जाएगा।|[[जुनादे अली]] writes in ''Mastering PHP Design Patterns''<ref>{{cite book|last1=Ali|first1=Junade|title=Mastering PHP Design Patterns {{!}} PACKT Books|date=September 2016|publisher=Packt Publishing Limited|location=Birmingham, England, UK|isbn=978-1-78588-713-0|page=11|edition=1|url=https://www.packtpub.com/application-development/mastering-php-design-patterns|access-date=11 December 2017|language=en}}</ref>}} | ||
[[ग्रेडी बूच]] ने तुलना की है कि कैसे विकसित होते शहर सॉफ्टवेयर-गहन प्रणालियों के विकास के समान हैं और रिफैक्टरिंग की कमी कैसे तकनीकी ऋण का कारण बन सकती है। | [[ग्रेडी बूच]] ने तुलना की है कि कैसे विकसित होते शहर सॉफ्टवेयर-गहन प्रणालियों के विकास के समान हैं और रिफैक्टरिंग की कमी कैसे तकनीकी ऋण का कारण बन सकती है। | ||
| Line 64: | Line 64: | ||
{{quotation |"The concept of technical debt is central to understanding the forces that weigh upon systems, for it often explains where, how, and why a system is stressed. In cities, repairs on infrastructure are often delayed and incremental changes are made rather than bold ones. So it is again in software-intensive systems. Users suffer the consequences of capricious complexity, delayed improvements, and insufficient incremental change; the developers who evolve such systems suffer the slings and arrows of never being able to write quality code because they are always trying to catch up."<ref name="Girish 2014"/> |[[Grady Booch]], 2014}} | {{quotation |"The concept of technical debt is central to understanding the forces that weigh upon systems, for it often explains where, how, and why a system is stressed. In cities, repairs on infrastructure are often delayed and incremental changes are made rather than bold ones. So it is again in software-intensive systems. Users suffer the consequences of capricious complexity, delayed improvements, and insufficient incremental change; the developers who evolve such systems suffer the slings and arrows of never being able to write quality code because they are always trying to catch up."<ref name="Girish 2014"/> |[[Grady Booch]], 2014}} | ||
ओपन सोर्स सॉफ़्टवेयर में, अपस्ट्रीम प्रोजेक्ट में स्थानीय परिवर्तन भेजना स्थगित करना तकनीकी ऋण का एक रूप है।{{Citation needed|date=May 2018}} | |||
== यह भी देखें == | == यह भी देखें == | ||
* [[कोड गंध]] (अवर कोड गुणवत्ता के लक्षण जो तकनीकी ऋण में योगदान दे सकते | * [[कोड गंध]] (अवर कोड गुणवत्ता के लक्षण जो तकनीकी ऋण में योगदान दे सकते हैं।) | ||
* [[मिट्टी का बड़ा गोला]] | * [[मिट्टी का बड़ा गोला]] | ||
* [[बस कारक]] | * [[बस कारक]] | ||
| Line 75: | Line 75: | ||
* [[शॉटगन सर्जरी]] | * [[शॉटगन सर्जरी]] | ||
* सॉफ्टवेयर एन्ट्रापी | * सॉफ्टवेयर एन्ट्रापी | ||
* [[सॉफ्टवेयर सड़ांध]] | * [[सॉफ्टवेयर सड़ांध|सॉफ्टवेयर अपक्षय]] | ||
* [[स्पेगेटी कोड]] | * [[स्पेगेटी कोड]] | ||
* [[ शुरू ]] | * [[ शुरू |स्केल]] | ||
* [[विफल लागत]] | * [[विफल लागत]] | ||
* | * टीओडीओ, फिक्समे, एक्सएक्सएक्स (प्रोग्रामिंग भाषा) | ||
==संदर्भ== | ==संदर्भ== | ||
Revision as of 23:58, 16 May 2023
सॉफ़्टवेयर विकास में तकनीकी ऋण (डिज़ाइन ऋण या कोड ऋण के रूप में भी जाना जाता है[1] एक बेहतर दृष्टिकोण के अतिरिक्त एक आसान लेकिन सीमित समाधान का चयन करते समय आवश्यक भावी पुनर्विक्रय की निहित लागत है जिसमें अधिक समय लग सकता है।[2]
मौद्रिक ऋण के अनुरूप यदि तकनीकी ऋण का भुगतान नहीं किया जाता है[3], तो यह "ब्याज" जमा कर सकता है, जिससे परिवर्तनों को लागू करना कठिन हो जाता है। अनएड्रेस्ड टेक्निकल डेट सॉफ्टवेयर एन्ट्रापी और आगे के रीवर्क की लागत को बढ़ाता है। इसी तरह मौद्रिक ऋण के लिए, तकनीकी ऋण एक बुरी चीज नहीं है, और कभी-कभी (उदाहरण के लिए अवधारणा के प्रमाण के रूप में) परियोजनाओं को आगे बढ़ाने की आवश्यकता होती है। दूसरी ओर, कुछ विशेषज्ञों का दावा है कि "तकनीकी ऋण" रूपक प्रभाव को कम करता है, जिसके परिणामस्वरूप इसे ठीक करने के लिए आवश्यक कार्य की अपर्याप्त प्राथमिकता होती है।[4][5]</nowiki></ref>
जैसे ही एक कोडबेस पर बदलाव शुरू किया जाता है, कोडबेस या दस्तावेज़ीकरण के अन्य भागों में प्रायः अन्य समन्वित परिवर्तन करने की आवश्यकता होती है। आवश्यक परिवर्तन जो पूरे नहीं हुए हैं, उन्हें ऋण माना जाता है, और जब तक भुगतान नहीं किया जाता है, तब तक ब्याज के ऊपर ब्याज लगेगा, जिससे परियोजना का निर्माण बोझिल हो जाएगा। हालाँकि यह शब्द मुख्य रूप से सॉफ्टवेयर विकास में उपयोग किया जाता है, इसे अन्य व्यवसायों पर भी लागू किया जा सकता है।
2016 में आयोजित एक डगस्टुहल संगोष्ठी में, तकनीकी ऋण को विषय के अकादमिक और औद्योगिक विशेषज्ञों द्वारा निम्नानुसार परिभाषित किया गया था: "सॉफ्टवेयर-गहन प्रणालियों में, तकनीकी ऋण डिजाइन या कार्यान्वयन निर्माणों का एक संग्रह है जो अल्पावधि में समीचीन है, लेकिन निर्धारित है एक तकनीकी संदर्भ जो भविष्य के परिवर्तनों को अधिक महंगा या असंभव बना सकता है। तकनीकी ऋण एक वास्तविक या आकस्मिक दायित्व प्रस्तुत करता है जिसका प्रभाव आंतरिक प्रणाली गुणों, मुख्य रूप से संरक्षण और अस्थिरता तक सीमित है।[6]
कारण
Template:More references needed section तकनीकी ऋण के सामान्य कारणों में सम्मिलित हैं:
- चल रहे विकास, समय के साथ परियोजना संवर्द्धन की लंबी श्रृंखला पुराने समाधानों को उप-इष्टतम बना देती है।
- अपर्याप्त अप-फ्रंट परिभाषा, जहां विकास के दौरान आवश्यकताओं को अभी भी परिभाषित किया जा रहा है, किसी भी डिजाइन के होने से पहले विकास शुरू हो जाता है। यह समय बचाने के लिए किया जाता है लेकिन प्रायः बाद में इसे फिर से काम करना पड़ता है।
- व्यावसायिक दबाव, जहां आवश्यक परिवर्तन पूर्ण होने से पहले व्यवसाय जल्द ही कुछ जारी करने पर विचार करता है, उन अधूरे परिवर्तनों को सम्मिलित करते हुए तकनीकी ऋण का निर्माण करता है।[7]: 4 [8]: 22
- प्रक्रिया या समझ का अभाव, जहां व्यवसाय तकनीकी ऋण की अवधारणा के प्रति अंधे होते हैं, और निहितार्थों पर विचार किए बिना निर्णय लेते हैं।
- युग्मन (कंप्यूटर प्रोग्रामिंग) , जहां कार्य मॉड्यूलर प्रोग्रामिंग नहीं हैं, सॉफ्टवेयर इतना लचीला नहीं है कि वह व्यावसायिक जरूरतों में बदलाव के अनुकूल हो सके।
- एक परीक्षण सूट का अभाव, जो त्वरित और जोखिम भरा बैंड-ऐड (कम्प्यूटिंग) | बैंड-ऐड बग फिक्स को प्रोत्साहित करता है।
- सॉफ़्टवेयर दस्तावेज़ों का अभाव, जहाँ दस्तावेज़ों का समर्थन किए बिना कोड बनाया जाता है। दस्तावेज़ बनाने का कार्य ऋण का प्रतिनिधित्व करता है।[7]
- सहयोग का अभाव, जहां ज्ञान को संगठन के आसपास साझा नहीं किया जाता है और व्यावसायिक दक्षता प्रभावित होती है, या जूनियर डेवलपर्स को ठीक से सलाह नहीं दी जाती है।
- एक स्रोत आधार में परिवर्तनों को मर्ज करने के लिए आवश्यक कार्य के कारण कई शाखाओं पर समानांतर विकास तकनीकी ऋण अर्जित करता है। अलगाव में जितने अधिक परिवर्तन किए जाते हैं, उतना अधिक ऋण।
- आस्थगित कोड रीफैक्टरिंग; जैसे-जैसे किसी परियोजना के लिए आवश्यकताएँ विकसित होती हैं, यह स्पष्ट हो सकता है कि कोड के भाग अक्षम या संपादित करने में कठिन हो गए हैं और भविष्य की आवश्यकताओं का समर्थन करने के लिए उन्हें फिर से तैयार किया जाना चाहिए। जितनी लंबी रिफैक्टरिंग में देरी होगी, और जितना अधिक कोड जोड़ा जाएगा, उतना ही बड़ा कर्ज होगा।[8]: 29
- मानकों के संरेखण की कमी, जहां उद्योग मानक सुविधाओं, सॉफ्टवेयर ढांचे और प्रौद्योगिकियों की अनदेखी की जाती है। आखिरकार मानकों के साथ एकीकरण आ जाएगा और ऐसा करने में जल्द ही कम खर्च आएगा (विलंबित रीफैक्टरिंग के समान)।[7]: 7
- ज्ञान की कमी, जब डेवलपर को यह नहीं पता होता है कि सुरुचिपूर्ण कोड कैसे लिखना है।[8]
- स्वामित्व की कमी, जब आउटसोर्स किए गए सॉफ़्टवेयर प्रयासों के परिणामस्वरूप इन-हाउस इंजीनियरिंग को कोड रिफैक्टरिंग या कोड पुनर्लेखन आउटसोर्स कोड की आवश्यकता होती है।
- खराब तकनीकी नेतृत्व, जहां खराब तरीके से सोची गई कमानों को कमान की शृंखला सौंपी जाती है।
- अंतिम मिनट विनिर्देश परिवर्तन। इनमें एक परियोजना के दौरान रिसने की क्षमता है, लेकिन परिवर्तनों का दस्तावेजीकरण और परीक्षण करने के लिए अपर्याप्त समय या बजट है।
सेवा या तकनीकी ऋण चुकाना
केनी रुबिन निम्नलिखित स्थिति श्रेणियों का उपयोग करता है:[9]
- हुआ-तकनीकी ऋण-ऋण कि विकास दल अनजान था जब तक कि उत्पाद पर काम करने के सामान्य पाठ्यक्रम के दौरान इसका खुलासा नहीं हुआ। उदाहरण के लिए, टीम उत्पाद में एक नई सुविधा जोड़ रही है और ऐसा करने पर यह महसूस होता है कि किसी ऐसे व्यक्ति द्वारा कोड वर्षों पहले वर्क-अराउंड बनाया गया था जो लंबे समय से विदा हो चुका है।
- ज्ञात तकनीकी ऋण—ऋण जो विकास दल को ज्ञात है और कई दृष्टिकोणों में से एक का उपयोग करके दृश्यमान बनाया गया है।
- लक्षित तकनीकी ऋण—ऋण जो ज्ञात है और विकास दल द्वारा सर्विसिंग के लिए लक्षित किया गया है।
परिणाम
"ब्याज भुगतान" आवश्यक स्थानीय संरक्षण और परियोजना के अन्य उपयोगकर्ताओं द्वारा संरक्षण की अनुपस्थिति दोनों के कारण होता है। अपस्ट्रीम परियोजना में चल रहे विकास से भविष्य में "ऋण चुकाने" की लागत बढ़ सकती है।[clarification needed] केवल अपूर्ण कार्य को पूरा करके ऋण का भुगतान किया जा सकता है।[citation needed]
तकनीकी ऋण का निर्माण परियोजनाओं की समय सीमा से चूकने का एक प्रमुख कारण है।[citation needed] यह अनुमान लगाना मुश्किल है कि ऋण का भुगतान करने के लिए कितना काम आवश्यक है। प्रत्येक परिवर्तन के लिए जो शुरू किया गया है, परियोजना के लिए अपूर्ण कार्य की अनिश्चित राशि प्रतिबद्ध है। समय सीमा समाप्त हो जाती है जब परियोजना को पता चलता है कि इसे पूरा करने के लिए समय की तुलना में अधिक अपूर्ण कार्य (ऋण) है। पूर्वानुमेय रिलीज शेड्यूल के लिए एक विकास टीम को अपूर्ण की मात्रा को बनाए रखने के लिए कार्य की मात्रा को सीमित करना चाहिए। काम (या कर्ज) हर समय छोटा।[citation needed]
यदि एक परियोजना पर पर्याप्त काम पूरा हो जाता है जो प्रस्तुत करने में बाधा उत्पन्न नहीं करता है, तो एक परियोजना जारी की जाएगी जो अभी भी पर्याप्त मात्रा में तकनीकी ऋण वहन करती है। यदि यह सॉफ्टवेयर उत्पादन तक पहुंचता है, तो तकनीकी ऋण को संबोधित करने वाले किसी भी भविष्य के रिफ्लेक्टर को लागू करने का जोखिम नाटकीय रूप से बढ़ जाता है। यदि अनुबंधों में सेवा-स्तरीय समझौते (SLA) सम्मिलित हैं, तो उत्पादन कोड को संशोधित करने से आउटेज, वास्तविक वित्तीय नुकसान और संभवतः कानूनी नतीजों का जोखिम होता है। इस कारण से हम तकनीकी ऋण को उत्पादन तक ले जाने को लगभग इस तरह देख सकते हैं जैसे कि यह ब्याज दर में वृद्धि थी और केवल एक बार यह घटता है जब तैनाती को ठुकरा दिया जाता है और सेवानिवृत्त कर दिया जाता है।
"एक विकसित कार्यक्रम के रूप में लगातार परिवर्तन होता रहता है, इसकी जटिलता, बिगड़ती संरचना को दर्शाती है, जब तक इसे बनाए रखने या कम करने के लिए काम नहीं किया जाता है।"[10]
— मीर मैनी लेहमन, 1980
जबकि मीर मैनी लेहमन के कानून ने पहले ही संकेत दिया था कि विकसित कार्यक्रम लगातार उनकी जटिलता और बिगड़ती संरचना को जोड़ते हैं जब तक कि उन्हें बनाए रखने के लिए काम नहीं किया जाता है, वार्ड कनिंघम ने पहली बार 1992 की अनुभव रिपोर्ट में तकनीकी जटिलता और ऋण के बीच तुलना की:
"शिपिंग पहली बार कोड कर्ज में जाने जैसा है। एक छोटा सा ऋण विकास को तब तक गति देता है जब तक इसे पुनर्लेखन के साथ तुरंत वापस भुगतान किया जाता है... खतरा तब होता है जब ऋण चुकाया नहीं जाता है। बिल्कुल सही नहीं कोड पर बिताया गया प्रत्येक मिनट उस ऋण पर ब्याज के रूप में गिना जाता है। संपूर्ण इंजीनियरिंग संगठनों को एक असमेकित कार्यान्वयन, ऑब्जेक्ट-ओरिएंटेड के ऋण भार के तहत स्थिर किया जा सकता है या अन्यथा "[11]
— वार्ड कनिंघम, 1992
अपने 2004 के पाठ में, रिफैक्टरिंग टू पैटर्न्स, जोशुआ केरिवेस्की वास्तु लापरवाही से जुड़ी लागतों के संबंध में एक तुलनीय तर्क प्रस्तुत करता है, जिसे वह "डिजाइन ऋण" के रूप में वर्णित करता है।[12]
जिन गतिविधियों को स्थगित किया जा सकता है उनमें दस्तावेज़ीकरण, परीक्षण स्वचालन, टीओडीओ टिप्पणियों पर ध्यान देना और संकलक और स्थैतिक कोड विश्लेषण चेतावनियों से निपटना सम्मिलित है। तकनीकी ऋण के अन्य उदाहरणों में ज्ञान सम्मिलित है जो संगठन के आसपास साझा नहीं किया जाता है और कोड जो आसानी से संशोधित करने के लिए बहुत भ्रामक है।[citation needed]
2014 में PHP के विकास के बारे में लिखते हुए, जुनादे अली ने कहा:
इस तकनीकी ऋण को कभी न चुकाने की कीमत स्पष्ट है; अंततः कार्यक्षमता प्रदान करने की लागत इतनी धीमी हो जाएगी कि एक अच्छी तरह से डिज़ाइन किए गए प्रतिस्पर्धी सॉफ़्टवेयर उत्पाद के लिए सुविधाओं के मामले में खराब डिज़ाइन किए गए सॉफ़्टवेयर से आगे निकलना आसान हो जाएगा। मेरे अनुभव में, खराब तरीके से डिज़ाइन किया गया सॉफ़्टवेयर भी एक अधिक तनावग्रस्त इंजीनियरिंग कार्यबल का कारण बन सकता है, जिसके परिणामस्वरूप उच्च कर्मचारी मंथन होता है (जो सुविधाओं को वितरित करते समय लागत और उत्पादकता को प्रभावित करता है)। इसके अतिरिक्त, किसी दिए गए कोडबेस में जटिलता के कारण कार्य का सटीक अनुमान लगाने की क्षमता भी गायब हो जाएगी। ऐसे मामलों में जहां विकास एजेंसियां फीचर-टू-फीचर के आधार पर चार्ज करती हैं, कोड डिलीवर करने के लिए लाभ मार्जिन अंततः खराब हो जाएगा।
— जुनादे अली writes in Mastering PHP Design Patterns[13]
ग्रेडी बूच ने तुलना की है कि कैसे विकसित होते शहर सॉफ्टवेयर-गहन प्रणालियों के विकास के समान हैं और रिफैक्टरिंग की कमी कैसे तकनीकी ऋण का कारण बन सकती है।
"The concept of technical debt is central to understanding the forces that weigh upon systems, for it often explains where, how, and why a system is stressed. In cities, repairs on infrastructure are often delayed and incremental changes are made rather than bold ones. So it is again in software-intensive systems. Users suffer the consequences of capricious complexity, delayed improvements, and insufficient incremental change; the developers who evolve such systems suffer the slings and arrows of never being able to write quality code because they are always trying to catch up."[1]
— Grady Booch, 2014
ओपन सोर्स सॉफ़्टवेयर में, अपस्ट्रीम प्रोजेक्ट में स्थानीय परिवर्तन भेजना स्थगित करना तकनीकी ऋण का एक रूप है।[citation needed]
यह भी देखें
- कोड गंध (अवर कोड गुणवत्ता के लक्षण जो तकनीकी ऋण में योगदान दे सकते हैं।)
- मिट्टी का बड़ा गोला
- बस कारक
- प्रतिबद्धता की वृद्धि
- मनुवाद
- अति अभियांत्रिकी
- शॉटगन सर्जरी
- सॉफ्टवेयर एन्ट्रापी
- सॉफ्टवेयर अपक्षय
- स्पेगेटी कोड
- स्केल
- विफल लागत
- टीओडीओ, फिक्समे, एक्सएक्सएक्स (प्रोग्रामिंग भाषा)
संदर्भ
- ↑ 1.0 1.1 Suryanarayana, Girish (November 2014). सॉफ्टवेयर डिजाइन गंध के लिए रिफैक्टरिंग (1st ed.). Morgan Kaufmann. p. 258. ISBN 978-0128013977.
- ↑ ""तकनीकी ऋण" शब्द की परिभाषा (प्लस, कुछ पृष्ठभूमि की जानकारी और एक "स्पष्टीकरण")". Techopedia. Retrieved August 11, 2016.
- ↑ Allman, Eric (May 2012). "तकनीकी ऋण का प्रबंधन". Communications of the ACM. 55 (5): 50–55. doi:10.1145/2160718.2160733. S2CID 53246391.
- ↑ Knesek, Doug. "Averting a 'Technical Debt' Crisis". Retrieved April 7, 2016.
- ↑ <ref> = जेफरीज़ 2015>Jeffries, Ron. "तकनीकी ऋण – बुरा रूपक या सबसे बुरा रूपक?". Archived from the original on November 11, 2015. Retrieved November 10, 2015.<nowiki>
- ↑ Avgeriou, Paris; Kruchten, Philippe; Ozkaya, Ipek; Carolyn, Seaman (2016). "Managing technical debt in software engineering (dagstuhl seminar 16162)" (PDF). Dagstuhl reports. 6 (4).
- ↑ 7.0 7.1 7.2 Girish Suryanarayana; Ganesh Samarthyam; Tushar Sharma (11 November 2014). Refactoring for Software Design Smells: Managing Technical Debt. Elsevier Science. p. 3. ISBN 978-0-12-801646-6.
- ↑ 8.0 8.1 8.2 Chris Sterling (10 December 2010). Managing Software Debt: Building for Inevitable Change (Adobe Reader). Addison-Wesley Professional. p. 17. ISBN 978-0-321-70055-1.
- ↑ Rubin, Kenneth (2013), Essential Scrum. A Practical Guide to the Most Popular Agile Process (in English), Addison-Wesley, p. 155, ISBN 978-0-13-704329-3
- ↑ Lehman, MM (1996). "Laws of Software Evolution Revisited". EWSPT '96 Proceedings of the 5th European Workshop on Software Process Technology: 108–124. ISBN 9783540617716. Retrieved 19 November 2014.
- ↑ Ward Cunningham (1992-03-26). "The WyCash Portfolio Management System". Retrieved 2008-09-26.
- ↑ Kerievsky, Joshua (2004). पैटर्न के लिए रिफैक्टरिंग. ISBN 978-0-321-21335-8.
- ↑ Ali, Junade (September 2016). Mastering PHP Design Patterns | PACKT Books (in English) (1 ed.). Birmingham, England, UK: Packt Publishing Limited. p. 11. ISBN 978-1-78588-713-0. Retrieved 11 December 2017.
बाहरी संबंध
- Ward Explains Debt Metaphor, video from Ward Cunningham
- OnTechnicalDebt The online community for discussing technical debt
- Experts interviews on Technical Debt: Ward Cunningham, Philippe KRUCHTEN, Ipek OZKAYA, Jean-Louis LETOUZEY
- Steve McConnell discusses technical debt
- TechnicalDebt from Martin Fowler Bliki
- Averting a "Technical Debt" Crisis by Doug Knesek
- "Get out of Technical Debt Now!", a talk by Andy Lester
- Lehman's Law
- Managing Technical Debt Webinar by Steve McConnell
- Boundy, David, Software cancer: the seven early warning signs or here, ACM SIGSOFT Software Engineering Notes, Vol. 18 No. 2 (April 1993), Association for Computing Machinery, New York, New York, US
- Technical debt: investeer en voorkom faillissement by Colin Spoel
- Technical debts: Everything you need to know
- What is technical debt? from DeepSource blog
