प्रोग्रामिंग मुद्दों के बारे में सबसे बेतुका मिथक क्या है?

Question

इसे दूसरे तरीके से रखने के लिए ... प्रोग्रामिंग के बारे में सबसे अधिक आयोजित और निराशाजनक गलतफहमी क्या है, आपने सामना किया है?

कौन से व्यापक और दीर्घकालिक मिथक / गलतफहमी आपको प्रोग्रामर को दूर करने / सही करने के लिए कठिन लगता है ।

कृपया, समझाएं कि यह एक मिथक क्यों है।

Comments

मैं Mythbusters को इनमें से कुछ पर देखना चाहता हूं।

— spong

Mythbuggers YouTube चैनल के लिए कोई भी? :-)

— तमारा विजसमैन

Ooooh, MythBusters और दौड़ की स्थिति! मीसा की तरह!

@TomWij ऐसे नाम वाली वेबसाइट होना बहुत अच्छा होगा!

— जूनियर एम

Answer 1

ऐसा इसलिए है क्योंकि आप एक प्रोग्रामर हैं, आप जानते हैं कि कैसे [व्यक्ति] वायरस राइड मशीन को ठीक करना है।

Comments

कार सादृश्य / बाहर निकलना बंद करें: "मैं एक रेसिंग ड्राइवर हूं, मैकेनिक नहीं।"

— पीटर बॉटन

यह कॉमिक प्रासंगिक है: Theoatmeal.com/comics/ कंप्यूटर्स

— lunixbochs

xkcd.com/627

— back2dos

@ अगर वह खाना बना सकती है, तो अपने दोस्तों की पार्टियों को पूरा करने के लिए उसे स्वयं सेवा देना शुरू करें

— स्टीवन ए। लोवे

यह नहीं है कि मैं नहीं जानता कि कैसे ... यह है कि मैं अपनी मशीन को ठीक करने में घंटों बर्बाद नहीं करना चाहता हूं जिसे आप 2 सप्ताह में वैसे भी तोड़ देंगे।

— चौपपांडियन

Answer 2

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

"हां, सीखने की अवस्था है। लेकिन मैंने इससे कठिन बदलाव किए हैं। मैं आपको एक सौदा करूंगा, मुझे पहले महीने के लिए 80% का भुगतान करें और उस समय के अंत में यदि मैं नहीं हूं ... ओह रुको, हम वास्तव में यह बातचीत नहीं कर रहे हैं, क्योंकि आपके एचआर बंदर ने बस मेरा आवेदन हटा दिया है। "

Comments

एचआर बंदर के लिए + जानकारी।

— रस्टी

मैंने एक एचआर आदमी को एक भूमिका के लिए मुझे ठुकरा दिया है क्योंकि मुझे पता था कि कैसे सी #, लेकिन वह किसी ऐसे व्यक्ति की तलाश कर रहा था जो डॉटनेट में कोड कर सके।

— burnt_hand

@ ब्लंट_हैंड: हाँ, मैं डॉटनेट जानता हूं। मुझे एक्सेल और इंटरनेट एक्सप्लोरर भी पता है। मैं अब अनुबंध कर सकता हूं?

— एलन प्लम

जबकि मैं मानता हूं कि जावा और C # के बीच सिंटैक्स, स्ट्रक्चर, SDLC, आदि के साथ बहुत सारे ओवरलैप्स हैं, अगर वे आपको अपने साक्षात्कार में कोई उचित पेचीदा C # टेस्ट देते हैं, तो आप किराया कैसे लेंगे?

— JBRWilkinson

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

— राजहंस

Answer 3

यदि आप टाइप नहीं कर रहे हैं, तो आप काम नहीं कर रहे हैं।

मेरा मानना ​​है कि ज़ोंबी ब्लैंक स्टार्स और कॉफी वॉक प्रोग्रामर को अपने सिर में चीजों को व्यवस्थित करने के लिए आवश्यक हैं।

Comments

पेज अप, पेज डाउन ... पेज अप, पेज डाउन ...

— एडोल्फ लहसुन

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

— केविन लाईट

"कोड का संकलन"

— टोबियास किंजलर

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

— एलन प्लम

"यदि मेरे पास कोड करने के लिए अधिक समय था, तो मैं कम लाइनें लिखूंगा।" - अबे लिंकन बोली पर उतार।

— जेएफओ

Answer 4

कि आप एक देर परियोजना को गति दे सकते हैं, बस उस पर और लोगों को फेंक सकते हैं।

Comments

ए, द मैथिकल मैन मंथ से। en.wikipedia.org/wiki/The_Mythical_Man-Month

— स्पंज

दरअसल, उह, आप कर सकते हैं। -1 (हाँ, एक मिथक वाहक को निहारना!)

— पी।

हम एक रंगीन कहावत का उपयोग करते हैं "आप 9 महिलाओं को एक कमरे में नहीं रख सकते हैं और एक महीने में एक बच्चा बना सकते हैं"।

— वाल्टर

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

— एएसपीली

@Walter, लेकिन आपके 9 महीने में 9 बच्चे हो सकते हैं और 7 साल में एक छोटी लीग बेसबॉल टीम हो सकती है।

— हपरनिकेक्ट्स

Answer 5

उस सॉफ्टवेयर को लिखना आसान है।

आप इन सभी परियोजनाओं की व्याख्या कैसे करते हैं, जो समय के साथ-साथ बजट और लोगों (राजनेताओं, मीडिया आदि) पर चलती हैं, फिर भी आश्चर्यचकित होते हैं, और ग्राहक शिकायत करते हैं जब आप उन्हें बताते हैं कि उनकी "छोटी वेबसाइट" (या जो भी) वास्तव में 6 ले जाएगी कई हजार डॉलर विकसित करने और खर्च करने के लिए महीने (पाउंड, यूरो, [पसंद की मुद्रा डालें])

फजी और कभी बदलती आवश्यकताओं के साथ मुझे कभी-कभी लगता है कि यह आश्चर्यजनक है कि कोई भी सॉफ़्टवेयर कभी भी समाप्त हो जाता है!

मुझे पता है कि यह उससे कुछ अधिक जटिल है;)

Comments

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

— 7wp

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

— एलन प्लम

ऐसा नहीं है कि आवश्यकताएं बदल गईं, यह वैसा नहीं है जैसा उन्होंने सोचा था कि वे चाहते थे।

— जेएफओ

मैं किसी को "अगर 'बयानों का एक गुच्छा" "के रूप में प्रोग्रामिंग को खारिज कर दिया था। ठीक है, शायद यह है ... उस मामले में, कविता "सिर्फ शब्दों का एक गुच्छा" है ... फिल्म का निर्माण "सिर्फ दृश्यों का एक गुच्छा" है, आदि

— जोएलफैन

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

— कैप्टन सेंसिबल

Answer 6

ऐप की जटिलता यूआई की जटिलता के सीधे आनुपातिक है। इस तर्क से, आप एक सप्ताहांत में Google या ट्विटर का निर्माण करने में सक्षम होना चाहिए।

Comments

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

— orokusaki

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

— इवान प्लाइस

1+ एक समय था जब मैं अपने पूर्व बॉस के लिए SharePoint संबंधित परियोजना (एक बहुभाषी एडऑन) को प्रदर्शित करता था, जो जटिल बैकएंड कोड पर काम करने में घंटों बिताते थे। अंतिम परिणाम यूआई पर बहुत अधिक नहीं किया गया था, जिससे मेरे बॉस को विश्वास हो गया कि परियोजना पर बहुत कुछ नहीं किया गया है। इसने मुझे नाराज कर दिया। वह SharePoint की विषमताओं के साथ-साथ पाठ प्रतिस्थापन तर्क के बारे में जानने के लिए घंटों तक कीबोर्ड पर बैठा नहीं था।

— जेसन इवांस

जब आप कुछ विशाल, लगभग-असंभव, अनुरोध से घृणा करते हैं, तो "" क्या आप एक बटन जोड़ सकते हैं ... "

— JoelFan

मुझे आश्चर्य है कि मैं पिछले कुछ वर्षों से क्या कर रहा हूं। उन सभी परियोजनाओं पर जिन्होंने मैंने पूर्णकालिक काम किया, उन्हें कुछ ही समय में समाप्त हो जाना चाहिए था, क्योंकि उनके पास बिल्कुल भी यूआई नहीं था। :-)

— बार्ट वैन इनगेन शेनॉ

Answer 7

सभी प्रोग्रामर गणित में अच्छे हैं। :-)

Comments

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

मुझे लगता है कि गणित में क्षमताएं किसी तरह प्रोग्रामिंग कौशल से संबंधित हैं।

— डिएगो

@Diego: हालांकि इस तरह जरूरी नहीं कि सभी प्रोग्रामर गणित में अच्छे हों, लेकिन फिर भी।

— ओमेगा

Answer 8

कोई भी किशोर बच्चा, जो कंप्यूटर के साथ हैक करता है, कौशल में एक अनुभवी काम करने वाले प्रोग्रामर के बराबर (या श्रेष्ठ) होता है।

मेरा 14 साल का भतीजा कंप्यूटर के साथ अच्छा है और मैं उसे अपना लॉन घास काटने के लिए $ 10 / hr का भुगतान कर रहा हूं। अगला फेसबुक लिखने के लिए मुझे आपको छह आंकड़े क्यों देने चाहिए?

Comments

वे शायद अपने स्वयं के वातावरण में हैं यानी अपने स्वयं के मानकों पर काम कर रहे हैं। उन्हें एक टीम में रखें जहां उन्हें संवाद करना है और यहीं पर उन्हें तकलीफ होती है।

— एडोल्फ लहसुन

काउंटर सवाल हो सकता है: "आप उसे अपना घर बनाने के लिए क्या भुगतान करेंगे?"

कोई योग्यता वाला बच्चा नहीं बल्कि साफ-सुथरा कोड लिखता है और श्री स्पेगेटी को किसी भी दिन हरा सकता है।

— ज़ाज़

मुझे लगता है कि के लिए हॉलीवुड दोष

— MAK

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

— पीटर बॉटन

Answer 9

उस वास्तविक समय का मतलब है उपवास।

बताते हुए "पैकेट को वास्तविक समय में संसाधित करने की आवश्यकता है।" बेकार और दुष्ट जुड़वां है ... जवाब "कितनी तेजी से एक्स होने की जरूरत है?" साथ "वास्तविक समय" संभवतः बेकार की तुलना में कम है ... बेवकूफ बजाय अज्ञानी की सीमा पर।

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

तो इसे खटखटाओ ।।

Comments

real-time = निकट-समय

— brian chandley

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

— बर्न_हैंड

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

— जॉनएफएक्स 14

@ जॉनफ्लेक्स अच्छी तरह से। अवधारणाओं को संदर्भ की आवश्यकता है।

— जंग

@ रिचर्ड: वास्तव में, आईट्यून्स हमेशा कुछ भी खेलने से पहले कुछ मिनट लगते हैं। ओह, यह तुम्हारा मतलब नहीं है?

— विन्यासकर्ता

Answer 10

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

:-) :-)

Comments

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

— डीजेकवर्थ

हमारे पास एप्लिकेशन कॉन्फ़िगरेशन में एक सेटिंग है: <

— key

@DJClayworth - जो हमेशा काम नहीं करता है। कुछ मामलों में, समस्या इतनी बड़ी है, बीमार-परिभाषित या सिर्फ सादा कठिन है कि पहली बार "सही" के करीब हो रही है, यह उम्मीद करने के लिए बहुत अधिक है। ऐसे मामले में, "फर्स्ट कट" लिखना बेहतर होता है, जो पूरी तरह से गलत नहीं है, क्योंकि इसे सही तरीके से पहली बार प्राप्त करने के प्रयास में दिनों / हफ्तों / महीनों को पूरी तरह से डिज़ाइन करना और फिर से डिज़ाइन करना है।

— स्टीफन सी।

यह आम आदमी का संस्करण हो सकता है "आप लोग टीडीडी क्यों नहीं कर रहे हैं?" यदि, निष्पक्ष होना, एक अच्छा प्रश्न है, अगर वास्तविक दुनिया के विकास के लिए अधिक सरल है।

— दान रे

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

— n1ckp

Answer 11

यदि आप विश्वविद्यालय चले गए हैं, तो आप नौकरी के लिए उपयुक्त नहीं हैं

Comments

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

— एलन प्लम

और फिर भी विश्वविद्यालय में पढ़ाने वाले लोगों को भी लगता है कि वे प्रोग्रामर और परियोजनाओं के व्यवहार को सामान्य बना सकते हैं, यह देखते हुए कि जब छात्र चाय पीते हैं तो वे कैसे संचालित होते हैं। एसीएम के संचार साल में 4-6 ऐसे लेखों के लिए अच्छे हैं।

— मिया

@ बिली यहाँ के बारे में कैसे है, जहां एक कॉलेज डिप्लोमा का मतलब जैक है, लेकिन एक विश्वविद्यालय डिप्लोमा आपको सब कुछ प्रदान करेगा? दोनों स्कूल जाते हैं, दोनों यकीनन दूसरे की तुलना में बेहतर हैं, लेकिन एक सामाजिक अंतर है

— तारका

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

— एडम लेअर

विश्वविद्यालय कम से कम एक महत्वपूर्ण बात सिखाते हैं: मानसिकता । यह बहुत महत्वपूर्ण है, लेकिन जो लोग नहीं जानते कि ... ठीक है, वह नहीं जानते।

Answer 12

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

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

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

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

Comments

डेटाबेस की अखंडता की जाँच के आसपास टिप्पणी के लिए विशेष रूप से +1।

— फ्रैंक शीयर

+1 विशेषकर अंतिम पैराग्राफ के लिए। मैंने उस ड्रम को एक से अधिक बार पीटा है।

— बाइनरी वॉरियर

पहले पैराग्राफ के लिए +1। सभी बुराईयो की जड़ समयपूर्व इष्टतमीकरण है; बिना किसी खूनी कारण के खराब कोड लिखना और भी बुरा है।

— विन्यासकर्ता

"कुछ ओओपी चीजों के कारण भयानक प्रदर्शन समस्याएँ पैदा हो जाएंगी और दूसरों को डेटाबेस के संदर्भ में सिर्फ दर्द होता है" - क्या आप कह सकते हैं? मुझे OOP के बारे में पता है, लेकिन डेटाबेस के बारे में बहुत कुछ नहीं है, और मुझे इस बात में दिलचस्पी है कि मैं हर तरफ से विचारों को दूसरे तक कैसे ले जा सकता हूं।

— टॉम एंडरसन

@HLGEM मैं भी उदाहरणों में दिलचस्पी लूंगा @Tom सोच रहा है ...

— आर्मंड

Answer 13

कि पूर्ण सर्वोत्तम प्रथाओं के कुछ पौराणिक स्रोत हैं।

कोई भी विचलन कभी भी उचित नहीं हो सकता।

किसी भी चीज़ को सर्वश्रेष्ठ-व्यवहार के रूप में परिभाषित करने का दावा करने वाले किसी भी दस्तावेज़ पर कभी भी सवाल नहीं उठाया जा सकता है।

Comments

अपने प्रबंधकों से बेहतर टीम का सदस्य ...

— बिल

क्या आप उस डॉक्टर को मेरे पास भेज सकते हैं?

— एएसपीली

पूर्णतया सहमत। यदि आप पायथन कोड में टैब और रिक्त स्थान मिलाते हैं, तो कौन परवाह करता है?

— ज़ज़

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

— स्टीफन सी

मैं व्याख्या करता हूं "यह सबसे अच्छा अभ्यास है" के रूप में "मैं इसे सही नहीं ठहरा सकता"। मैं निश्चित रूप से इसका उपयोग खुद करता हूं।

— टॉम एंडरसन

Answer 14

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

Comments

और मार्केटिंग की और भी मज़ेदार बात यह है कि इसमें कोई विचार नहीं है कि कौन सी सुविधाएँ आसान हैं और जो असंभव के करीब हैं।

— derobert

@derobert वास्तव में, मुझे अक्सर यह अनुभव होता है कि कुछ अधिक विचारशील विपणन लोग वास्तव में कुछ सरल / आसान सुविधाओं के बारे में पूछने से भी डरते हैं जो उन्हें लगता है कि इसे लागू करना बहुत मुश्किल था। हालांकि मैं इसके विपरीत अक्सर अनुभव करता हूं: यहां एक्स "आसान" सुविधाओं का एक बैच है जो हमने पहले ही ग्राहक को बेच दिया है, कृपया इसे कल तक पूरा कर लें ...

— Giel

Answer 15

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

Comments

@DisgruntledGoad - हालांकि यह सच है। इस "मिथक" में गलतफहमी इस तथ्य से है कि बहुत से प्रोग्रामर अपने अखंड भ्रमित कोड को "अच्छा" मानते हैं। if user.is_logged_in: print('Welcome')एक टिप्पणी की जरूरत नहीं है।

— orokusaki

@orokusaki हर एल्गोरिथ्म इतना आसान नहीं है।

— ज्यूके वैन डेर मास

@orokusaki आप "सरल कोड टिप्पणी की जरूरत नहीं है" के साथ "अच्छे कोड टिप्पणी की जरूरत नहीं है" गलत कर रहे हैं। अच्छा कोड हमेशा सरल नहीं होता है।

— असंतुष्टगीतगेट

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

— फ्लेमिंगपेंगिन

@orokuskai: अच्छा कोड सरल है। चीजें जो कर रही हैं वह जटिल हो सकती हैं लेकिन कोड की सादगी (लालित्य) वह है जो मेरी राय में इसे अच्छा बनाती है! बेशक, कोड बहुत सारी अन्य चीजें करता है, और बकवास कोड आपको बहुत पैसा बना सकता है। लेकिन मेरा लक्ष्य जटिल परिस्थितियों में भी सरल कोड लिखना है।

— राजहंस

Answer 16

सबसे खराब मिथक: यदि आप लंबे समय से प्रोग्रामिंग कर रहे हैं तो आप आसानी से प्रोजेक्ट मैनेजर हो सकते हैं।

और अगर आप लंबे समय से प्रोग्रामिंग कर रहे हैं तो आपको एक प्रोजेक्ट मैनेजर बनना चाहिए।

Comments

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

— इवान प्लाइस

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

— एएसपीली

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

— एलन प्लम

पीटर सिद्धांत के रूप में भी जाना जाता है। en.wikipedia.org/wiki/Peter_Principle

— Spoike

वास्तव में अच्छी तरह से कहा

— माइकल ईस्टर

Answer 17

यदि हम अपने प्रोजेक्ट में Java, C # और C ++ के अलावा किसी अन्य चीज का उपयोग करते हैं, तो हमें इसका समर्थन करने के लिए कोई प्रोग्रामर नहीं मिलेगा।

Comments

मैंने इसके बारे में कभी नहीं सुना था, लेकिन यह मान्य है। बेशक यदि आप एक अस्पष्ट भाषा का उपयोग करते हैं तो ऐसा होगा।

— मनिएरो सेप

@ बिगबॉस, "अस्पष्ट"? कितना अस्पष्ट है? क्या बंधन अस्पष्ट है? हास्केल? पास्कल (डेल्फी)? अजगर? मुझे लगता है कि वे अस्पष्ट नहीं हैं। बहुत से लोग सोचते हैं कि वे हैं, और "गंभीर" विकास में केवल भाषाओं का एक बहुत ही संकीर्ण सेट (C ++, C # और Java) की अनुमति है।

— पी शेव्ड

@bigown: ओह, तुम्हारा मतलब है COBOL की तरह अस्पष्ट? : पी

— अन्नज्र

मैंने एक बार लिनक्स पर ऑब्जेक्टिव-सी कोड करने वाली एक छोटी कंपनी के लिए काम किया था। CEO - जो एक इंजीनियर नहीं थे, लेकिन उनके पास कुछ तकनीकी ज्ञान था - यह विश्वास नहीं कर सकता था कि आस-पास ObjC प्रोग्रामर थे या किसी और ने इसका इस्तेमाल किया था। वास्तव में उन्हें अच्छे डेवलपर्स को काम पर रखने में कोई समस्या नहीं थी।

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

— टॉम एंडरसन

Answer 18

जावा विभिन्न वर्गों के साथ सिर्फ C ++ है।

Comments

+1 मैंने एक बार एक साक्षात्कारकर्ता से पूछा, "सी ++ और जावा में क्या अंतर है?" इसलिए मैंने कुछ अंतर सूचीबद्ध किए। देशी कंपाइलर बनाम जेवीएम, एएनएसआई मानक बनाम मालिकाना, कचरा संग्रह, क्लास लोडर, आदि। उन्होंने कहा, "गलत! कोई फर्क नहीं है! वे समान हैं!" वह एक छात्र नहीं था, वह इंजीनियरिंग प्रबंधक था।

— बिल कार्वेन

@ फिर, मेरी प्रतिक्रिया तब होगी, "तो फिर उन्हें अलग-अलग नामों से क्यों संदर्भित किया जाए?"

— जेसी सी। स्लाइसर

@ अच्छा, तो आप परीक्षण में विफल रहे और काम पर रखा गया?

मेरी प्रतिक्रिया "अलविदा" होगी।

— पन्नी

@Foole क्या आपका मतलब System.exit (1) नहीं है?

— बैरी ब्राउन

Answer 19

जावा है धीमी गति से ।

Comments

लेकिन, निष्पक्ष होने के लिए, यह हुआ करता था ...

— Dan Diplo

यह अभी भी है ....

— Fosco

कॉफी धीमी कैसे हो सकती है?

— जंग

@ जंग डेकाफ़? ।

— जो फिलिप्स

"नॉक, दस्तक।" - "कौन है वहाँ?" - बहुत लंबे ठहराव ... "जावा।" (के सौजन्य stackoverflow.com/questions/234075/... )

— RegDwight

Answer 20

संभवतः सबसे खतरनाक एक जिसे मैंने देखा है, क्योंकि यह बहुत आसानी से स्वीकार हो जाता है, क्या यह है कि कोड को जल्दी से लिखने में सक्षम है, और इसलिए जितनी जल्दी आप एक दी गई भाषा में [यहां फीचर डालें], बेहतर भाषा में कोड कर सकते हैं है।

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

Comments

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

— Sk93

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

— rtperson

आपने एक शक्तिशाली भाषा की आवश्यकता है। देखें पॉल ग्राहम भाषाओं की चर्चा और क्या ti आपको करने में सक्षम बनाता है: paulgraham.com/power.html

@ Thorbjørn: मैंने वह लेख पढ़ा है, और पॉल ग्राहम ने इसे गलत बताया है। वह एक लिस्प अधिवक्ता है, इसलिए वह लिस्प को अच्छा दिखने के लिए तथ्यों को आत्म-सेवा वाले तर्कों में बदल देता है। शायद यह भी नहीं, क्योंकि यह वास्तव में बहुत घुमा नहीं लेता है। पठनीयता और सफलता के बीच बहुत अधिक ओवरलैप है, क्योंकि वह लेख के अंत की ओर इशारा करता है। लेकिन वह जो निष्कर्ष निकालता है वह वास्तविक दुनिया में सॉफ्टवेयर विकास की स्थिति के साथ पूरी तरह से सिंक से बाहर है। हां, आपको एक शक्तिशाली भाषा की आवश्यकता है, लेकिन वह गलत मानदंडों द्वारा शक्ति को माप रहा है, और यह विश्वास करना हानिकारक है कि वह क्या कहता है।

— मैसन व्हीलर

@ आर्टपर्सन: यह उत्पादकता दस के कारक से भिन्न हो सकती है कोई मिथक नहीं है। जो लोग तेजी से खत्म करते हैं, वे आवश्यक रूप से अधिक उत्पादक होते हैं।

— डेविड थॉर्नले

Answer 21

विनिर्माण सबक सॉफ्टवेयर विकास प्रक्रिया के लिए लागू किया जा सकता है।

Comments

पाठों पर निर्भर करता है। जब मैंने एक गद्दा कारखाने में काम किया, तो हमें पता चला कि टास्क-स्विचिंग हमारे उत्पादन के लिए हानिकारक था। Kinda महत्वपूर्ण है क्योंकि हम गद्दे की संख्या से भुगतान किया गया था और घंटे से नहीं ... और एक सबक है कि बहुत सारे कारणों के लिए भी यहाँ लागू होता है।

— AnonJr

यह एक ऐसा लगातार मिथक है जब आप एक जगह पर काम करते हैं जो ज्यादातर हार्डवेयर बनाता है। हुप्स हम अपने सॉफ़्टवेयर 'बिल्ड' को एक ही मॉडल में फिट करने के लिए कूदते हैं जैसे कि हार्डवेयर 'भाग' अद्भुत होते हैं ...

— AShelly

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

— डेविड थॉर्नले

+100 इसके लिए, विशेष रूप से अर्थशास्त्र का अध्ययन करने वाले लोग ऐसा सोचते हैं

— कुगेल

हर किसी को जैक रीव्स को पढ़ना चाहिए: developerdotstar.com/mag/articles/reeves_design_main.html - यह इस विचार का मूल (या कम से कम एक प्रारंभिक और शक्तिशाली कथन) है कि स्रोत कोड एक उत्पाद नहीं बल्कि एक डिज़ाइन है । प्रोग्रामर ड्राफ्टिंग रूम में डिजाइनरों की तरह होते हैं, न कि कारखाने के फर्श पर मशीन बनाने वाले, और प्रोग्रामिंग का प्रबंधन अन्य प्रकार के इंजीनियरिंग डिजाइन के प्रबंधन की तरह होना चाहिए, न कि विनिर्माण के लिए।

— टॉम एंडरसन

Answer 22

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

Comments

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

— एलन प्लम

+1, या थोड़ा-सा एक स्पर्शरेखा - क्योंकि आपका एक प्रोग्रामर, आपके पास सुपर डुपर वाटर कूल्ड 300 एलईडी फैन कताई है, जो रेंज प्लांट से भेजे गए रेंज ब्रांड के शीर्ष पर चमकता हुआ है, इसके जारी होने से पहले। सच में नहीं! यह एक शालीनता से तेज़ मशीन है, एक काले रंग के बहुत सस्ते मामले में। वास्तव में उस से परे परवाह नहीं है!

— सर्जिकल कोडर

हंसो, काम पर एक पीएम सहायक है, जिसके पास घर पर कुछ देव-सर्वशक्तिमान गेमिंग रिग है, हमेशा देव क्षेत्र में यह पूछने के लिए रोल करता है कि क्या उसे (उत्पाद ए) या (उत्पाद बी) खरीदना चाहिए ... एक असंबंधित नोट में, वह देव टीम को 4Chan (जो वह वास्तव में करता है) पर लटके हुए मानता है। - आह

— ओसोडो

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

— ऐनी शूसेलर

Answer 23

जब प्रोग्रामर कहते हैं कि यह करना बहुत मुश्किल है / बस असंभव है, तो एचआर सोचते हैं कि वे आलसी और अनमोटेड हैं

Comments

प्रबंधन को भी शामिल करें

— प्राशम

जब आप कहते हैं कि वे नहीं सोचते हैं कि आप काम करने के लिए बस एक कठिन व्यक्ति हैं।

— कैप्टन सेंसिबल

+100, और यह कि पर्याप्त "प्रेरणा" के साथ, वे आपके उत्तर को बदल सकते हैं। या किसी अन्य [कम अनुभवी] डेवलपर के पास जाएं और उसे कहने के लिए आधे विवरणों को छोड़ दें और हां, केवल आधे रास्ते के विकास को समाप्त करने के लिए और आपको बताए गए सटीक समस्या में टकराएं।

— Wildpeaks

Answer 24

मेरे व्यवसाय के लिए एक खुला स्रोत कार्यक्रम होना चाहिए। क्या आप इसे डाउनलोड नहीं कर सकते हैं और मेरी आवश्यकताओं के अनुरूप हैं।

Comments

+1। ओह, हाँ, जो कुछ भी करने की ज़रूरत है वह पहले से ही खुले स्रोत में होना चाहिए।

— शार्पूथ

बहुत समय है ... वेब विकास के लिए कम से कम यह सच है।

— WalterJ89

@ WalterJ89: यह वहाँ हो सकता है, लेकिन इसका मतलब यह नहीं है कि यह इसका उपयोग करने के लिए एक अच्छा विचार है। ओपन सोर्स का मतलब अच्छे कोड से नहीं है।

— एलन प्लम

सच है .. लेकिन Wordpress, Drupal, jQuery, के मामले में ... ऐसे क्षेत्र हो सकते हैं जहाँ ई-कॉमर्स की तरह फ्री बहुत बढ़िया नहीं है, लेकिन अधिक बार वेब बहुत खुला नहीं है, और मुझे लगता है कि मुझे इसके साथ काम करने में मज़ा आता है ओपन सोर्स कम्युनिटी, प्रॉपर हेल्प डेस्क से कहीं ज्यादा।

— WalterJ89

इसके विपरीत एक मिथक भी है। आप अपनी व्यावसायिक आवश्यकताओं को पूरा करने के लिए FOSS का उपयोग नहीं कर सकते।

— टर्मिनस

Answer 25

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

मुझे नहीं पता कि मैं उस मिथक को दूर करना चाहता हूं, यह मुझे वास्तव में स्मार्ट दिखता है!

Comments

यह मदद नहीं करता है कि ज्यादातर लोग यह भी नहीं जानते हैं कि प्रोग्रामिंग वास्तव में क्या है ... उनके पास यह अस्पष्ट विचार है कि यह सॉफ़्टवेयर बना रहा है ... लेकिन उन्हें वास्तव में स्पष्ट विचार नहीं है कि सॉफ़्टवेयर क्या है ...

— Spudd86

"हम बुनाई व्यंजनों को लिखते हैं"। दादी समझती हैं।

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

— ज़ाज़

@ जोश - जब तक कोई प्रदर्शन समस्या नहीं है, तब तक यह समय की बर्बादी जैसा लगता है।

— जॉनएफएक्स

@ बूस्टरवाल - असेंबली बाइनरी नहीं है, न ही यह गणितीय प्रतीकों का उपयोग करता है।

— JohnFx

Answer 26

मुझे लगता है कि सबसे बड़ी गलतफहमी यह है कि कोड को पढ़ना और समझने में सक्षम होने की तुलना में कोड को आसानी से लिखना अधिक महत्वपूर्ण है।

Comments

* v (int) (शून्य) ++

— जंग खाए हुए

@ जंग: मैं बहुत अधिक, बहुत खराब उदाहरणों के साथ आ सकता हूं अगर मुझे भी वाक्यविन्यास सही नहीं है।

आह, हाँ, "केवल लिखें" कोड ...

— Paddyslacker

Answer 27

प्रोग्रामिंग सिर्फ असेंबली लाइन के काम की तरह है। आप एक निश्चित समय के लिए एक उत्पाद पर काम कर रहे हैं (शायद सहकर्मियों के साथ) और अंत में आप इसे जहाज करते हैं। जैसे ईंटों का घर बनाना।

कॉन्ट्रा: प्रोग्रामिंग में बहुत अधिक रचनात्मकता और योजना होती है। यह कला है। राजमिस्त्री की तरह, एक प्रोग्रामर भी ईंट को आकार देने और पूरे कैथेड्रल की योजना बनाने के बीच का अंतर जानता है।

Comments

असेंबली लाइन के काम से अंतर के बारे में सहमत - लेकिन कई मायनों में मुझे नहीं लगता कि यह घर बनाने से बहुत अलग है।

— बिली ओनली

Answer 28

C ++ में प्रोग्राम को पोर्ट करने से यह अपने आप तेज हो जाएगा।

Comments

मैं अन्य निम्न स्तरीय भाषाओं का विस्तार करूंगा। यह संभव है जब प्रोग्रामर को यह नहीं पता कि वह क्या कर रहा है।

— Maniero

एक अन्य सामान्य संस्करण क्लाइंट-सर्वर आर्किटेक्चर पर स्विच कर रहा है। "एसक्यूएल में अपग्रेड करने से मेरा ऐप बहुत तेज हो जाएगा!" जरुरी नहीं।

— JohnFx

हाँ, यह कई बार काफी विपरीत है। SQL तरह के डेटाबेस ACID होने के लिए अच्छे हैं या लगभग यह कीमत के साथ आता है। और सबसे खराब हो सकता है, SQL तकनीक के बारे में गलत सोच प्रदर्शन के बारे में हानिकारक हो सकती है।

— मनिएरो

पायथन / पर्ल / रूबी / आदि में लिखे गए लोगों के लिए सी ++ / सी के लिए पोर्टिंग। C / C ++: P में लिखे गए लोगों के लिए asm के लिए पोर्टिंग। मुझे आश्चर्य है कि आप क्या करने के लिए बंदरगाह होगा? हार्डवेयर में इसे डिजाइन करना?

— MAK

@MAK - en.wikipedia.org/wiki/Handel-C

— flamingpenguin

Answer 29

किसी प्रकार के दृश्य डिजाइनर के साथ किसी भी प्रोग्रामिंग वातावरण को ऐसा बना देगा कि व्यावसायिक उपयोगकर्ता प्रोग्राम को "लिख" सकते हैं और वास्तविक प्रोग्रामर की आवश्यकता नहीं है।

Comments

आह येस। यह हमेशा मजेदार होता है जब कोई कंपनी प्रोग्रामर्स को निरर्थक बनाने के लिए एक नया संलेखन उपकरण बनाती है और फिर इसे अपनाने वाला हर व्यक्ति आगे बढ़ता है और अत्यधिक भुगतान किए जाने वाले <संलेखन उपकरण> विशेषज्ञ वास्तव में इसका उपयोग करता है। बिंदु में मामला: जुमला! और वह सब गैर-बोध।

— एलन प्लम

हा हा हा हा हा हा हा +1 :)

— बिली

कोबोल ने पहले ही कोशिश की कि :)

— Carra

Answer 30

OOP का पुन: उपयोग यह प्रोग्रामिंग में सबसे बड़ी गिरावट है।

Comments

कुंआ। एचपी एक्स्ट्रा लार्ज WESM लगभग 85% प्रतीक WS5100 के रूप में ही है (वहाँ OEMming चल रहा है)। क्या आप मुझे मेरे मॉनिटरिंग और कॉन्फ़िगरेशन कोड के उस प्रतिशत की कॉपी-पेस्ट कर सकते हैं जिससे कि दो बार कई कीड़े हैं, या क्या आप पसंद करेंगे कि मैं इसे खरोंच से फिर से लिखूं और चालीस बार लंबे समय तक ले जाऊं और कई बार पांच बार हो? या क्या आप केवल मूर्ख प्रबंधन द्वारा दबाव डाला जाता है जो सोचता है कि $ परियोजना को तेजी से बनाने के लिए यह कई जादुई रामबाणों में से एक है?

छोटे में पुन: उपयोग 40 साल पहले और अधिक हल किया गया था। बड़े में पुन: उपयोग मुश्किल है और अभी तक IMHO हल नहीं हुआ है। जैसे रॉबर्ट ग्लास तथ्य और सॉफ्टवेयर इंजीनियरिंग की गिरावट

— MarkJ