टेक ऋण गणना: वेग-आधारित बनाम। मुद्दा-आधारित बनाम। गुणवत्ता-आधारित मापन समझाया गया

ब्याज दरों में 157% की बढ़ोतरी!

नहीं, मैं फेड के नवीनतम निर्णय के बारे में बात नहीं कर रहा हूं, लेकिन मंदी के बारे में, फिक्शनल इंक ने अपने मंच के संस्करण 3.0 को जारी करने के बाद सामना किया।

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

नई रिलीज के हिस्से के रूप में पेश किए गए नए तकनीकी ऋण को ब्याज दर बढ़ाने और भविष्य में टीम की मंदी को बढ़ाने के बारे में सोचा जा सकता है।

(मुझे लगता है कि आप यहां तकनीकी ऋण की अवधारणा से काफी परिचित हैं, लेकिन अगर आपको गति बढ़ाने के लिए एक पुनश्चर्या की आवश्यकता है तो यहां एक त्वरित भजन की पुस्तक )

ठीक है, आप शायद एक इंजीनियरिंग प्रबंधक को उनके तकनीकी ऋण के बारे में इस तरह की बात नहीं सुनेंगे।

लेकिन क्यों नहीं?

अपने चल रहे प्रभाव को मापने और परिमाणित करने में सक्षम होना तकनीकी ऋण महत्वपूर्ण है यदि आप इसे संबोधित करने के लिए एक कार्य योजना तैयार करना चाहते हैं।

जब हम तकनीकी ऋण के बारे में सोचते हैं, तो ब्याज आपके मौजूदा तकनीकी ऋण के वर्तमान और भविष्य के विकास पर खोए हुए समय की मात्रा है।

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

तकनीकी ऋण का स्वस्थ स्तर क्या है?

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

एक स्पष्ट समस्या तुरंत सामने आती है - मूलधन समय की एक निश्चित इकाई है (घंटों को ठीक करने/पुनर्लेखित करने के लिए) लेकिन ब्याज प्रति समय खोए हुए घंटों की दर है। इसे ध्यान में रखते हुए हमें एक प्रभाव अंतराल के विचार को पेश करने की आवश्यकता है - वह समय जिसके दौरान हम इस बात की परवाह करते हैं कि तकनीकी ऋण से भविष्य की मंदी पुनर्लेखन की लागत से अधिक है या नहीं। आप जिस प्रभाव अंतराल की परवाह करते हैं, वह आपकी कंपनी, आपकी विशिष्ट नियोजन प्रक्रिया और उसके चरण या आपके कोडबेस के जीवनचक्र पर बहुत अधिक निर्भर करेगा - लेकिन मैं व्यक्तिगत रूप से आमतौर पर 3 महीने के प्रभाव अंतराल को देखूंगा। एक कंपनी के रूप में हमारे शुरुआती चरण में, वर्ष-लंबी + समय-सीमा में कुछ भी देखना बहुत व्यापक है, लेकिन 2-3 महीने से कम कुछ भी तकनीकी ऋण के प्रभाव को बहुत कम आंकेगा जैसा कि हम बाद में देखेंगे।

इसका मतलब यह है कि तकनीकी ऋण का हमारा स्तर संबोधित करने योग्य नहीं है यदि:

उदाहरण के लिए: यदि हमारे पास एक छोटी परियोजना थी जिसके बारे में हमें पता था कि तकनीकी ऋण है जो हमें 2 घंटे/सप्ताह तक धीमा कर देता है, तो हमें उस ऋण को दूर करने में 4 दिन लगेंगे, और 3 महीने के प्रभाव अंतराल की देखभाल करेंगे तो हम नहीं करेंगे अभी तक उस ऋण का भुगतान करने के लिए समय व्यतीत करें।

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

हम तकनीकी ऋण कैसे मापते हैं?

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

वेग आधारित मापन

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

उदाहरण के लिए: यदि हमारे पास 4 अलग-अलग क्षेत्रों के साथ अपेक्षाकृत सरल परियोजना है जिस पर हम काम करेंगे तो हम देख सकते हैं कि समय के साथ वेग कैसे बदलता है (यहां हम कहानी बिंदुओं/डेवलपर महीने में वेग ट्रैक कर रहे हैं)।

तकनीकी ऋण के प्रभाव का वेग आधारित मापन

यहाँ से हम देख सकते हैं कि D ने समान जटिल कार्यों के लिए किसी भी अन्य क्षेत्र की तरह काम करने में हमेशा ~3x समय लिया है। इसका तात्पर्य है कि कोडबेस के अन्य सभी वर्गों के रूप में इसका 3x ब्याज है। B अपेक्षाकृत A और C के बराबर हुआ करता था, लेकिन 4 महीने की शुरुआत में यह अचानक 2x समय लेने के लिए कूद गया। इससे पता चलता है कि हमने यहां कुछ कर्ज पेश किया है जो हमारी ब्याज दर को बी के लिए पहले की तुलना में दोगुना कर देता है।

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

जब वेग आधारित माप की बात आती है, तो इसके बारे में सोचने के लिए कुछ महत्वपूर्ण चेतावनियाँ हैं।

• वेग अस्थिर हो सकता है और नए (या मौजूदा) बग, गलत संरेखित अनुमान, तकनीकी बाधाएं, या बाहरी परियोजना देरी जैसे तकनीकी ऋण से स्वतंत्र कारकों पर निर्भर हो सकता है।

• अनुमानों में अंतर्निहित अनिश्चितता का स्तर होता है और शुरुआत में यह एक गलत उपाय हो सकता है।

• इस डेटा को इकट्ठा करना और उसका विश्लेषण करना मुश्किल और समय लेने वाला हो सकता है।

  
  

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

अंक आधारित मापन

एक अलग दृष्टिकोण यह है कि आप अपनी परियोजना के भीतर तकनीकी ऋण के विशिष्ट उदाहरणों की पहचान करें और अनुमान लगाएं कि वे आपको कितना धीमा कर सकते हैं। इसका एक हिस्सा स्वचालित उपकरणों का उपयोग करके किया जा सकता है, जैसे स्थैतिक विश्लेषण उपकरण, कोड गुणवत्ता के आसपास सामान्य मुद्दों को खोजने के लिए जो किसी परियोजना की पठनीयता, विस्तारशीलता या रखरखाव पर प्रभाव डाल सकते हैं। इस प्रकार के मुद्दों से निपटने में आपकी टीम के अनुभव के आधार पर आप प्रत्येक प्रकार के मुद्दे के लिए इसे एक ब्याज लागत (उदाहरण के लिए 5 मिनट/सप्ताह या 1%) निर्दिष्ट कर सकते हैं।

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

इस दृष्टिकोण में कुछ कमियां हैं:

• विशिष्ट मुद्दों से जुड़े समय का अनुमान गलत हो सकता है
• कुछ मुद्दे आसानी से लंबे समय तक अनसुलझे रह सकते हैं

गुणवत्ता आधारित मापन

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

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

एक उदाहरण को देखते हुए - वेग आधारित मापन पर अनुभाग में देखे गए सरल 4 भाग कोडबेस पर दोबारा गौर करें।

हम तालिका में इस परियोजना के समस्या अनुभागों को आसानी से देख सकते हैं (लाल रंग में हाइलाइट किया गया) और ब्याज अनुमान की गणना करना अपेक्षाकृत सरल है - बस विभिन्न घटकों के ब्याज प्रभावों का योग करें।

इस दृष्टिकोण में कुछ कमियां हैं:

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

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

कोडबेस इंटरेक्शन फ्रीक्वेंसी को देखते हुए

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

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

इस बात पर ध्यान दिए बिना कि हम डेटा कैसे प्राप्त करते हैं - तब हम अपने कोडबेस के प्रत्येक अनुभाग के साथ बातचीत करने में अपने समय का कितना प्रतिशत खर्च कर सकते हैं, इसका ब्रेकडाउन प्राप्त कर सकते हैं। इसे ब्याज योगदान के साथ मिलाकर, जिसे हमने पहले ही निर्धारित कर लिया है, अब हम देख सकते हैं कि आगे बढ़ते हुए हमारे कोडबेस के प्रत्येक अनुभाग से निपटने के दौरान हम कितना धीमा होने की उम्मीद करते हैं।

पहले के अपने उदाहरण को जारी रखते हुए - यदि हम आगे की ओर देखते हैं और उन सभी परियोजनाओं को नया करते हैं जिन पर हम अगले 3 महीनों में काम करने जा रहे हैं और आत्मविश्वास से अनुमान लगा सकते हैं कि यह कोडबेस के प्रत्येक क्षेत्र में बिताए गए समय की मात्रा थी ( याद रखें यह एक बहुत ही सरल परियोजना है):

अब हम इसे अपने वेग आधारित दृष्टिकोण और हमारे गुणवत्ता मीट्रिक आधारित दृष्टिकोण से प्राप्त ब्याज अनुमानों से जोड़ सकते हैं और एक अच्छा विचार प्राप्त कर सकते हैं कि हमें सबसे अधिक धीमा कहाँ किया जा रहा है।

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

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

ब्याज और ऋण का प्रबंधन

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

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

जैसा कि हमने पहले चर्चा की थी, हम आम तौर पर कोडबेस के क्षेत्रों को संबोधित करने में समय व्यतीत नहीं करना चाहते हैं जहां:

लेकिन, इसके चरम मामले में हम एक ऐसे मामले से समाप्त हो सकते हैं जहां हम बड़े पैमाने पर ऋण के उच्च स्तर से धीमा हो जाते हैं जिसे ठीक करना बेहद महंगा है - जो कि एक अच्छी स्थिति भी नहीं है।

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