तकनीकी ऋण कोड के बीच का अंतर है कि वह कैसा है और कैसा होना चाहिए, तेजी से आगे बढ़ने के लिए लिया गया (जानबूझकर या नहीं)। कुछ ऋण ठीक है; काम इसे प्रबंधित करना है, इसे समाप्त करना नहीं। मुख्य बात यह है कि उस ऋण को प्राथमिकता दी जाए जो वास्तव में नुकसान पहुँचाता है।
यह क्यों महत्वपूर्ण है
For each piece of debt, ask:
- How often does it slow us down or cause bugs? (frequency)
- How bad is it when it bites? (severity)
- How risky/expensive is it to fix? (cost)
High frequency + high severity + low cost → fix now
Low frequency + low severity → leave it, document it
एक ठोस उदाहरण
एक नाजुक मॉड्यूल जो हर रिलीज़ पर टूटता है और टीम को साप्ताहिक रूप से ब्लॉक करता है, उसे ठीक करने योग्य है। एक कुरूप-लेकिन-स्थिर उपयोगिता जिसे कोई नहीं छूता है , भले ही यह आपको नाराज करे। इसे रीफ़ैक्टर करना बेकार है, मूल्य नहीं।
