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