नमस्कार, हेब्र! मैं आपको डेविड ब्रायंट कोपलैंड द्वारा "सॉफ्टवेयर डिजाइन के लिए चार बेहतर नियम" लेख प्रस्तुत करता हूं। डेविड ब्रायंट कोपलैंड एक सॉफ्टवेयर आर्किटेक्ट हैं और स्टिच फिक्स के लिए सीटीओ हैं। वह एक ब्लॉग का रखरखाव करता है और कई पुस्तकों का लेखक है ।

मार्टिन फाउलर ने हाल ही में केंट बेक से चार सरल डिजाइन नियमों के बारे में अपने ब्लॉग पोस्ट के लिंक के साथ ट्वीट किया, जो मुझे लगता है कि इसमें और सुधार किया जा सकता है (और जो कभी-कभी प्रोग्रामर को गलत तरीके से भेज सकते हैं):

एक्सट्रीम प्रोग्रामिंग से केंट के नियम

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

मेरे अनुभव के अनुसार, ये नियम सॉफ़्टवेयर डिज़ाइन की जरूरतों को पूरा नहीं करते हैं। एक अच्छी तरह से डिजाइन प्रणाली के लिए मेरे चार नियम हो सकते हैं:

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

मेरे लिए, ये नियम हमारे सॉफ़्टवेयर के साथ क्या करते हैं, से उपजा है।

तो हम अपने सॉफ्टवेयर के साथ क्या करते हैं?

हम सॉफ्टवेयर डिजाइन के बारे में पहले बात नहीं कर सकते हैं कि हम इसके साथ क्या करना चाहते हैं।

सॉफ्टवेयर समस्या को हल करने के लिए लिखा गया है। कार्यक्रम चलता है और एक व्यवहार है। इस व्यवहार का अध्ययन सही संचालन सुनिश्चित करने या त्रुटियों का पता लगाने के लिए किया जाता है। सॉफ्टवेयर भी अक्सर इसे नया या बदला हुआ व्यवहार देने के लिए बदलता है।

इसलिए, सॉफ़्टवेयर डिज़ाइन के किसी भी दृष्टिकोण को इस व्यवहार को यथासंभव सरल बनाने के लिए उसके व्यवहार की भविष्यवाणी, अध्ययन और समझ पर ध्यान केंद्रित किया जाना चाहिए।

हम परीक्षण द्वारा सही व्यवहार को सत्यापित करते हैं, और इसलिए मैं केंट से सहमत हूं कि पहली और सबसे महत्वपूर्ण बात यह है कि अच्छी तरह से डिज़ाइन किए गए सॉफ़्टवेयर को परीक्षण पास करना होगा। मैं आगे भी जाऊंगा और जोर दूंगा कि सॉफ्टवेयर में परीक्षण होने चाहिए (यानी परीक्षण द्वारा अच्छी तरह से कवर किया जाना चाहिए)।

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

कोड की नकल को खत्म करने के लिए अमूर्तता की आवश्यकता होती है, और अमूर्तता से जटिलता पैदा होती है

अपने आप को न दोहराएं या DRY का उपयोग विवादास्पद डिजाइन निर्णयों को सही ठहराने के लिए किया जाता है। क्या आपने कभी समान कोड देखा है?

ZERO = BigDecimal.new(0) 

इसके अतिरिक्त, आपने शायद कुछ ऐसा देखा है:

 public void call(Map payload, boolean async, int errorStrategy) { // ... } 

यदि आप झंडे, बूलियन, आदि के तरीकों या कार्यों को देखते हैं, तो इसका मतलब यह है कि किसी व्यक्ति ने डीएआरवाई सिद्धांत का उपयोग किया था, जब रिफलेक्टरिंग किया गया था, लेकिन कोड दोनों स्थानों में समान नहीं था, इसलिए परिणामी कोड होना चाहिए दोनों व्यवहारों को समायोजित करने के लिए पर्याप्त लचीला हो।

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

इसलिए, कुछ प्रकार के व्यवहार को संयोजित करना वास्तव में महत्वपूर्ण है , लेकिन यह समझना मुश्किल हो सकता है कि वास्तव में कौन से व्यवहार को दोहराया गया है। अक्सर कोड के टुकड़े समान दिखते हैं, लेकिन यह केवल दुर्घटना से होता है।

विचार करें कि कोड डुप्लीकेशन को खत्म करने की तुलना में इसे फिर से वापस करना कितना आसान है (उदाहरण के लिए, एक खराब विचार के बाद अमूर्त बनाने के बाद)। इसलिए, हमें डुप्लिकेट कोड छोड़ने के बारे में सोचने की ज़रूरत है, जब तक कि हम पूरी तरह से सुनिश्चित न हों कि हमारे पास इससे छुटकारा पाने का एक बेहतर तरीका है।

अमूर्त बनाना हमें सोचना चाहिए। यदि आप डुप्लिकेट कोड को समाप्त करने की प्रक्रिया में आप एक बहुत ही लचीली सामान्यीकृत अमूर्तता बनाते हैं, तो आप गलत तरीके से चले गए होंगे।

यह हमें अगले बिंदु पर ले जाता है - इरादा बनाम व्यवहार।

प्रोग्रामर का इरादा अर्थहीन है - व्यवहार का मतलब सब कुछ है

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

आइए इस उदाहरण को देखें, जो प्रोग्रामर के इरादों को बहुत अच्छी तरह से दर्शाता है, लेकिन जैसा इरादा है वैसा व्यवहार नहीं करता है:

 function LastModified(props) { return ( <div> Last modified on { props.date.toLocaleDateString() } </div> ); } 

जाहिर है, प्रोग्रामर ने योजना बनाई कि यह रिएक्ट घटक "अंतिम संशोधित" संदेश के साथ एक तारीख प्रदर्शित करेगा। क्या यह इरादा के अनुसार काम करता है? वास्तव में नहीं। क्या होगा अगर यह। Prop.date कोई फर्क नहीं पड़ता सब कुछ बस टूट जाता है। हमें पता नहीं है कि क्या यह कल्पना की गई थी, या कोई व्यक्ति इसके बारे में भूल गया था, और यह भी मायने नहीं रखता है। व्यवहार क्या मायने रखता है।

और यह वही है जो हमें पता होना चाहिए कि क्या हम कोड के इस हिस्से को बदलना चाहते हैं। कल्पना करें कि हमें लाइन को "अंतिम संशोधन" में बदलने की आवश्यकता है। हालांकि हम ऐसा कर सकते हैं, लेकिन यह स्पष्ट नहीं है कि यदि तारीख गायब है तो क्या होना चाहिए। बेहतर होगा कि हम इसके बजाय घटक को इस तरह से लिखें ताकि उसके व्यवहार को अधिक समझ में आ सके।

 function LastModified(props) { if (!props.date) { throw "LastModified requires a date to be passed"; } return ( <div> Last modified on { props.date.toLocaleDateString() } </div> ); } 

या इस तरह भी:

 function LastModified(props) { if (props.date) { return ( <div> Last modified on { props.date.toLocaleDateString() } </div> ); } else { return <div>Never modified</div>; } } 

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

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

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

वैचारिक लागत भ्रम और जटिलता में योगदान करती है

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

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

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

जब हम कोड या डिज़ाइन सॉफ़्टवेयर लिखते हैं, तो हमें अपने कोड की लालित्य , सुंदरता, या अन्य व्यक्तिपरक माप के बारे में सोचना बंद कर देना चाहिए। इसके बजाय, हमें हमेशा याद रखना चाहिए कि हम सॉफ्टवेयर के साथ क्या करने जा रहे हैं।

आप दीवार पर कोड नहीं लटकाते हैं - आप इसे बदलते हैं

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

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

जब आप अपना कोड लिखते हैं या अपना सिस्टम डिज़ाइन करते हैं, तो क्या आप सिस्टम व्यवहार की व्याख्या को सरल बनाते हैं? क्या यह समझना आसान हो जाता है कि वह कैसे व्यवहार करेगी? क्या आप अपने सामने समस्या को सुलझाने पर ध्यान केंद्रित कर रहे हैं या एक अधिक सार पर?

हमेशा प्रदर्शन, भविष्यवाणी और समझ के लिए व्यवहार को सरल रखने की कोशिश करें, और अवधारणाओं की संख्या को पूर्णतम रखें।