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



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

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

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

इसलिए, आमतौर पर सबसे अच्छा विकल्प वह है जो हम आमतौर पर वित्तीय ऋणों के साथ करते हैं: धीरे-धीरे मूलधन का भुगतान करें। पहले समारोह में, मैं कुछ कचरे को हटाने के लिए कुछ दिनों का अतिरिक्त समय बिताऊंगा। यह ऋण पर ब्याज कम करने के लिए पर्याप्त हो सकता है, ताकि भविष्य में इसे एक दिन में चुकाया जा सके। यह अभी भी अतिरिक्त समय है, लेकिन कचरा हटाने के साथ, भविष्य के बदलाव सस्ते हो जाते हैं। वृद्धिशील सुधार का बड़ा लाभ यह है कि हम स्वाभाविक रूप से अक्सर बदलते क्षेत्रों में कचरा हटाने में अधिक समय व्यतीत करते हैं। ये ठीक कोड बेस के क्षेत्र हैं जो कचरा निपटान की सबसे अधिक आवश्यकता है।

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

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

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

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



विभिन्न प्रकार के कचरे को ऋण माना जाना चाहिए या नहीं, इस पर बहस नियमित रूप से होती है। मुझे ऐसा लगता है कि यहाँ इस बात पर विचार करना उपयोगी है कि क्या कर्तव्य जानबूझकर और यथोचित रूप से लिया गया है - या लापरवाही से। तो तकनीकी ऋण का एक वर्ग दिखाई दिया ।

आगे पढ़ रहे हैं

जहां तक ​​मैं बता सकता हूं, वार्ड ने पहली बार 1992 ओओपीएसएलए रिपोर्ट में इस अवधारणा को पेश किया था । विकी पर भी चर्चा हुई।

एक वीडियो रिकॉर्डिंग है जहां वार्ड कनिंघम अपने रूपक पर चर्चा करता है।

डेव निकोलेट ने तकनीकी ऋण के बारे में वार्ड के विचार का विस्तार किया है, जिसे मैं उचित जानबूझकर ऋण कहता हूं।

कई पाठकों ने अन्य वैध रूपकों का सुझाव दिया है। डेविड पैनारिटी ने कम गुणवत्ता वाले विकास को प्रोग्रामिंग की कमी कहा । जाहिर है, उन्होंने कई साल पहले इस शब्द का इस्तेमाल तब शुरू किया था जब यह सरकारी नीति के अनुरूप था; मुझे लगता है कि अब यह फिर से प्रासंगिक है।

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

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

हारून एरिकसन ने एनरॉन को वित्तपोषण करने के बारे में बात की।

हेनरिक नाइबर्ग का तर्क है कि पुराना तकनीकी ऋण सबसे बड़ी समस्या पैदा कर रहा है, और यह कि इसे प्रबंधित करने में आसान बनाने के लिए उच्च-गुणवत्ता वाले ऋण छत स्थापित करने की समझदारी है।

एरिक डिट्रिच तकनीकी ऋण के कारण मानव हानि पर चर्चा करता है : टीम की लड़ाई, कौशल क्षरण और बर्नआउट।

संपादन

यह पोस्ट मूल रूप से 1 अक्टूबर 2003 को प्रकाशित किया गया था। मैंने अप्रैल 2019 में इसे पूरी तरह से फिर से लिखा।