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