हम सभी इसे सरल रखना चाहते हैं, है ना?किसी डिज़ाइन का मूल्यांकन करते समय, आप जटिलता का मूल्यांकन कैसे करते हैं?
मैंने जटिलता को सिस्टम के बीच बातचीत की संख्या के रूप में मापा जा रहा है, और मुझे लगता है कि यह शुरू करने के लिए एक बहुत अच्छी जगह है। आंत के अलावा, किसी विशेष डिजाइन या सॉफ़्टवेयर के टुकड़े की जटिलता के स्तर को निर्धारित करने के लिए अन्य (अधिमानतः अधिक उद्देश्य) विधियों का उपयोग कैसे किया जा सकता है?
आपके पसंदीदा नियम या हेरिस्टिक्स क्या हैं?
यदि आपका ऐप बनाया गया है, तो आप इसे समय के अनुसार माप सकते हैं (कितना समय निष्पादित करने के लिए कोई विशेष कार्य निष्पादित करेगा) या गणना (प्रत्येक बार कार्य चलाने के दौरान कितना कोड निष्पादित किया जाता है)।
यदि आपके पास अभी डिज़ाइन हैं, तो आप देख सकते हैं कि किसी दिए गए कार्य को चलाने के लिए या औसत कार्य चलाने के लिए आपके डिज़ाइन के कितने घटक आवश्यक हैं। उदाहरण के लिए, यदि आप अपने डिजाइन पैटर्न के रूप में एमवीसी का उपयोग करते हैं, तो आपके पास अधिकांश कार्यों के लिए कम से कम 3 घटक छूए हैं, लेकिन डिज़ाइन के आपके कार्यान्वयन के आधार पर, आप दर्जनों घटकों (एक कैश के अतिरिक्त) उदाहरण के लिए 3 परतें)।
यहाँ मेरे हैं:
1) यह कोई है जो समस्या को समझता है लेकिन समाधान के बारे में सोचा नहीं किया गया है करने के लिए समझाने के लिए कितना कठिन है? अगर मैं हॉल में किसी को समस्या की व्याख्या करता हूं (जो शायद हॉल में हैं तो समस्या को समझता है) और समाधान की व्याख्या कर सकते हैं, तो यह बहुत जटिल नहीं है। यदि यह एक घंटे से अधिक समय लेता है, तो समाधान का समाधान अच्छा होता है।
2) घोंसला वाले कार्यों में आपको कितना गहरा होना है? अगर मेरे पास कोई ऑब्जेक्ट है जिसके लिए किसी ऑब्जेक्ट द्वारा किसी ऑब्जेक्ट द्वारा रखी गई संपत्ति की आवश्यकता होती है, तो संभावनाएं अच्छी होती हैं कि मैं जो करने की कोशिश कर रहा हूं वह ऑब्जेक्ट से बहुत दूर है। ऑब्जेक्ट्स थ्रेड-सुरक्षित बनाने की कोशिश करते समय ये स्थितियां समस्याग्रस्त हो जाती हैं, क्योंकि आपकी वर्तमान स्थिति से लॉक करने के लिए अलग-अलग गहराई की कई वस्तुएं होती हैं।
3) क्या आप पहले से हल हो चुके समस्याओं को हल करने की कोशिश कर रहे हैं? हर समस्या नई नहीं है (और कुछ तर्क देंगे कि वास्तव में कोई भी नहीं है)। क्या मौजूदा पैटर्न या पैटर्न का समूह आप उपयोग कर सकते हैं? यदि आप नहीं कर सकते हैं, क्यों नहीं? अपने स्वयं के नए समाधान बनाने के लिए यह सब अच्छा है, और मैं इसके लिए सब कुछ कर रहा हूं, लेकिन कभी-कभी लोगों ने पहले से ही समस्या का उत्तर दिया है। मैं एसटीएल को फिर से लिखने वाला नहीं हूं (हालांकि मैंने कोशिश की, एक बिंदु पर), क्योंकि समाधान पहले से मौजूद है और यह एक अच्छा है।
जब मैंने न्यू इंग्लैंड कॉम्प्लेक्स सिस्टम्स इंस्टीट्यूट (http://necsi.org/) में कॉम्प्लेक्स सिस्टम मॉडलिंग कार्यशाला में भाग लिया, तो उनके द्वारा उपयोग किए जाने वाले उपायों में से एक सिस्टम राज्यों की संख्या थी।
उदाहरण के लिए यदि आप दो नोड्स, जो बातचीत, ए और बी है, और इनमें से प्रत्येक 0 या 1 हो सकता है, अपने संभावित स्थितियों में हैं:
A B
0 0
1 0
0 1
1 1
इस प्रकार बाइनरी के बीच केवल 1 बातचीत का एक प्रणाली घटक वास्तव में 4 अलग-अलग राज्यों में परिणाम दे सकते हैं। मुद्दा यह है कि सिस्टम की जटिलता रैखिक रूप से बढ़ती नहीं है क्योंकि इंटरैक्शन की संख्या बढ़ जाती है।
जटिलता युग्मन और कैसे एकजुट अपने सभी वस्तुओं रहे हैं के साथ अनुमान लगाया जा सकता। यदि कुछ बहुत अधिक युग्मन है या पर्याप्त समेकित नहीं है, तो डिजाइन की तुलना में अधिक जटिल होना शुरू हो जाएगा।
अच्छे उपाय भी फाइलों की संख्या हो सकते हैं, कॉन्फ़िगरेशन संग्रहीत स्थानों की संख्या, कुछ भाषाओं पर संकलन का आदेश हो सकता है।
उदाहरण:
.- गुण फ़ाइलें, डेटाबेस विन्यास, एक्सएमएल फ़ाइलें संबंधित जानकारी धारण करने के लिए।
.- इंटरफेस के साथ कक्षाओं के हजारों, और डेटाबेस मैपिंग
.- एक अत्यंत लंबी और जटिल निर्माण फ़ाइल (build.xml, Makefile, दूसरों ..
औपचारिक मैट्रिक्स रहे हैं। पढ़ें अप पर Cyclomatic Complexity, उदाहरण के लिए।
संपादित करें।
इसके अलावा, Function Points को देखो। वे आपको एक देना सिस्टम जटिलता के गैर-आंत-मात्रा मात्रात्मक माप।
चक्रवात जटिलता स्रोत कोड से एक मटेरिक गणना है - आपके पास डिज़ाइन के दौरान स्रोत कोड नहीं है! –
@ स्टेवन ए लोवे: हालांकि, यदि आपके पास if-statement की समान अवधारणाएं हैं, तो आप करते हैं। विनिर्देशों या आवश्यकताओं में वर्णित विकल्पों और निर्णयों के आधार पर आप आसानी से अपने डिजाइन के कुछ हिस्सों को जटिलता के साथ स्कोर कर सकते हैं। –
आपके पास स्रोत कोड होने पर चक्रवात बेहतर होता है। डिजाइन में यह लूप और तुलना की संख्या का आकलन करने की कोशिश करने के लिए उत्पादक नहीं है। –
अंत में कुछ एलओसी वास्तव में उपाय करने में मदद कर सकता है? :)
मुझे लगता है कि जटिलता को उन चीजों की संख्या के रूप में सबसे अच्छा देखा जाता है जिन्हें बातचीत करने की आवश्यकता होती है।
एक जटिल डिजाइन में एन टायर होंगे जबकि एक साधारण डिजाइन में केवल दो होंगे।
जटिलता उन समस्याओं के आसपास काम करने के लिए आवश्यक है जो सादगी को दूर नहीं कर सकते हैं, इसलिए यह हमेशा एक समस्या नहीं होगी।
सामान्य रूप से जटिलता को परिभाषित करने में एक समस्या है क्योंकि जटिलता में आमतौर पर इसके साथ एक कार्य होता है। कुछ समझने के लिए जटिल हो सकता है, लेकिन देखने के लिए सरल (उदाहरण के लिए बहुत तेज़ कोड) इस वेब पेज को सर्वर से आपके कंप्यूटर पर प्राप्त करने वाली इंटरैक्शन की संख्या बहुत जटिल है, लेकिन http प्रोटोकॉल का अमूर्त बहुत आसान है।
इसलिए मापने से पहले एक कार्य को ध्यान में रखना (उदा। रखरखाव) इसे और अधिक उपयोगी बना सकता है। (यानी एक कॉन्फ़िगरेशन फ़ाइल जोड़ना और ऐप में लॉगिंग करना इसकी उद्देश्य जटिलता बढ़ाता है [हाँ, केवल थोड़ा सा सुनिश्चित करें], लेकिन रखरखाव को सरल बनाता है)।
कोड की जटिलता नहीं बल्कि डिज़ाइन, डिजाइन करने के दौरान कितनी फ़ाइल जानना मुश्किल है;) –