क्या पहिया को फिर से मजबूत करना सब बुरा है?


101

प्रोग्रामिंग में इसका सामान्य ज्ञान यह है कि पहिया को सुदृढ़ करना बुरा या बुरा है

लेकिन ऐसा क्यों है?

मैं सुझाव नहीं दे रहा हूं कि यह अच्छा है। मैं इसे गलत मानता हूं। हालाँकि, मैंने एक बार एक लेख पढ़ा था जिसमें कहा गया था, अगर कोई व्यक्ति कुछ गलत कर रहा है (प्रोग्रामिंग वार) उन्हें समझाएं कि इसका गलत क्यों है, यदि आप नहीं कर सकते हैं, तो शायद आपको खुद से पूछना चाहिए कि क्या यह वास्तव में गलत है।

मुझे इस प्रश्न की ओर ले जाता है:

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

क्यों वह अपने दम पर एक में निर्मित का उपयोग करना चाहिए?


16
यह एक बड़ा सवाल है। मुझे नहीं लगता कि लोगों को पहिया को फिर से मजबूत करना चाहिए, लेकिन यह सुनिश्चित करने के लिए इन विचारों को चुनौती देना महत्वपूर्ण है कि वे पकड़ रखें।
जॉन हॉपकिंस 15

4
@ डेमियन - यह वास्तव में एक बहुत अच्छा विचार है। यदि आप इसे समझा सकते हैं तो आप इसे करने में शायद उचित हैं।
जॉन हॉपकिंस

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

5
यदि मौजूदा पहिये वास्तव में आपकी विशिष्ट आवश्यकता के लिए ट्रिक नहीं करते हैं, या ... यदि आप जानना चाहते हैं कि पहिए कैसे काम करते हैं! इस विषय पर एक दिलचस्प लेख: codinghorror.com/blog/2009/02/…
19

4
डगलस The good thing about reinventing the wheel is that you can get a round one.
क्रॉकफोर्ड में शामिल

जवाबों:


71

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


14
+1 सबसे महत्वपूर्ण बिंदु यह है कि यह पूरी तरह से आपके नियंत्रण में है और आप इसे अंदर से जानते हैं। अन्य पुस्तकालयों को डीबग करना, मुख्य सिरदर्द पैदा कर सकता है, यदि संभव हो तो, और यह कहना कि सभी परिपक्व पुस्तकालय बग मुक्त हैं, कम से कम कहने के लिए आशावादी हैं।
15

6
एक्सेल टीम यहां तक ​​कि अपने स्वयं के संकलक को लिखने के लिए चली गई क्योंकि वे कोई बाहरी निर्भरता नहीं चाहते थे जो परियोजना को प्रभावित कर सकते हैं। यह एक मान्य बिंदु है लेकिन यह कितना महत्वपूर्ण है कि नियंत्रण मुख्य प्रश्न है।
जॉन हॉपकिंस 15

6
+1। एक बार MFC / VC ++ प्रोग्रामर के रूप में मेरे पूर्व जीवन में, हमने विभिन्न GUI घटकों के लिए एक तीसरे पक्ष के पुस्तकालय का उपयोग किया, जो बनाए रखने के लिए कुल दुःस्वप्न बन गया। ये चीजें सॉफ़्टवेयर में गहराई से आदी हो गईं और इन्हें हटाया नहीं जा सकता (बिना खर्च किए मानव-जन-महीने-जो-हम-हमने-प्रयास का नहीं है)। मुझे पूरा विश्वास है कि किसी भी शुरुआती समय की बचत से हमारे स्वयं के ग्रिड और लेआउट प्रबंधकों को रोल नहीं करने के कारण उस राक्षसीपन को बनाए रखने के वर्षों से परिमाण के आदेशों से उड़ा दिया गया था।
बॉबी टेबल्स

4
@ गुज़िका, एक दुर्भाग्यपूर्ण विकल्प आवश्यक रूप से सामान्य बनाने के लिए पर्याप्त नहीं है, और अन्य पुस्तकालय मौजूद हैं जो अच्छी तरह से बनाए हुए हैं और एक अच्छा विकल्प है। सवाल यह है कि क्या मूल निर्णय पर पर्याप्त शोध किया गया था?

5
उल्टा, यदि आप पहले से मौजूद पहिये का उपयोग करते हैं, तो आपको आमतौर पर Google द्वारा मदद की जाती है, जिसे अक्सर Google द्वारा अनुक्रमित किया जाता है, ताकि आप इसे डीबग करने में सहायता कर सकें।
डेन रे

81

निर्भर करता है ..

सब कुछ के साथ, संदर्भ के बारे में:

यह अच्छा है जब:

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

यह बुरा है जब:

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

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

1
मेरे लिए छल्ले को समझना मुश्किल है। मैं सिर्फ निर्देशित ग्राफ विश्लेषण नहीं कर रहा था इसलिए एक बना, और अब मुझे पता है। अब मैं एक ढांचे का उपयोग करने के लिए आश्वस्त महसूस कर रहा हूं
JasTonAChair

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

55

मुझे लगता है कि एक डेवलपर का मामला जानबूझकर पहिया को फिर से मजबूत करना है "क्योंकि वह अपनी पद्धति को पसंद करता है" बहुत दुर्लभ है। ज्यादातर यह अज्ञानता से बाहर किया जाता है, और कभी-कभी हठ के बाहर।

क्या यह सब बुरा है? हाँ। क्यों? क्योंकि मौजूदा पहिये को समय के साथ सबसे अधिक तैयार किया गया है और पहले से ही बहुत सारी परिस्थितियों में और विभिन्न प्रकार के डेटा के खिलाफ परीक्षण किया जा चुका है। मौजूदा पहिये के डेवलपर (ओं) को पहले से ही किनारे-मामलों और कठिनाइयों का सामना करना पड़ा है जो कि पुनर्निवेशक अभी तक कल्पना भी नहीं कर सकता है।


3
या आलस्य - कि विकल्प के लिए जाने और देखने के लिए परेशान नहीं किया जा सकता है या कोड को लिखने के लिए जाना और ऐसा करना कम दिलचस्प लगता है।
जॉन हॉपकिंस

9
मैंने कई मामलों को देखा है जहां पहिया का फिर से आविष्कार किया गया था, घमंड से बाहर किया गया था, एक दृष्टिकोण के साथ कि लाइब्रेरी / फ्रेमवर्क xyz केवल खराब प्रोग्रामर के लिए है जो यह नहीं जानता था कि यह "सही तरीका" कैसे करना है। हेक, मैंने एसओ साइटों पर उस तर्क (कुछ फैशन या किसी अन्य में) को देखा है।
बिल

2
... जो वर्तमान या बाद के डेवलपर्स पर रखरखाव का एक आवर्ती (सबसे खराब तरह) बोझ बनाता है।
गहुआ

2
यह वही है जो मैं वर्षों से कर रहा था। मैं अपनी सुविधा को किसी भाषा में रोल करूंगा क्योंकि मुझे पता नहीं था कि कार्यक्षमता पहले से ही अंतर्निहित थी।
माचिस

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

22

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

बस उससे पूछें कि क्या कमी है।


9
+1 अच्छा रूपक "वर्ग पहियों को फिर से मजबूत करना होगा"
परिक्रमा

+1 के लिए "स्क्वायर व्हील्स को फिर से बनाना होगा"
टिंटु सी राजू

17

सामान्य तौर पर, मैं पहिया को फिर से स्थापित करने से बचता हूं अगर मैं चाहता हूं कि कार्यक्षमता, या कुछ इसे सन्निकट कर दे, जो भाषा मैं उपयोग करता हूं उसके मानक पुस्तकालय में मौजूद है ।

हालाँकि, अगर मुझे थर्ड पार्टी लाइब्रेरीज़ को शामिल करना है, तो यह एक निर्णय कॉल है जो इस बात पर निर्भर करता है कि लाइब्रेरी का व्यापक रूप से उपयोग और सम्मान कैसे किया जाता है। मेरा मतलब है, क्या हम बूस्ट या बॉब के किक-गधा स्ट्रिंग-पार्सिंग टूल्स 1.0 के बारे में बात कर रहे हैं ?

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

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

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

तो यह वास्तव में एक संतुलन अधिनियम है। लेकिन बात यह है कि बस आँख बंद करके कह रहे हैं "कोड का पुन: उपयोग अच्छा है! पहिया खराब होना!" एक खतरनाक रवैया है। तृतीय-पक्ष कोड का लाभ उठाने के लिए निर्भरता शुरू करने के नुकसान के खिलाफ तौला जाना चाहिए।


3
+1। मैं उसी तरह महसूस करता हूं। यदि छोटे पहिए को फिर से चालू करने के लिए मैं अधिक इच्छुक हूं, तो मौजूदा पहिये का उपयोग करने से निर्भरता की समस्या पैदा होगी यदि मौजूदा पहिया पहले से ही है, तो सेट करें और प्रतीक्षा करने के लिए किसी भी वातावरण में उपयोग किया जाए जहां मुझे इसकी आवश्यकता हो सकती है।
dsimcha

14

अगर लोगों ने पहियों को फिर से नहीं लगाया, तो दुनिया इनसे भर जाएगी। यहाँ छवि विवरण दर्ज करें

यहाँ मेरे कार्यस्थल से एक संवाद है:

- I would like to add some colors to the output of this program.
- Oh, there is this library called Colorama ..

दो विकल्प हैं: या तो पहिया को फिर से मजबूत करें या Colorama का उपयोग करें। यहां बताया गया है कि प्रत्येक विकल्प क्या होगा:

Colorama का उपयोग करना

  • शायद दौड़ने में थोड़ा तेज हो
  • किसी तुच्छ के लिए तीसरे पक्ष की निर्भरता जोड़ना
  • आप Colorama का उपयोग करने से पहले बेवकूफ के रूप में जारी है

पहिया बदलते

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

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


2
+1 आपके साथ 100% सहमत नहीं है लेकिन विचार व्यक्त करने के लिए उपयोग की गई छवि पसंद करता है।
ट्यूलेंस कोर्डोवा

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

2
@ नीलहॉटन, जैसा कि मैं देख रहा हूं कि यह मेरा "अपना" शैक्षिक लाभ है, मेरे नियोक्ता का भी लाभ है।
पिथिकोस

हम्म ... आपके नियोक्ता बेशक इसे इस तरह से नहीं देख सकते हैं, और वह आपकी टेबल पर रोटी डाल रहा है।
नील हैटन

लाइब्रेरी रंगामा, अपने आप में एक पहिये का पुनर्निमाण था। टर्मिनल में रंगों को प्रदर्शित करने के लिए पहले से ही एक इंटरफ़ेस था (विशेष वर्णों के माध्यम से) और इससे पहले कि बाहर आए लोग पहले से ही कर रहे थे। Colorama पुस्तकालय लक्ष्य को प्राप्त करने के लिए इंटरफ़ेस को पुन: स्थापित करता है। तो यहाँ सवाल यह है कि क्या आप एक कथित रूप से बेहतर पहिये का उपयोग करने वाले हैं, या आप अपनी परियोजना में एक पुराने पहिये का उपयोग करते हैं? इस मामले में पहिया को फिर से रंगनामा 2 का निर्माण कर रहा होगा जो कि रंगामा के प्रस्ताव के ऊपर "सुधार" करता है।
स्की

13

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

एक और बात - अगर कोई चिंता गायब हो सकती है एक कंपनी से तीसरे पक्ष के पुस्तकालय पर निर्भर करता है, सुनिश्चित करें कि स्रोत कोड प्राप्त करने के लिए एक विकल्प है, या कम से कम कुछ अन्य विकल्प वहां से वापस आने के लिए।

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


+1 शिक्षण परिप्रेक्ष्य पर एक बहुत अच्छा बिंदु, एक पुस्तकालय का प्रभावी ढंग से उपयोग करने के लिए, आपको वास्तव में यह जानना चाहिए कि यह कैसे काम करता है। मुझे उपकरणों का ब्लैक बॉक्स उपयोग पसंद नहीं है। क्रिप्टोग्राफी पुस्तकालयों पर भी उत्कृष्ट बिंदु, उस स्कोर पर अपना खुद का रोल करने के लिए बहुत जोखिम भरा।
परिक्रमा

मुझे लगता है कि अगर वहाँ एक चिंता है कि तीसरे पक्ष के पुस्तकालय गायब हो सकता है, यह एक प्रोग्राम इंटरफ़ेस है कि एक पुस्तकालय आसानी से दूसरे के लिए बाहर स्वैप करने की अनुमति देता है लिखने के लिए एक बहुत अच्छा औचित्य है।
user8865

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

9

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

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

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

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

अपने स्वयं के रोल करने के कारण हैं - बड़े पैमाने पर जहां आप कुछ ऐसा करना चाहते हैं जो निर्मित फ़ंक्शन नहीं कर सकता है और जहां ऐसा करने से वास्तविक लाभ प्राप्त होता है, या जहां आसानी से उपलब्ध विकल्प परिपक्व नहीं होते हैं - लेकिन वे कई डेवलपर्स की तुलना में आपको कम विश्वास होगा।

इसके अलावा, आप पहले से ही हल की गई समस्याओं को सुलझाने में अपना समय क्यों बिताना चाहेंगे? हां यह सीखने का एक शानदार तरीका है, लेकिन आपको उत्पादन कोड के लिए सही समाधान की कीमत पर ऐसा नहीं करना चाहिए जो मैं मान रहा हूं कि हम किस बारे में बात कर रहे हैं।


2
आपकी अंतिम पंक्ति में: यह जानने के लिए कि वे कैसे हल किए जाते हैं। प्रोग्रामिंग आखिर अनुभव पर निर्भर है।
परिक्रमा

@Orbling - पर्याप्त रूप से उचित है, लेकिन आपको उत्पादन कोड में ऐसा नहीं करना चाहिए और मैं यह मान रहा हूं कि प्रश्न क्या संदर्भित करता है। संशोधन करेंगे।
जॉन हॉपकिंस

@Jon हॉपकिंस: अच्छी तरह से उत्पादन कोड आमतौर पर सीखने से चलता है, जब तक कि आपके समय पर नहीं किया जाता।
परिक्रमा

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

@ जौन हॉपकिंस: आदर्श रूप से हां, लेकिन अक्सर टीम में कोई भी ऐसा नहीं होता है जो जानता है कि यह कैसे करना है, इस बिंदु पर जहां उपलब्ध पुस्तकालय विश्वसनीय रूप से सेवा करने योग्य नहीं हो सकते हैं। सीखना, या "अनुसंधान" जैसा कि ज्यादातर लोग इसे कहते हैं, तब यह एक आवश्यकता है। हां, यह सीखने के लिए बिल्कुल नहीं है, लेकिन यह भविष्य के जोखिम से बचने के लिए सीख रहा है।
परिक्रमा

9

बेशक पहिया को एक ज़ोर पर रोकना, अज्ञानता और अहंकार से बाहर निकलना एक बुरी बात हो सकती है, लेकिन IMHO पेंडुलम बहुत दूर निकल गया है। वहाँ एक पहिया है कि करता है करने के लिए एक जबरदस्त लाभ है वास्तव में क्या आप चाहते हैं और अधिक कुछ नहीं

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

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

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

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

5

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

कोड के लिए बहुत कुछ है, और जब तक यह उत्पादन को प्रभावित नहीं करता है तब तक मुझे वापस जाने और कुछ को फिर से कोड करने के लिए बहुत समय नहीं मिलता है।

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


2
यही कारण है कि इसे बदलने के लिए नहीं, यह पहली जगह में नहीं है। मुझे लगता है कि आप अब यह नहीं जानते कि विकल्प मौजूद है?
जॉन हॉपकिंस 15

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

4

पहिया को फिर से तैयार करना यह जानने का एक शानदार तरीका है कि पहिया कैसे काम करता है, लेकिन यह कार बनाने का एक अच्छा तरीका नहीं है।


4

मैं वर्तमान में चीकपेट्स के एक समूह के लिए काम करता हूं।

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

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

बिल्ड बनाम खरीद पर प्रस्तुति
बिल्ड बनाम खरीद पर अनुच्छेद

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

क्यों वह अपने दम पर एक में निर्मित का उपयोग करना चाहिए?

बिल्ट-इन संस्करण में बहुत अधिक लोगों को इस पर धमाका करते देखा होगा - इस प्रकार आपके होमब्रेव कोड की तुलना में अधिक बग्स को ढूंढना और ठीक करना कभी भी हो सकता है।

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


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

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

क्या आप यह नहीं भूल रहे हैं कि आपके गुमराह चेप्सकैट नियोक्ता प्रभावी रूप से आपको अधिक भुगतान किए गए काम प्रदान कर रहे हैं जो आपके पास अन्यथा हो सकता है? आपको इसके बारे में शिकायत करने के बजाय उन्हें प्रोत्साहित करना चाहिए!
नील हैटन

4

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

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

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


4

पहिया का फिर से आविष्कार करना या न करना एक लागत / लाभ की बात है। लागत काफी स्पष्ट है ...

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

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

फायदे हो सकते हैं ...

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

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


3

यदि एक कार्यशील घटक है जो आपको क्या चाहिए तो समय लिखने और अपने स्वयं के संस्करण को डीबग करने में क्यों खर्च करें? इसी तरह, यदि आपने पहले ही समान फ़ंक्शन को पूरा करने के लिए कोड लिखा है, तो इसे फिर से क्यों लिखें?

जोएल ने नॉट-इनवॉल्ड पर यहां एक लेख लिखा था, जो कोड और सॉफ़्टवेयर को लिखने और उपयोगी नहीं होने पर वॉल्यूम के बारे में बोलता है।


3

पहिया को फिर से बनाना एक शानदार तरीका हो सकता है यह जानने के लिए कि कुछ कैसे काम करता है - और मैं अपने समय पर सिर्फ उस उद्देश्य के लिए पुनर्निवेश करने की सलाह देता हूं - लेकिन जब कोई एप्लिकेशन लिखता है तो क्यों अच्छी तरह से स्थापित समाधानों को सुदृढ़ करता है जो पहले से ही काम करते हैं?

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


3

अंगूठे का मेरा व्यक्तिगत नियम:

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


3

"बुरा" या यहां तक ​​कि "बुराई" होने के बजाय मजबूत शब्द हैं।

हमेशा की तरह एक अंतर्निहित में एक व्यक्तिगत कार्यान्वयन को चुनने के लिए कारण हैं। पुराने दिनों में एक सी प्रोग्राम रनटाइम लाइब्रेरी में बग का सामना कर सकता है, और इसलिए बस उसे अपना कार्यान्वयन प्रदान करना होगा।

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

http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

यह भविष्य के जावा वितरण में पाया, तय और वितरित किया गया था।

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

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

इसलिए, अपने स्वयं के कार्यान्वयन को प्राथमिकता देना पूरी तरह से मान्य है, लेकिन इसका कारण वास्तव में अच्छा है, क्योंकि यह दूसरों के काम का लाभ उठाने की तुलना में अधिक महंगा होने के लिए बाध्य है।


Bugfixes को तैनात करने के लिए प्लेटफ़ॉर्म पर भरोसा करने के लिए +1। दूसरी ओर, यह प्लेटफ़ॉर्म विक्रेता पर निर्भर करता है कि वह बगफिक्स को वितरित करे या नहीं। एक अलग विक्रेता चुन सकता है: (1) बगफिक्स को वितरित करें, मुफ्त में; (2) प्रमुख संस्करण के उन्नयन तक बगफिक्स को रोकना; (3) नवीनतम संस्करण के उपयोगकर्ताओं को बगफिक्स वितरित करते हैं, लेकिन पहले के संस्करणों को अस्वीकार करते हैं (4) पूरी तरह से ठीक करने से इनकार करते हैं, यह दावा करते हुए कि यह "व्यापक असंगति" का कारण हो सकता है और "केवल सीमित उपयोगकर्ताओं को प्रभावित करता है"।
rwong

@rwong, यदि आपको नियमित रूप से निर्मित बग मिला , तो आपका सर्वश्रेष्ठ दांव अपना निश्चित संस्करण प्रदान करना होगा। यह "बहुत अच्छे कारण के लिए इतना है" के तहत चला जाता है।

ørn: मेरा कहना है कि आपके द्वारा उल्लेखित परोपकारी विक्रेता (ओं) के अलावा, अन्य प्रकार के विक्रेता भी हैं।
rwong

@rwong, उस मामले में जो "व्यक्तिगत कार्यान्वयन चुनने के लिए एक बहुत अच्छा कारण" के लिए अर्हता प्राप्त करता है।

3

मैंने हाल ही में इस विषय पर अपने विचार रखे । संक्षेप में:

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

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

  3. अपना खुद का ढांचा बनाने का एक बड़ा फायदा यह है कि आपको किसी और के बग की जिम्मेदारी नहीं लेनी पड़ेगी। (यह अमेज़ॅन का दर्शन है ।) इसे इस तरह से सोचें: इनमें से कौन सा ग्राहक को बताना बेहतर है? -

    "हमारी वेबसाइट टूट गई। यह किसी और की गलती थी, और हमने इसके निर्माता के साथ एक बग लॉग इन किया है। प्रतीक्षा के अलावा हम ऐसा कुछ भी नहीं कर सकते हैं। हम आपको अपडेट रखेंगे।"

    "हमारी वेबसाइट टूट गई, और हम इसे तुरंत ठीक करने में सक्षम थे।"


0

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


0

खैर, उनका अपना तरीका फ्रेमवर्क जितना ही कुशल होगा, बहुत कम होगा क्योंकि ज्यादातर फ्रेमवर्क में अभी भी बग होते हैं और कोई भी फ्रेमवर्क आपको आउट ऑफ बॉक्स समाधान नहीं दे सकता है। अधिकांश प्रोग्रामर जो सोच भी नहीं सकते, वे फ्रेमवर्क स्तर पर कुछ भी लिखने की कोशिश नहीं करेंगे; वे बस एक तैयार समाधान के लिए Google खोज करेंगे। कोई भी बुद्धिमान प्रोग्रामर सबसे पहले यह देखेगा कि क्या कोई मुफ्त ढांचा है जिसकी कार्यक्षमता उसकी जरूरत है, और अगर नहीं है तो स्वयं समाधान लिखें। कभी-कभी वर्तमान परियोजना संतृप्ति की व्याख्या करना बहुत मुश्किल होता है और डेवलपर सबसे अच्छा न्यायाधीश होता है।

पहिया को फिर से चालू करना बुरा नहीं है, यह आलसी लोगों द्वारा कड़ी मेहनत से बचने के लिए दिया गया बयान है। यहां तक ​​कि रूपरेखा लेखक भी पुनर्निवेश करते हैं; COM क्या पेशकश कर रहा था करने के लिए पूरे .Net ढांचे को फिर से बनाया गया था।


0

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

मैं समझता हूं "अगर यह नहीं टूटा है तो इसे ठीक न करें", हालांकि मुझे लगता है कि इस तरह के वाक्यांश से कुछ लोग अनभिज्ञ हो सकते हैं। फिर भी अंतरिक्ष यात्रा, रेसिंग, शिपिंग, आदि की जरूरतों के लिए पहिया का फिर से आविष्कार करने के मौजूदा प्रयास के साथ, "पहिया का फिर से आविष्कार न करें" बहुत अज्ञान है, और कहीं नहीं के रूप में यह लगता है के रूप में निकट है।

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

इस सवाल का मेरा वास्तविक जवाब: केवल दो ही स्थितियां हैं जो पहिया का फिर से आविष्कार करती हैं, यह एक बुरी बात है:

  1. अगर वास्तव में इसकी जरूरत नहीं है
  2. अगर यह दूसरा आदमी है जब आप कर सकते हैं

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


0

"एक पहिया को फिर से संगठित करना" के बारे में तर्क अक्सर पुस्तकालय का उपयोग करने के लिए चुनने के गलत संदर्भ में उपयोग किया जाता है, लेकिन यह शायद ही समान बात है।

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

हर समय नए गर्भपात हो रहे हैं। उनकी तुलना पहियों से करना कठिन है। यह एक नए नियंत्रण उपकरण और नए मैनुअल की तरह है जो कुछ भी पहले से ही बहुत जटिल-डिवाइस आपको चलाने की आवश्यकता है।

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

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

अंत में सही उपकरण चुनना एक जटिल निर्णय है और "व्हील का सुदृढीकरण" एक बहुत ही उपयोगी परिप्रेक्ष्य नहीं है।


-1

मैंने इसके बारे में एक छोटा सा लेख लिखा था - http://samueldelesque.tumblr.com/post/77811984752/what-re-inventing-the-wheel-can-teach-you

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.