क्या किसी को पता है कि कोड बेस के एक प्रकार के कोड के तकनीकी ऋण पर नंबर डालने के लिए किसी प्रकार का टूल है या नहीं? यदि नहीं, तो क्या किसी को एल्गोरिथ्म या इसके लिए हेयुरेटिक्स के सेट के बारे में पता है?
यदि उनमें से कोई भी चीज़ अभी तक मौजूद नहीं है, तो मुझे इस तरह की चीज़ के साथ शुरुआत करने के लिए विचारों में दिलचस्पी होगी। अर्थात्, मैं एक विधि, एक वर्ग, एक नाम, एक विधानसभा, आदि द्वारा किए गए तकनीकी ऋण को कैसे निर्धारित कर सकता हूं।
मुझे C # कोड आधार का विश्लेषण करने और उसका आकलन करने में सबसे अधिक दिलचस्पी है, लेकिन कृपया अन्य भाषाओं के लिए भी झिझक महसूस करें, खासकर अगर अवधारणा भाषा पारगमन हो।
12
तकनीकी ऋण निर्णयों से आता है, न कि कोड से। यह खराब प्रबंधन विकल्पों के कारण अर्जित होता है। यह स्पष्ट नहीं है कि "विधि, एक वर्ग, एक नाम स्थान, एक विधानसभा" में तकनीकी ऋण शामिल हैं। जब कोई बेहतर विकल्प उपलब्ध हो तो वे एक दायित्व का प्रतिनिधित्व करते हैं।
—
S.Lott
मैं तर्क देता हूं (ऋण के रूपक के संदर्भ में) कि प्रबंधक ऋण-धारक हो सकते हैं, लेकिन कोड कलाकृतियां ऋण मूल्यांकन का प्रतिनिधित्व करती हैं और उन्हें मात्रा निर्धारित किया जा सकता है। यही है, मैं मानता हूं कि प्रबंधक "यूनिट परीक्षण को भूल जाएं क्योंकि हमारे पास समय नहीं है" जैसे निर्णय ले सकते हैं और इस प्रकार तकनीकी ऋण को प्रभावित कर सकते हैं। लेकिन, मुझे निश्चित रूप से लगता है कि आप एक संख्या को व्यक्तिगत कोड तत्वों के लिए एक अनुमान के रूप में डाल सकते हैं। इसे इस तरह से सोचें - यदि प्रबंधन भविष्य के लिए कई भयानक निर्णय लेता है, लेकिन कोई कोड नहीं लिखा गया है, तो क्या उस समय कोई ऋण है?
—
एरिक डायट्रिच
"क्या उस पल में कोई कर्ज है?" ऋण जमा करने की आवश्यकता है, आप सही हैं। लेकिन यह कोड नहीं है; यह "काम" की मात्रा है जिसे पूर्ववत करने की आवश्यकता है। विनिर्देशों, डिजाइन, कोड, डीबीए-काम, सभी को फिर से काम करना होगा। सॉफ्टवेयर कलाकृतियों से ऋण मापना (कोड की स्रोत लाइनों की तरह) विकास लागत की भविष्यवाणी करने के समान है।
—
S.Lott
तकनीकी ऋण को मापना कठिन है, साथ ही यह प्रबंधकों को भ्रमित करता है। हालांकि, मैं आपको तकनीकी ऋण से लड़ने का एक अच्छा तरीका बता सकता हूं: सस्ते, अच्छे और कामकाजी प्रोटोटाइप, खासकर अगर कोड आधार जीयूआई के साथ घूमता है। जैसा कि जोएल ने यहां सुझाव दिया है: joelonsoftware.com/articles/fog0000000332.html , हर दिन सफाई करने में थोड़ा समय व्यतीत करें। परिवर्तन में सकारात्मक सुधार होना चाहिए, न कि "ओएमजी, हमारे तकनीकी ऋण = पेंटाबोब्स और यह तेजी से बढ़ रहा है ... आकाश गिर रहा है।" बस काइज़ेन पर हर दिन थोड़ा समय इस तरह से बिताएं कि काम करने वाली चीजें टूटें नहीं। दोस्त बनाओ।
—
नौकरी
@ZoranPavlovic आपका विचित्र और अनचाही झूठी दुविधा एक तीसरा विकल्प याद कर रही है: मैं जानना चाहता था कि क्या कोई उपकरण थे जो तकनीकी ऋण का मूल्यांकन करने का प्रयास करते थे।
—
एरिक डायट्रिच