ईश्वर वस्तु। जटिल परियोजनाओं का विश्लेषण

परिचय

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



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

कोड पर एक नज़र

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

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

कार्य योजना

समस्या को कई चरणों में हल किया गया था:

1. डेटा एक्सेस लेयर कोड के लिए मात्रात्मक जानकारी का संग्रह।
2. विधि द्वारा उपयोग की जाने वाली तालिकाओं की संख्या का विश्लेषण।
3. तालिका का उपयोग करके विधियों की संख्या का विश्लेषण।
4. उनके द्वारा उपयोग की जाने वाली तालिकाओं के आधार पर क्लस्टरिंग विधियाँ।
5. विषय क्षेत्र की संस्थाओं के समूहों द्वारा समूहों का समूहन करना।
6. गणना किए गए वर्ग समूहों के लिए विधि हस्तांतरण की स्वचालित रीफैक्टरिंग।
7. विशेष मामलों के मैनुअल सुधार।

बोल्ड हाइलाइट किए गए आइटम जो इस आलेख में चर्चा किए गए हैं। शेष अगले में हैं।

चलो चलते हैं!

मात्रात्मक जानकारी संग्रह

चूंकि कार्य का समापन चरण प्राप्त डेटा की क्लस्टरिंग है, इसलिए डेटा को ऐसे रूप में इकट्ठा करना आवश्यक है जिसमें तरीकों और तालिकाओं के बीच संबंधों को प्रतिबिंबित करना सुविधाजनक होगा। मेरी राय में, ऐसा प्रारूप एक मैट्रिक्स हो सकता है, जिसमें से पंक्तियाँ तरीकों को दर्शाती हैं, कॉलम तालिकाओं का प्रतिनिधित्व करते हैं, और कोशिकाएं दो मान ले सकती हैं: 0 (तालिका विधि द्वारा उपयोग नहीं की जाती है) और 1 (तालिका विधि द्वारा उपयोग की जाती है):

	तालिका 1	तालिका 2
विधि 1	1	1
विधि 2	0	1

यह केवल कोड पर इस तरह के डेटा को इकट्ठा करने के लिए रहता है। डेटा एक्सेस लेयर C # में लिखी गई है, जो कुछ हद तक इस कार्य को सरल बनाती है। NRefactory जैसी परियोजना है। यह एक पार्सर और C # कोड कनवर्टर है, जिसे व्यापक रूप से संकीर्ण सर्किल IDEs में SharpDevelop के रूप में जाना जाता है और (हाल के समय से) MonoDevelop। वर्तमान संस्करण के लिए समझदार दस्तावेज ढूंढना संभव नहीं था, लेकिन एक उत्कृष्ट डेमो है जिसमें से पुस्तकालय के साथ काम करने के बुनियादी सिद्धांत स्पष्ट हैं। कुछ घंटों के लिए, एक सूचना संग्राहक (कचरा) लिखा गया था, जो परियोजना के माध्यम से चलता था और उपरोक्त रूप में जानकारी एकत्र करता था। डेटाबेस में SQL क्वेरी द्वारा आम तौर पर मौजूदा तालिकाओं की सूची पूर्व-निर्मित थी। साथ ही, यह पता चला कि कोड में कुछ तालिकाओं का उपयोग नहीं किया गया है। :-) शायद उन्हें संग्रहीत प्रक्रियाओं की आवश्यकता है, लेकिन कार्य के समाधान के दौरान ऐसा विश्लेषण नहीं किया गया था।

के विश्लेषण

वांछित मैट्रिक्स प्राप्त करने के बाद, मुझे यह देखने में रुचि थी कि प्रति तालिका तालिकाओं की संख्या और प्रति तालिका विधियों की संख्या कैसे दिखती है, यदि पंक्तियों और स्तंभों को सिंक करने के बाद, अवरोही क्रम में डेटा को सॉर्ट करें। परिणाम आंकड़े 1 और 2 में दिखाया गया है।

चित्र 1

चित्र 2

दोनों ग्राफ़ पर, तीन क्षेत्रों को प्रतिष्ठित किया जा सकता है:

1. खड़ी वृद्धि का क्षेत्र (रेखांकन की शुरुआत में)।
2. चिकनी वंश का क्षेत्र (ग्राफ़ के अंत में)।
3. फॉर्म का एक क्षेत्र "उठता हुआ प्रतीत होता है, हालांकि यह पहले से ही उतर रहा है" (रेखांकन के बीच में)।

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


चित्रा 3. क्लस्टरिंग तालिकाओं के परिणाम का आरेख। तालिकाओं को गेंदों के रूप में दिखाया गया है, गेंद का रंग क्लस्टर की संख्या से निर्धारित होता है, और इसकी त्रिज्या इस तालिका का उपयोग करने की विधियों की संख्या से निर्धारित होती है।

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

अगला चरण चित्र 2 का वही विश्लेषण है, हालांकि, इस मामले में यह माना जा सकता है कि पहचाने गए तीन समूह (और एक अन्य विशेष मामला) हैं:

1. बहुत जटिल विधियां, जिनमें से स्वचालित मोड में क्लस्टरिंग सफल होने की संभावना नहीं है। वे एक भयानक स्पेगेटी कोड हैं जो एक विशाल एसक्यूएल क्वेरी के टुकड़ों को एक एकल राक्षसी पूरे में इकट्ठा करते हैं और परिणाम को उपयोगकर्ता में बदल देते हैं। केवल हस्तनिर्मित, केवल कट्टर।
2. जटिल तरीके जिसके साथ अभी भी उम्मीद है। उन्हें अभी भी आपके हाथों से रिफ्लेक्ट किया जाना है, लेकिन आप क्लस्टरिंग की कोशिश कर सकते हैं।
3. 6 टेबल से अधिक नहीं सरल तरीके शामिल हैं। क्लस्टरिंग का परिणाम बहुत अच्छा होना चाहिए।
4. एक विशेष मामले के रूप में, हम उन तरीकों को अलग कर सकते हैं जो केवल एक तालिका के साथ काम करते हैं, उनके लिए, क्लस्टरिंग आवश्यक नहीं है, यहां सब कुछ स्पष्ट है। यानी हम चरमोत्कर्ष पर भी नहीं पहुँचे हैं, और लगभग 25% काम पहले ही हो चुका है।
   

परिणाम

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

आगे क्या है?

अगले भाग (भागों में?): विश्लेषण का समापन, क्लस्टरिंग के परिणामों के आधार पर कक्षाओं का स्वत: चयन, मैनुअल मोड में कक्षाओं और विधियों के महीन चयन के लिए रेस्परर एसडीके पर आधारित टूल का निर्माण।

• क्या NRefactory पर एक लेख पढ़ना दिलचस्प है?
• क्या मुझे Resharper में Refactoring लिखने पर एक अलग लेख लिखना चाहिए?
• क्या किसी ने कुछ ऐसा ही किया है? परिणाम बहुत दिलचस्प हैं, Google कुछ मदद नहीं करता है।
• और ये चार्ट क्या दिखते हैं?