"पहिए को फिर से लगाना" के विपरीत एंटीपैटर्न का क्या नाम है? [बन्द है]

Question

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

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

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

क्या इस तरह के एंटीपैटर के लिए एक सामान्य नाम है?

_{(मैं सही या गलत होने पर चर्चा शुरू करने की कोशिश नहीं कर रहा हूं, या अगर यह एक वास्तविक एंटीपैर्टन है या कुछ भी राय आधारित है , तो यह एक सरल और उद्देश्यपूर्ण नामकरण प्रश्न है।)}

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

Comments

निर्भरता नरक । मैं उसके बारे में सबसे ज्यादा सोच सकता हूं।

— मचाडो

@ मचाडो: अच्छा, हालांकि मैं कहूंगा कि डिपेंडेंसी हेल ​​इस एंटी-पैटर्न की प्रचुरता का प्रत्यक्ष परिणाम है; अत्यंत जटिल प्रणालियों के मामले में यह जटिलता का सीधा परिणाम हो सकता है।

— एसएफ।

मैं इसे कहेंगे "निर्भरता क्रीप" करने के लिए अनुरूप Feature_creep या Scope_creep जहां अधिक से अधिक मूल रूप से अवांछित सुविधाओं उत्पाद से जुड़ जाते हैं।

— k3b

Tle left-pad fiasco एक्शन में इस सिंड्रोम का वास्तविक जीवन उदाहरण है।

— एसएफ।

मैं सलाह देता हूं कि हम सामूहिक रूप से इसे वामपंथी के रूप में संदर्भित करना शुरू करें।

— रबरडक

Answer 1

नहीं, आमतौर पर इस्तेमाल किया जाने वाला एंटी-पैटर्न नाम नहीं है जो आपके द्वारा वर्णित किया जा रहा है।

Comments

यह विचारों, सुझावों और चर्चा की संख्या के साथ प्रकट होता है, यह वास्तव में सही है।

— एसएफ।

मुझे ऐसा करने में गंदा लग रहा है।

— एसएफ।

है ना? "कोई XXX नहीं है" एक बहुत ही मजबूत कथन है और यह साबित करने के लिए बहुत कठिन है, खासकर यह देखते हुए कि टिप्पणियों में कई उम्मीदवारों का उल्लेख है।

— AnoE

@AnoE "क्या इस तरह के एंटीपैटर के लिए एक सामान्य नाम है?" उक्त टिप्पणियों और उत्तरों में मौजूद प्रमाणों का तात्पर्य है कि ऐसा नहीं है। सच है, यह शीर्षक का जवाब नहीं देता है, लेकिन यह सवाल का जवाब देता है।

— क्रोल्टन

@ आप एक नकारात्मक, सम्मान साबित नहीं कर सकते। हो सकता है कि यह शब्द बोर्नियो में कहीं चट्टान के नीचे छिपा हो और हम अभी तक इसके ऊपर नहीं गिरे हैं? 1 के बजाय 10 उत्तर के साथ 10 उत्तर मेरे लिए पर्याप्त प्रमाण हैं।

Answer 2

गोल्डन हैमर

सुनहरा हथौड़ा केवल चुना हुआ उपकरण है क्योंकि यह फैंसी है। यह इच्छित कार्य करने में न तो लागत प्रभावी है और न ही कुशल।

स्रोत: xkcd 801

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

Comments

Upvoted, और आप इसे विकिपीडिया से भी स्रोत कर सकते हैं: en.wikipedia.org/wiki/Anti-pattern , en.wikipedia.org/wiki/Law_of_the_instrument

— Pierre.Sassaas

अगर मैं प्रतिनिधि होता तो मैं इसे ठुकरा देता। यह संपूर्ण रूप से प्रश्न का उत्तर नहीं देता है, लेकिन एक (सटीक) शब्द प्रदान करता है जो सुझाए गए परिदृश्यों में से केवल एक का उत्तर देता है।

— डेविड

इसके विपरीत पूछा गया था। यह इस बात पर जोर देने जैसा है कि "बेकरेल" (विकिरण, इकाई s ^ -1 है) का उपयोग संगीत के बजाय हर्ट्ज़ (hz, इकाई s ^ -1) के लिए किया जा सकता है क्योंकि उनका अर्थ "प्रति सेकंड" है।

— थोरबजोरन रेव एंडरसन

@ ThorbjørnRavnAndersen मैंने अपने दिन में कुछ बहुत खतरनाक संगीत सुना है।

Answer 3

रॉबर्ट मार्टिन इस एंटी-पैटर्न के सबसे स्पष्ट नकारात्मक परिणाम को संदर्भित करने के लिए " फ्रेमवर्क बाउंड " शब्द का उपयोग करता है । जैसा कि मुझे नहीं लगता कि पैटर्न के लिए कोई सामान्य नाम है, इस परिणाम का एक संदर्भ अधिकांश उद्देश्यों के लिए पर्याप्त हो सकता है।

Comments

विकास प्रक्रिया को गति देने के लिए फ्रेमवर्क मौजूद हैं। वे एक बूस्टर रॉकेट की तरह हैं: जैसे ही इस्तेमाल किया जाता है। समाधान है - रिलीज़ संस्करण एक, अब हम कहाँ थे? यह सही है, विकासशील सॉफ्टवेयर। आगे! रखरखाव एक अलग चिंता है, और मुझे लगता है, इन दिनों महत्वहीन होना चाहिए। अगले समाधान के लिए अगले ढांचे को लें, जल्दबाजी पोस्ट करें।

Answer 4

" इन्वेंटेड हियर " पर यह विकिपीडिया पेज थोड़ा अलग स्थिति का वर्णन करता है लेकिन बहुत ही समान परिणाम के साथ। जब समान कार्यक्षमता वहां पाई जा सकती है तो अपने स्वयं के कोड बनाने की दिशा में एक टीम के फैलाव का वर्णन करता है।

मैं तर्क दूंगा कि नाम थोड़ा भ्रामक है। जब यह इसके विपरीत नहीं है के साथ संदर्भ में डाल दिया जाता है, तो समझ में आता है कि IMHO जो पहिया को फिर से तैयार करने के लिए एक पर्याय है।

Answer 5

मैंने "इन वर्सेस बिल्ड खरीदें " और " इन्वेंटेड हियर " को इन-हाउस के रूप में विकासशील चीजों के खिलाफ पूर्वाग्रह के लिए एंटी-पैटर्न नामों के रूप में सुना है , तब भी जब ऐसा करने का कोई मतलब हो सकता है। (और भले ही वाक्यांश "खरीदें बनाम निर्माण" व्यवहार्य विकल्पों के बीच एक विकल्प को इंगित करने के लिए माना जाता है, मुझे लगता है कि यह आमतौर पर उल्लेख किया जाता है जब कोई मानता है कि "खरीदना" सही विकल्प है।)

Answer 6

मच्छर मारने के लिए तोप का इस्तेमाल न करें

कन्फ्यूशियस

AKA ओवरकिल

Comments

आम (यूके) अंग्रेजी वाक्यांश "अखरोट को तोड़ने के लिए स्लेजहैमर का उपयोग" है।

— nigel222

संबंधित मोंटी पाइथन स्केच

— स्टेडीबॉक्स

यह भी: "हिरण शिकार एक टैंक के साथ"

— Jeutnarg

"स्वाटिंग एक हथौड़ा के साथ उड़ती है"

मक्खी को मारने के लिए हथौड़े का प्रयोग न करें

— jeffmcneill

Answer 7

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

यदि हम चाहें, तो हम एक अवधि के साथ स्पष्ट कर सकते हैं जैसे फूला हुआ निर्भरता ।

Answer 8

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

वाक्यांश का यह भी फायदा है कि यह शब्दजाल की गणना नहीं कर रहा है, इसलिए यह किसी ऐसे व्यक्ति का सुराग लगाने में बहुत मददगार हो सकता है जिसके पास कोई नहीं है।

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

Answer 9

मुझे नहीं लगता कि कोई सटीक सादृश्य है , लेकिन मैं कहूंगा कि ओवरडिजाइन या अतिरंजना निकटतम आती है।

कम से कम, मैं तर्क दूंगा कि यह वही है जो वास्तव में चल रहा था जब मैंने आपके वर्णन के समान कुछ का सामना किया।

समान कार्यक्षमता को लागू करने के लिए अपना स्वयं का कोड लिखने के बजाय लाइब्रेरी का उपयोग करना लगभग कभी हानिकारक नहीं होता है।

यहां तक ​​कि आपके काल्पनिक उदाहरण में, "कोड की दो पंक्तियों" को बदलने के लिए एक पुस्तकालय का उपयोग करना आवश्यक नहीं हो सकता है, लेकिन इससे आपको बहुत दुःख होने की संभावना नहीं है - यदि यह वास्तव में एक पुस्तकालय है जो कोड की आपकी दो पंक्तियों के समान है। ।

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

कुछ सरल करने के लिए एक जटिल पुस्तकालय का उपयोग करना संभवतः यह दर्शाता है कि आप आवश्यक कार्यक्षमता को लागू करने से अधिक करने की कोशिश कर रहे हैं।

जैसे कि उन सुविधाओं का निर्माण, जिनकी आवश्यकता नहीं है, एक ऐसे भविष्य की तैयारी करें जो कभी न आए, आदि।

यहाँ समस्या वास्तव में प्रति पहिया को सुदृढ़ करने में विफलता नहीं है ।

Answer 10

यदि आपने पहिया का फिर से आविष्कार नहीं किया है, तो सबसे अधिक संभावना है कि विक्रेता या तीसरे पक्ष द्वारा प्रदान किए गए पहियों के एक मौजूदा सेट का उपयोग किया जाता है।

यदि यह एक विरोधी पैटर्न है, तो इसे आमतौर पर विक्रेता लॉक-इन कहा जाता है।

Comments

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

— बेन

@ - ठीक है, मुझे फ्रेमवर्क बाउंड पसंद है, जो बेहतर तरीके से वेंडर लॉक के विपरीत है। यह प्रश्न एक तरह का राय आधारित है और यह पहली चीज थी जो मेरे सिर में आ गई थी।

— जॉन रेन्नोर

Answer 11

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