डिजाइन के बारे में

अधिकांश डेवलपर्स, यहां तक ​​कि बहुत कम अनुभव के साथ, उनके समाधान को डिजाइन करने की समस्याओं का सामना करते हैं, जब कार्य को दर्जनों विभिन्न तरीकों से हल किया जा सकता है और आपको एक निश्चित, अधिक या कम पर्याप्त विकल्प चुनने की आवश्यकता होती है।

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

एक और चरम है, जब एक टीम सही समाधान (एक वास्तुकार के पवित्र कंघी बनानेवाले की रेती) की खोज में सप्ताह बिता सकती है, जब डिजाइन सभी संभव दिशाओं में "विस्तार" करने में सक्षम होगा, और इतना "लचीला" होगा कि इसे लागू करने का कोई तरीका नहीं होगा।


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

नतीजतन, अधिकांश डेवलपर्स को यह समझना आता है कि ...

डिजाइन कई परस्पर विरोधी लक्ष्यों और आवश्यकताओं के बीच एक समझौता खोजने की कला है, जिसका महत्व समय के साथ बदल सकता है।

प्रसंग महत्वपूर्ण है

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

हां, ज्यादातर मामलों में खुले मैदान वास्तव में खतरनाक अभ्यास होते हैं, लेकिन जो हमें मौजूदा सिस्टम के साथ बातचीत करने के लिए संरचनाओं (महत्वपूर्ण प्रकार के .NET) में उनका उपयोग करने से रोकता है? हां, यूनिट परीक्षण एक बहुत अच्छी बात है, लेकिन इसका मतलब यह नहीं है कि 100% परीक्षण कवरेज के बिना आपकी परियोजना विफल हो जाएगी। इस कारण से, जब एक अनुभवी प्रोग्रामर से सवाल पूछा जाता है कि "बेहतर क्या है?", तो "बुद्धिमान मिर्च" उसे "माथे" में जवाब नहीं देगा, लेकिन समस्या के संदर्भ को समझने के लिए एक स्पष्ट सवाल पूछेगा? आखिरकार, एक मामले में लागू करने के लिए क्या उचित है (उत्पादन कोड के लिए इकाई परीक्षण लिखना) दूसरे में पूरी तरह से अनावश्यक हो सकता है (क्या होगा अगर हम एक दिन के प्रोटोटाइप के बारे में बात कर रहे हैं?)।
उसी कारण से, हम अक्सर दूसरों के फैसलों की निंदा करते हैं और इस निर्णय की गुणवत्ता को अक्सर डब्ल्यूटीएफ प्रति सेकंड की मात्रा से मापा जाता है; लेकिन तथ्य यह है कि अक्सर हम केवल उन परिस्थितियों के बारे में पर्याप्त जानकारी नहीं रखते हैं जिनके तहत इसे अपनाया गया था। यहां एक उदाहरण दिया गया है: C # में, अत्यधिक संदिग्ध संभावना है, जिसे कोवेरीयन ऑफ सरण कहा जाता है। इसका अर्थ है कि निम्नलिखित कोड स्निपेट सही है और परिणामस्वरूप संकलन के बजाय रन-टाइम त्रुटि होगी:

object[] o = new string[] {“1”,”2”, “3”}; o[0] = 42; 

इस विशेषता का कारण इस तथ्य से संबंधित है कि यह जावा भाषा में पहले संस्करण से था, और 90 के दशक के उत्तरार्ध में सी # भाषा विकसित करते समय, मौजूदा प्रोग्रामर्स को एक नई भाषा में "हुकिंग" करने का महत्व निर्णायक था। यही कारण है कि सामान्य सी-जैसे सिंटैक्स का उपयोग किया जाता है, जो पहले से ही सी / सी ++ और जावा प्रोग्रामर से परिचित था, भले ही इसकी कमियां हों। इस तरह के निर्णय अब संदिग्ध लग सकते हैं, लेकिन उनके गोद लेने के कारणों को समझना (अन्य भाषाओं के साथ स्थिरता (रन-टाइम त्रुटियों की संभावना)) यह स्पष्ट करते हैं कि भाषा या पुस्तकालय इस तरह से क्यों लागू किए जाते हैं और अन्यथा नहीं, और उनके विकास को क्या प्रभावित करता है।



किसी अन्य व्यक्ति के निर्णय को पूर्ण श्रेणियों में निर्धारित करना असंभव है , किए गए निर्णय का सही मूल्यांकन करने के लिए, आपको यह समझने की आवश्यकता है कि यह किस प्रतिबंध के दबाव में किया गया था।

अच्छा, तुमने कहा था !!

उन्होंने आपको कितनी बार कहा है: "अरे, ठीक है, आपने खुद कहा है कि आपको ऐसा करने की आवश्यकता नहीं है, लेकिन आप इसे स्वयं करें!" या "ठीक है, धिक्कार है, आप देते हैं, हमने पहले ही आपके साथ सब कुछ पर चर्चा की है, और अब आप कहते हैं कि आपको इसकी आवश्यकता है दूसरे को! ” बात यह है कि समय के साथ हमारे निर्णय बदलते हैं। समय के साथ, कुछ मानदंडों (कोड दक्षता) का महत्व कम हो सकता है, और अन्य मानदंडों (वास्तुकला स्थिरता और रखरखाव में आसानी) का महत्व बढ़ सकता है।

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

अच्छा डिजाइन

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

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

अच्छा डिजाइन अपने आप में एक अंत नहीं है, इसलिए सही समाधान के लिए प्रयास करने की आवश्यकता नहीं है। इतनी सारी चीजों के साथ, सामान्य ज्ञान और व्यावहारिकता आपके सबसे अच्छे सलाहकार हैं।

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