4.3 कोड चर्न और हॉटस्पॉट विश्लेषण

अवलोकन और प्रेरणा

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

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

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

प्रमुख सिद्धांत

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

सिफ़ारिशें

चर्न और जटिलता को साथ में गणना करें, और उनके संयोजन द्वारा रैंक करें

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

कार्य करने से पहले शीर्ष हॉटस्पॉटों की मानवीय निर्णय से जाँच करें

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

हॉटस्पॉटों को घटना और दोष डेटा के विरुद्ध क्रॉस-रेफ़रेंस करें

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

हॉटस्पॉट प्रवृत्ति को क्रमागत विश्लेषणों में ट्रैक करें, केवल एक एकल स्नैपशॉट नहीं

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

टीम-स्तरीय प्राथमिकता बातचीत को प्रतिस्थापित करने के लिए नहीं, सूचित करने के लिए हॉटस्पॉट डेटा का उपयोग करें

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

समझौते: लाभ और हानि

दृष्टिकोण	लाभ	हानि
अंतर्ज्ञान-आधारित प्राथमिकता	तेज़, कोई टूलिंग आवश्यक नहीं, टीम के प्रासंगिक ज्ञान का लाभ उठाती है	हाल की, व्यक्तिगत पसंद, और जो भी सबसे ज़ोर से शिकायत करता है उससे तिरछी
अकेले चर्न	गणना करना सरल	अपने आप में कमज़ोर संकेत; बार-बार परिवर्तन अंतर्निहित रूप से बुरा नहीं है
जटिलता के साथ जोड़ा गया चर्न (हॉटस्पॉट विश्लेषण)	मज़बूत, प्रमाण-आधारित, मौजूदा डेटा से स्वचालित	दो डेटा स्रोतों को जोड़ने और निर्णय के साथ परिणामों की व्याख्या करने की आवश्यकता
घटना डेटा के विरुद्ध क्रॉस-रेफ़रेंस किया गया हॉटस्पॉट विश्लेषण	सत्यापित, प्राथमिकता के लिए सबसे मज़बूत प्रमाण	विश्वसनीय घटना-से-कोड लिंकेज की आवश्यकता, जो हर संगठन के पास नहीं है

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

अपनी टीम के साथ चर्चा करने के प्रश्न

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

क्षेत्र दृष्टिकोण

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

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

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

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

उदाहरण

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

सरकार। एक राज्य मोटर वाहन एजेंसी की दशकों पुरानी लाइसेंसिंग प्रणाली एक आधुनिकीकरण व्यावसायिक मामले के हिस्से के रूप में एक हॉटस्पॉट विश्लेषण से गुज़री। विश्लेषण ने फ़ाइलों के एक छोटे समूह की पहचान की, कुल कोडबेस के 3% से कम का प्रतिनिधित्व करते हुए, दोनों चर्न और जटिलता के एक असंगत हिस्से के लिए ज़िम्मेदार, और एजेंसी के घटना लॉग के विरुद्ध क्रॉस-रेफ़रेंस ने दिखाया कि यही समूह पिछले तीन वर्षों में सभी रिपोर्ट की गई प्रणाली दोषों का लगभग 40% हिसाब रखता है। यह ठोस, प्रमाण-आधारित खोज, इस सामान्य दावे से कहीं अधिक प्रेरक कि “प्रणाली पुरानी है और आधुनिकीकरण की आवश्यकता है,” उस समूह पर विशेष रूप से केंद्रित एक लक्षित, वृद्धिशील आधुनिकीकरण प्रयास के लिए एक सफल बजट अनुरोध का केंद्रबिंदु बन गई, एक कहीं अधिक महंगे पूर्ण प्रणाली प्रतिस्थापन की बजाय।

व्यावसायिक तर्क: प्रेरणाएँ, ROI, और TCO

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

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

विरोधी-पैटर्न और नुक़सान

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

परिपक्वता मॉडल

स्तर 1, आरंभ: रीफ़ैक्टरिंग प्राथमिकताएँ अंतर्ज्ञान या शिकायत मात्रा द्वारा निर्धारित की जाती हैं, बिना किसी चर्न या जटिलता डेटा के निर्णय को सूचित किए।
स्तर 2, विकास: कुछ टीमें अनौपचारिक रूप से चर्न या जटिलता डेटा की जाँच करती हैं, लेकिन कोई सुसंगत, संगठन-व्यापी हॉटस्पॉट विश्लेषण प्रथा नहीं है।
स्तर 3, मानकीकरण: चर्न और जटिलता को जोड़ने वाला हॉटस्पॉट विश्लेषण नियमित रूप से चलता है और लगातार संगठन-व्यापी रीफ़ैक्टरिंग प्राथमिकता को सूचित करता है।
स्तर 4, प्रबंधन: विश्लेषण को सत्यापित करने के लिए हॉटस्पॉटों को घटना और दोष डेटा के विरुद्ध क्रॉस-रेफ़रेंस किया जाता है, और क्रमागत चक्रों में प्रवृत्ति को सक्रिय रूप से ट्रैक किया जाता है।
स्तर 5, संयोजन: संगठन हॉटस्पॉट-सूचित रीफ़ैक्टरिंग निवेश से विशिष्ट, मापने योग्य दोष-दर या डिलीवरी सुधारों की ओर इशारा कर सकता है, और विश्लेषण इंजीनियरिंग निवेश निर्णयों के लिए एक नियमित, विश्वसनीय इनपुट है।

चर्चा के लिए विचार

यदि हमने आज यह विश्लेषण चलाया तो हमारी शीर्ष हॉटस्पॉट सूची कैसी दिखेगी?
क्या वह सूची हमारी टीम की वर्तमान अनौपचारिक भावना से मेल खाएगी या विरोधाभासी होगी कि हमारे सबसे बुरे समस्या क्षेत्र कहाँ हैं?
क्या हमारे पास हॉटस्पॉटों को वास्तविक घटनाओं के विरुद्ध क्रॉस-रेफ़रेंस करने का डेटा है?
क्या एक ज्ञात समस्या क्षेत्र इसे ठीक करने के पिछले प्रयासों के बावजूद बना रहा है, और क्यों?
हमारे वर्तमान शीर्ष हॉटस्पॉट को एक और वर्ष के लिए असंबोधित छोड़ने से हमें क्या लागत आएगी?

मुख्य निष्कर्ष

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

संदर्भ और आगे पढ़ने के लिए

Your Code as a Crime Scene, by Adam Tornhill (वर्ज़न कंट्रोल डेटा से चर्न और जटिलता को जोड़ने वाले हॉटस्पॉट विश्लेषण पर आधारभूत पाठ)।
Software Design X-Rays, by Adam Tornhill (वर्ज़न कंट्रोल इतिहास का उपयोग करके व्यवहारिक कोड विश्लेषण के लिए आगे की तकनीकें)।
Nagappan, Nachiappan, and Thomas Ball, “Use of Relative Code Churn Measures to Predict System Defect Density,” ICSE (2005): चर्न और दोष घनत्व के बीच संबंध पर अनुभवजन्य शोध।
Refactoring: Improving the Design of Existing Code, by Martin Fowler (पहचाने जाने के बाद आकस्मिक जटिलता को संबोधित करने की तकनीकें)।