मजबूत कोड बनाम अतिरंजना लेखन

33

आप लोगों को कैसे पता चलेगा कि आप बिना ओवरगेंरिंग के सबसे मजबूत कोड लिख रहे हैं?

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

self-improvement programming-practices

— फ्रां सेविलानो
स्रोत

2

इसे Agda2 में कोड करें

— लॉजिक

एक ठोस उदाहरण आपकी बात बनाने में बहुत मदद करेगा। :)

— जोआओ पोर्टेला

क्या मैं सिर्फ यह जांच सकता हूं कि आप वास्तव में मजबूती के बारे में पूछ रहे हैं, अर्थात "अमान्य इनपुट या तनावपूर्ण पर्यावरणीय परिस्थितियों की उपस्थिति में काम करने के लिए एक प्रणाली की क्षमता", क्योंकि कुछ जवाबों से लगता है कि आप विस्तार के बारे में बात कर रहे हैं।

— डीजेकवरवर्थ

मैं पागल समय सीमा के तहत काम करता हूं, यह डेमो-वेयर के लिए है, इसलिए मैं पूर्णता पक्षाघात के बिना खुशी से तेजी से हैक कर सकता हूं।

— नौकरी

1

यहाँ एक लेख है जो विषय के बारे में बात करता है: code-tag.com/2017/04/02/…

— San

39

आप लोगों को कैसे पता चलेगा कि आप बिना ओवरगेंरिंग के सबसे मजबूत कोड लिख रहे हैं?

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

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

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

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

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

सरलता मजबूत है, जटिलता नाजुक है।

जटिलता मार देती है।

— बाज़
स्रोत

2

क्योंकि इसमें बहुत सारी कक्षाएं, कारखाने और सार नहीं हैं। यह एक विरोधाभास है, लेकिन कुछ लोग उस सामान को पसंद करते हैं। पता नहीं क्यों।

— कोडर

5

यह स्पार्टा है!!!

— टॉम स्क्वायर्स

4

जो लोग बीस साल से ऐसा नहीं कर रहे हैं उन्हें यह पता नहीं है कि जटिलता आपको कैसे मार सकती है। उन्हें लगता है कि वे बहुत स्मार्ट हैं। वे गूंगे हैं, स्मार्ट नहीं हैं। यह जटिलता आपको मृत करने जा रही है।

— पीटरएलेनवेब सेप

1

लचरता भविष्य-प्रूफिंग के बारे में नहीं है - यह अमान्य इनपुट या तनावपूर्ण वातावरण के साथ कार्य करना जारी रखने के बारे में है - कोड पूरा p464।

— डीजेकवर्थ

5

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

— डीजेकेवर्थ

8

मैं एक संतुलन बनाए रखने की कोशिश करता हूं, जिस पर ध्यान केंद्रित किया जाए

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

यह एक फजी बॉर्डर क्षेत्र है - कभी-कभी मैं कुछ अनावश्यक काम करने का प्रबंधन करता हूं, कभी-कभी मैं कुछ ऐसा करने में विफल रहता हूं जो बाद में आवश्यक हो जाता है। अगर मिसेज बड़ी नहीं हैं, तो मैं ठीक हूं। किसी भी दर पर, मैं अपनी गलतियों से सीखने का प्रयास करता हूं।

— पेटर टॉर्क
स्रोत

मौजूदा उपयोग के मामलों में सभी संभावित निष्पादन पथों को संभालने के

— कोडयोगी

5

मजबूत और अतिरंजना के बीच का अंतर सुंदर रूप से सभी संभव उपयोग के मामलों को संभालने के बीच का अंतर है, यहां तक कि विचित्र और फ्रिंज उपयोग मामलों में भी होता है जो SHOULDN'T होता है। जब मैं शालीनतापूर्वक कहता हूं तो मेरा मतलब है कि उपयोगकर्ता एक विचित्र अपवाद मामले में प्रवेश करता है या एक ऐसी स्थिति में चलता है जो एक असमर्थित या अनिर्दिष्ट सुविधा के लिए कॉल करता है जिसे परिभाषित नहीं किया गया था और कोड बिना किसी कार्यक्षमता के उपयोगकर्ता को दुर्घटनाग्रस्त हो जाता है या सूचित करता है।

दूसरी ओर अतिरंजना उन विशेषताओं के पूर्ण कार्यान्वयन के दायरे में आ सकती है जिनकी आवश्यकता नहीं थी या जिनके लिए (कुछ विशेषताएं जो क्लाइंट की आवश्यकता है, लेकिन कभी भी नहीं पूछी गई!) के लिए इसे पूरा किया जा सकता है या इसे अत्यधिक जटिल डिज़ाइन या ओवरऑल कॉम्प्लेक्स प्राप्त करके परिभाषित किया जा सकता है। एक अपेक्षाकृत सरल समस्या को संभालने के लिए कोड।

— मेपल_शाफ्ट
स्रोत

4

1) आवश्यकताएँ प्राप्त करें।

2) आवश्यकताओं को पूरा करने के लिए न्यूनतम कोड लिखें। अगर कुछ अस्पष्ट है, तो एक शिक्षित अनुमान लगाएं। अगर यह सुपर है अस्पष्ट है, तो 1 पर वापस जाएं।

3) परीक्षण के लिए भेजें।

4) यदि परीक्षक अच्छा कहते हैं, तो अनुमोदन का दस्तावेजीकरण करें। अगर कुछ बंद है, तो 1 पर वापस जाएं।

परीक्षणों की भविष्यवाणी पर ध्यान दें, परीक्षणों की भविष्यवाणी नहीं। यदि आपके पास परीक्षक नहीं हैं ... परीक्षक प्राप्त करें! वे न केवल कोड शुद्धता की पुष्टि करने के लिए, बल्कि संपूर्ण विकास प्रक्रिया के लिए आवश्यक हैं।

— मॉर्गन हेरलॉकर
स्रोत

1

टेस्ट पास करने पर फोकस के लिए, टेस्ट की भविष्यवाणी न करते हुए, हालांकि, खुद जैसे कई डेवलपर्स को मजबूत कारोबारी विश्लेषकों की कमी के बावजूद दोनों करने की उम्मीद है।

— maple_shaft

@maple_shaft - बहुत सही। मुद्दा यह है कि ये समस्याएं किसी और की अक्षमता के कारण उत्पन्न होती हैं। किसी और की नौकरी से बाहर निकलना ज्वलन का रास्ता है। यदि मेरी कंपनी मुझे उस महीने के लिए प्राप्य करने के लिए पर्याप्त रूप से गूंगी थी, तो मैं अपने आप में बहुत निराश नहीं होता अगर यह अच्छी तरह से नहीं होता। आवश्यकताओं को परिभाषित करना आमतौर पर केवल यह बताता है कि आप रोज क्या करते हैं, ताकि यह स्वचालित हो सके। अगर कर्मचारियों में से कोई भी ऐसा नहीं कर सकता है, तो ठीक है ... कंपनी मुश्किल में पड़ सकती है।

— मॉर्गन हेरलॉकर

3

पहली जगह में, डेटा को सामान्यीकृत करें (निरर्थक नहीं) जितना आप कर सकते हैं। यदि डेटा पूरी तरह से सामान्यीकृत है, तो डेटा का एक भी अपडेट इसे असंगत नहीं बना सकता है।

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

सूचनाओं के माध्यम से कसकर अतिरेक को प्रबंधित करने की कोशिश करने की एक मजबूत प्रवृत्ति है। यह न केवल सुनिश्चित करने के लिए मुश्किल है कि वे सही हैं, बल्कि भारी अक्षमताओं को जन्म दे सकते हैं । (सूचनाएं लिखने के प्रलोभन का एक हिस्सा इसलिए उठता है क्योंकि OOP में वे व्यावहारिक रूप से प्रोत्साहित होते हैं।)

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

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

— माइक डनलवे
स्रोत

3

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

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

आपके परीक्षण तब आपके कार्यक्रम की क्षमताओं को परिभाषित करेंगे और वे कितने मजबूत होंगे - जब तक आप सफलता की दर और इनपुट से संतुष्ट नहीं हो जाते, तब तक परीक्षण जोड़ते रहें; आवश्यकतानुसार सुधार, विस्तार और सुदृढ़ीकरण।

— जस्टिन
स्रोत

2

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

— thiton
स्रोत

2

मजबूतता: अमान्य इनपुट या तनावपूर्ण पर्यावरणीय परिस्थितियों की उपस्थिति में एक प्रणाली जिस पर कार्य करना जारी रखती है। (कोड पूरा 2, p464)

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

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

इसलिए यह असामान्य त्रुटि स्थितियों के लिए चेक करने के पक्ष में वास्तव में बेहतर है। लेकिन एक संतुलन है। इस संतुलन पर विचार करने के लिए कुछ चीजें:

यह त्रुटि कितनी बार हो सकती है?
इस त्रुटि के होने की लागत क्या है?
क्या यह आंतरिक या बाहरी उपयोग के लिए है?

यह मत भूलो कि लोग अप्रत्याशित कार्यक्रमों में अपने कार्यक्रम का उपयोग करने की कोशिश कर सकते हैं - और करेंगे। यह बेहतर है अगर कुछ अनुमान लगाने योग्य होता है जब वे करते हैं।

बचाव की अंतिम पंक्ति के रूप में, मुखर या शटडाउन का उपयोग करें। अगर कुछ ऐसा होता है, जिससे आप काम नहीं कर सकते, तो उससे कैसे निपटें, कार्यक्रम को बंद कर दें। यह आमतौर पर कार्यक्रम को जाने और कुछ अप्रत्याशित करने की अनुमति देने से बेहतर है।

— DJClayworth
स्रोत