क्या पुस्तकालयों और कोड स्निपेट्स का भारी उपयोग न करने के ठोस कारण हैं? [बन्द है]

Question

कुल मिलाकर अब मैं लगभग 8 वर्षों के लिए प्रोग्रामिंग में हूँ और यह मुझे लगता है कि मैं खुले स्रोत पुस्तकालयों और स्निपेट पर अधिक से अधिक भरोसा कर रहा हूं ("आपको काम खत्म करने के लिए!" मुझे पता है कि समय में मैं खुद के कार्यान्वयन को लिख सकता था लेकिन मुझे समग्र डिजाइन पर ध्यान देना पसंद है।

क्या यह सामान्य (गैर कॉर्पोरेट वातावरण) है? क्या गलत हो सकता है अगर मेरी "प्रोग्रामिंग" अलग-अलग पुस्तकालयों को एक साथ जोड़ने से ज्यादा कुछ नहीं है?

मुझे पता है कि "पहिया को फिर से मजबूत न करें" लेकिन क्या होता है जब आप एक भी पहिया का आविष्कार नहीं करते हैं?

Comments

क्या आपका मतलब "गैर कॉर्पोरेट वातावरण", या ऐसा वातावरण है जहाँ लोग सहयोग नहीं करते हैं ?

— ब्रायन ओकली

मुझे लगा कि हम इंटरफेस और अमूर्त कक्षाओं में लिखते हैं इसलिए हमारे पुस्तकालय अधिक सार्वभौमिक, कम निर्भर, अधिक लचीले हैं ...

— IAbstract

इतना बुरा है, एक तथ्य के रूप में, कि पिता की बेल्ट बंद हो रही है।

— थॉमस ईडिंग

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

— हेंज़ोलो

नहीं, यह आपको खराब प्रोग्रामर नहीं बनाता है, लेकिन यह आपको बेहतर प्रोग्रामर भी नहीं बनाता है।

Answer 1

पहिया को सुदृढ़ करने के बजाय पुस्तकालयों का उपयोग करना: महान! ऐसा ही हर किसी को करना चाहिए। आपको वह करने के लिए भुगतान नहीं मिलता है जो पहले से किया गया है।

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

Comments

बिल्कुल यही मैने सोचा। शायद मुझे इस भावना से छुटकारा पाने के लिए एक ओपन सोर्स प्रोजेक्ट शुरू करना चाहिए :)

— हेनरिक पी। हेसेल

मुझ से +1। लोगों को कभी भी उस कोड का उपयोग नहीं करना चाहिए जो उन्हें समझ में नहीं आता है। यह स्निपेट और लाइब्रेरी के लिए जाता है।

— टिम पोस्ट Tim

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

— री मियासाका

टिम: पुस्तकालयों के बारे में, मुझे यह समझने की ज़रूरत नहीं है कि यह कुछ कैसे करता है, जब तक मुझे पता है कि यह क्या करता है। उदाहरण के लिए, हम में से बहुत से लोग क्रिप्टोकरंसी का उपयोग करते हैं; मुझे नहीं पता कि एईएस कैसे काम करता है, लेकिन मुझे पता है कि यह क्या करता है और इसका उपयोग कब करना है।

— user281377

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

— हेनरिक पी। हेसल

Answer 2

अच्छे प्रोग्रामर अच्छा कोड लिखते हैं; महान प्रोग्रामर महान कोड चोरी।

Comments

लाइन के लिए +1। क्या यह मूल है?

— अपूर्व ०२०

काश, यह कोई अजीब कहावत है।

— dan_waterworth

मैं अपने iPhone पर हूं, लेकिन मुझे लगता है कि यह पाब्लो पिकासो (कलाकारों के साथ प्रोग्रामर को बदलने) का एक उद्धरण है

— हेनरिक पी। हेसेल

पिकासो ने कहा Good artists copy, Great artists steal।

— dan_waterworth

शानदार बोली। मुझे लगता है कि मैं ^ H ^ H ^ H ^ H को फिर से चुरा लूंगा।

— को साने

Answer 3

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

Answer 4

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

नहीं है कुछ नहीं पुस्तकालय कोड है कि परीक्षण किया गया है और समय के साथ प्यार करता था का उपयोग कर के साथ कुछ गलत। आप जानते हैं कि यह कैसे काम करता है, आप इसकी जटिलता पर भरोसा कर सकते हैं और आप इसे जल्दी से लागू कर सकते हैं।

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

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

इसलिए, लाइब्रेरी कोड का उपयोग करने में कुछ भी गलत नहीं है, जब तक आप जिज्ञासु बने रहते हैं और सीखते रहते हैं। यह कहे बिना जाता है कि आपको उस कोड का उपयोग नहीं करना चाहिए जिसे आप नहीं समझते हैं, जब तक कि आपका उपयोग यह समझने का प्रयास नहीं है कि यह कैसे काम करता है।

Comments

आपने jQuery, +1 के खिलाफ मेरे विरोध का बहुत सुंदर वर्णन किया है।

— आआआआआआआआआआ आआआआआ

Answer 5

मैं इस प्रश्न में कुछ अन्य लोगों की तुलना में बेहतर हूँ: मुझे नहीं लगता कि किसी लाइब्रेरी के "क्लाइंट" डेवलपर को उस लाइब्रेरी के कोड को "समझने" की आवश्यकता है।

मैं (कुछ की तुलना में) अपेक्षाकृत नए iPhone डेवलपर हूं। वहाँ पुस्तकालयों के बहुत सारे हैं जो मैं हर दिन उपयोग करता हूं जो मैं कभी भी अपने दम पर उत्पन्न नहीं कर सकता था, और जिसका कोड मेरे सिर पर है। थोड़ी भी बात नहीं है:

1) मैं पूरी तरह से उन पुस्तकालयों के लिए इंटरफ़ेस को समझता हूं (मैं एक ASIHTTPRequest निंजा हूं!)
2) मैं उन पुस्तकालयों को चुन रहा हूं जो सामान्य रूप से व्यापक उपयोग हैं, इसलिए मुझे यकीन है कि वे अच्छी तरह से खत्म हो गए हैं और समस्याओं के लिए पता लगाया गया है। (जैसे: ASIHTTP, स्टिग ब्रूटसेट की JSON लाइब्रेरी, फेसबुक की obj-c लाइब्रेरी इत्यादि)
3) Failing # 2, यह इतना सरल है कि मैं इसके माध्यम से अपना रास्ता चुन सकता हूं और ऐसी किसी भी चीज को ढूंढ / तय / अनुकूलित कर सकता हूं, जिसकी जरूरत है / फिक्सिंग / कस्टमाइज़िंग ।

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

Answer 6

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

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

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

मुझे पता है, सोच दुख देती है और कंप्यूटर सस्ते होते हैं, लेकिन फिर भी। नहीं सोचने से ज्यादा नुकसान हो सकता है।

Answer 7

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

Answer 8

कोड का पुन: उपयोग एक बहुत अच्छा विचार है। यह अतिरेक को कम करता है और रखरखाव को बढ़ावा देता है।

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

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

Comments

तुम मुझे वहां ले गए। मैं दूसरे के काम के कोड की कई पंक्तियों (पुस्तकालयों को नहीं) की नकल करने का भी उल्लेख करता हूं, क्योंकि यह मेरे मामले में कानूनी है। तुम क्या सोचते हो?

— अरमान

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

— pswg

: एक आखिरी सवाल: तो जैसा कि मेसन ने कहा था, अगर मैंने उदाहरण के लिए पाया कि आप की 2500 लाइनें (फिर से मैं पुस्तकालयों पर जोर नहीं दे रहा हूं) तो मेरा काम शुरू करने में कुछ उपयोगी है, और आप मुझे इसे कॉपी करने के लिए करते हैं, आपको लगता है कि यह मेरे लिए अच्छा है? नैतिक है?

— अरमान

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

— 1957 में

आदर्श रूप से, आपको यह भी समझना चाहिए कि कॉपी किए गए कोड कैसे काम करते हैं।

— माइक पार्टरिज

Answer 9

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

हालाँकि, सुनिश्चित करें कि आप यह समझने में समय लेते हैं कि पुस्तकालय क्या करता है और यह कैसे करता है। जिन चीजों को आप नहीं समझते, उनका ध्यान रखने के लिए "मैजिक" लाइब्रेरी का उपयोग करना इसका एक अच्छा तरीका है कि इसका कुछ हिस्सा आप पर उड़ जाए क्योंकि आपने इसे गलत इस्तेमाल किया है, और फिर आपको पता नहीं है कि इसे कैसे ठीक किया जाए।

Comments

मुझे आश्चर्य है कि मेरे उदार साथी प्रोग्रामर द्वारा बनाई गई कोड की सौ पंक्तियों को "कॉपी और पेस्ट करना" अभी भी नैतिक है।

— अरमान

@ अरमान: उससे पूछने का प्रयास करें।

— मेसन व्हीलर

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

— डेरियस एक्स

Answer 10

कानूनी रूप से पुन: उपयोग कोड में लगभग कोई डाउनसाइड नहीं है और दो विशाल अपसाइड हैं:

1. इससे काम हो जाता है। पेशेवर विकास के लिए यह अधिक महत्वपूर्ण है। अंततः, आपके पास एक अच्छी तरह से भुगतान करने वाली नौकरी है क्योंकि आप जानते हैं कि ऐसी चीजें कैसे बनती हैं जो अधिकांश गैर-प्रोग्रामर को स्टंप करेंगी; पुन: उपयोग आपको उस लक्ष्य तक तेज़ी से पहुंचने देता है, जिससे आप अपनी नौकरी में अधिक मूल्यवान बन जाते हैं।
2. आप सामान सीखिए। यह आत्म-सुधार का अधिक महत्वपूर्ण कारण है। दूसरों द्वारा लिखे गए अच्छे कोड को पढ़ने की तुलना में कोडिंग में सुधार करने का कोई बेहतर तरीका नहीं है। यहां तक ​​कि दूसरों द्वारा लिखे गए बुरे कोड आमतौर पर आपको कुछ सिखाते हैं! और यह समझने का कोई बेहतर तरीका नहीं है कि एक पुस्तकालय, एपीआई, भाषा या डोमेन कैसे काम करता है, जो दूसरों द्वारा पहले से लिखे गए समाधानों को पढ़ने और सुधारने से है। दोनों चीजें आम तौर पर तब होती हैं जब आप मौजूदा कोड का पुन: उपयोग करते हैं, क्योंकि कोई भी मौजूदा-मौजूदा समाधान कभी भी आपकी आवश्यकता के अनुसार बहुत कुछ नहीं करेगा - और स्रोत के साथ आने वाली छेड़छाड़ वह जगह है जहां से ज्ञान को बढ़ावा मिलता है।

Comments

यह वास्तव में मेरा लक्ष्य है, सीखना। अभी के लिए, यह मेरी परियोजना को खत्म करने से अधिक के लायक है। इसलिए मुझे बुरा लगता है जब किसी के काम को सिर्फ थोड़े से प्रयास के साथ करने की कोशिश की जाती है (न कि केवल पुस्तकालयों का जिक्र करते हुए)।

— अरमान

Answer 11

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

यदि आप उचित स्थानों में पुस्तकालयों और कोड स्निपेट का उपयोग करते हैं, तो 'नहीं' , इसका मतलब यह नहीं है कि आप एक खराब प्रोग्रामर हैं। इसका मतलब है कि आप एक स्मार्ट प्रोग्रामर हैं जो दूसरों के ज्ञान को उपयुक्त स्थानों पर लागू कर सकते हैं।

हालाँकि...

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

Answer 12

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

Answer 13

अन्य उत्तरों में कारणों के अलावा, कोड का उपयोग नहीं करना (जब तक यह आपकी समस्या के लिए एक अच्छा फिट है) को अनैतिक माना जा सकता है क्योंकि:

1. आप जानबूझकर अपने नियोक्ता समय बर्बाद कर सकते हैं या
2. आप जानबूझकर कम उत्पाद वितरित कर सकते हैं

ध्यान रखें, उन दोनों को पहले से निर्धारित करना कठिन है।

इसके अलावा, Not Invented Here को देखें , जिसे आमतौर पर anit-pattern के रूप में जाना जाता है।

Answer 14

पूर्ण उद्देश्यों के लिए, एक काउंटर तर्क की अनुमति दें: http://web.archive.org/web/20150326134617/https://michaelochurch.wordpress.com/2015/03/25/never-invent-here-the-venven-worse नहीं आविष्कार-यहाँ -sibling के- /

एक मानसिकता जिसे मैं "नेवर इन्वेंट हियर" (NeIH) कहता हूं। उस मानसिकता के साथ, बाहरी संपत्तियों को ओवरवैल्यूड किया जाता है और अक्सर उन पर भरोसा किया जाता है, जिससे इंजीनियरों को ऑफ-द-शेल्फ संपत्ति के quirks के लिए अधिक समय बिताने के लिए छोड़ दिया जाता है, और कम समय में अपनी संपत्ति का निर्माण होता है।

हमेशा एक संतुलन होता है।

Answer 15

मैं पुस्तकालयों का उपयोग नहीं करने के लिए हूँ जब तक कि बिल्कुल आवश्यक न हो। निर्भरता पोर्टेबिलिटी और जीवनकाल को सीमित करती है। मेरे पास सॉफ्टवेयर विकास में 34 वर्ष हैं और मैं कम से कम 1 कार्यक्रम को पिछले 3 वर्षों से अधिक समय तक नष्ट (परिवर्तित) किए बिना करना चाहूंगा।

COM (घटक ऑब्जेक्ट मॉडल), 17 साल पहले का उत्तर, सिद्धांत रूप में महान, व्यवहार में संदिग्ध, पुन: प्रयोज्य घटकों वास्तव में नहीं, मैं केवल बहुत ही मूल घटकों का उपयोग करेगा और केवल अगर मुझे करना है।

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

फ्रेमवर्क: Zend, Silverlight, WCF, .NET, स्तरित सिस्टम, हाँ, वे प्रारंभिक विकास को गति दे सकते हैं, लेकिन जब मैं उनकी सीमा से टकराता हूं, तो जिस समय मैं दरारें ठीक करता हूं, बस प्रयास के लायक नहीं होता। वे कितने पुराने हैं और क्या वे अपरदन के लिए अभेद्य हैं?

मैं केवल अपने पुस्तकालयों के साथ जावास्क्रिप्ट और HTML पर गया हूं। मैंने केवल सबसे सामान्य स्टेटमेंट प्रकारों का उपयोग करके जावास्क्रिप्ट को नीचे गिरा दिया है। मुझे उम्मीद है कि 10 साल में मैं ऐसा कुछ लिख सकता हूं जो चलेगा।

Comments

इस समस्या का हिस्सा पुस्तकालयों में बहुत ज्यादा नहीं है, लेकिन भाषाओं और प्रोग्रामिंग टूलों की निरंतर प्रौद्योगिकी मंथन का मतलब है कि आपको उसी पुरानी चीज़ को करने के लिए नई तकनीक में नए पुस्तकालयों को ढूंढना होगा।

— gbjbaanb

Answer 16

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