जूनियर प्रोग्रामर्स को अपनी कमियों को दूर करने में मदद करना? [बन्द है]

Question

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

मेरा मतलब अंतर-वैयक्तिक कौशल जैसे 'सलाह सुनना,' से मेरा तात्पर्य तकनीकी मामलों से है जैसे (यदि लागू हो):

• 'तुमने एसक्यूएल कभी नहीं किया है?'

• 'आपने कभी यूनिट टेस्ट नहीं लिखा है?'

• 'आप यूनिक्स कमांड लाइन का उपयोग नहीं जानते हैं?'

ऐसी चीजें जो आप उम्मीद करते हैं - मैं इन विशिष्ट कमियों से पिछले करने के लिए नए प्रोग्रामर को पढ़ाने के लिए आपकी टिप्पणियों और तकनीकों को सुनना चाहूंगा।

Comments

एकल सबसे परेशान करने वाली बात: लगातार परेशान होने के बारे में पूछना। :-)

— जैरी कॉफ़िन

मुझे नहीं लगता कि जब लोग उन चीजों को नहीं जानते हैं जिनसे आप उन्हें जानना चाहते हैं, तो आपको चिढ़ होना चाहिए। क्या महत्वपूर्ण है कि वे सीखने के लिए तैयार हैं =)

— koenmetsu

हाँ @KoMet के साथ सहमत हूँ अगर आपके पास सुनने के लिए सीखने की इच्छा है, तो मुझे लगता है कि इसके महत्वपूर्ण :)

— MalsR

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

— Darknight

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

— एंड्रयू एम

Answer 1

यह नहीं पता कि संस्करण नियंत्रण क्या है, या इसे ठीक से कैसे उपयोग किया जाए ।

जूनियर डेवलपर्स में से एक जो कई महीनों से मेरी कंपनी में है, उसे हाल ही में तोड़फोड़ की मूल बातें सिखाई जानी थीं। यह वास्तव में मुझे परेशान कर रहा है ... वह पूरे समय लाइव परियोजनाओं के लिए कोड में जाँच कर रही है ... और पता नहीं था कि वह क्या कर रही थी ...?

Comments

चापलूसी? वह भाग्यशाली है कि उसके पास अभी भी एक नौकरी है।

— रेन हेनरिच

ऐसा लगता है कि यह "न जाने क्या-क्या नहीं जानता" या "जो आप नहीं जानते उसे स्वीकार नहीं करने की बात" है। अगर उसने शुरू से मदद मांगी होती, तो क्या यह बहुत बड़ी बात होती?

— माइकल मैकगोवन

ouch, यह मुझे हाहा की तरह लग रहा था, हमने हाल ही में संस्करण नियंत्रण लागू नहीं किया था, और मैं कंपनी में नए सिरे से ग्रेड के रूप में शामिल हो गया, मैंने विश्वविद्यालय में संस्करण नियंत्रण और तोड़फोड़ की थोड़ी सी बात सीखी, लेकिन इसे पहले कभी लागू नहीं किया।

— सूफेंडी

"यह बैकअप के लिए उपकरण है ना? आप हर शाम अपने कोड को बचाने के लिए इसका इस्तेमाल करते हैं?"

— डेविड

यह एक बड़ी बात है कि वे आपको लगभग कभी भी स्कूल में नहीं पढ़ाते हैं

— एलियाह सौनकिन

Answer 2

पर्याप्त सवाल नहीं पूछ रहा

मुझे पता है कि वे जूनियर हैं, मुझे उम्मीद है कि वे गलतियाँ करेंगे और बस चीजों को नहीं जानते हैं। इतने सारे शाही च ** k अप्स को केवल कुछ मानने के बजाय एक सवाल पूछने से बचा जा सकता था। ईमानदारी से कहूं तो मुझे काफी परेशान नहीं किया जा सकता।

मैं था टन सवालों का जब मैं बाहर शुरू कर दिया - पूछ उन्हें कई मौकों पर मेरे गधे को बचा लिया। नरक, मेरे पास अभी भी बहुत सारे सवाल हैं ... मुझे लगता है कि वे अब बेहतर सवाल करना चाहते हैं।

Comments

जी ... लगभग एक ही जवाब मैंने पोस्ट किया है, आप पहले लगभग 5 सेकंड में जाते हैं।

— जल्‍दी से जल्‍दी से जल्‍दी quickly

"आप परेशान हैं !! मैं यहाँ व्यस्त हूँ, क्या आप अपने आप से नहीं सोच सकते?" अगर आप बदकिस्मत हैं !! हाहा

— सूपेन्डी

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

— Péter Török

दूसरी ओर, कुछ लोग बहुत अधिक प्रश्न पूछते हैं (स्टैक ओवरफ्लो पर)।

— बोल्टलोक

@SnOrfus: वे अयोग्य लोग हैं जिनका मैं उल्लेख कर रहा हूं: P

— BoltClock

Answer 3

अंतर्निहित मूल सिद्धांतों को समझने के बजाय पेस्ट और परीक्षण और त्रुटि की प्रतिलिपि बनाएँ

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

कोड का उनका "पहला मसौदा" रखते हुए

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

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

Comments

+1 "समझने की तलाश करने के बजाय कॉपी और पेस्ट करें", हालांकि निश्चित रूप से यह नए प्रोग्रामर के लिए अद्वितीय समस्या नहीं है, बस बुरे लोगों के लिए। नए प्रोग्रामर के पास कम से कम इसके बढ़ने का एक मौका है - दोस्तों मैं उन लोगों के साथ काम करता हूं जो दशकों से प्रोग्रामर हैं और अब भी ऐसा नहीं करते हैं।

— टॉम एंडरसन

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

— जेमी मैकग्यूगन

Answer 4

विश्वास है कि आप पहली बार किसी स्थिति का सामना कर रहे हैं।

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

संपादित करें :

बस स्पष्ट होने के लिए, मैं कॉपी / पेस्ट प्रोग्रामिंग की वकालत नहीं कर रहा हूं । हालाँकि, मैं निश्चित हूँ, कि मौजूदा ज्ञान की समीक्षा करने से पहले आपको स्वयं अच्छे निर्णय लेने की आवश्यकता है।

Comments

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

— एलियाह सौनकिन

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

— सेटज़ामोरा

ज़रूर, लेकिन @Scott ने कोड को कॉपी और पेस्ट करने के बारे में कुछ नहीं कहा, उन्होंने कहा कि आप यह नहीं मान रहे हैं कि आप किसी स्थिति का सामना करने वाले पहले व्यक्ति हैं, यह महसूस करें कि वहाँ कुछ जानकारी और अनुभव हो सकते हैं जिनसे आप लाभ उठा सकते हैं। उदाहरण: मैं जानना चाहता हूं कि क्या दो तार समान हैं। क्या इस समस्या को हल करने के लिए पहले से ही एक ज्ञात एल्गोरिदम है? कल्पना कीजिए कि अगर किसी डेवलपर ने यह जानते हुए भी कि वे पहले से मौजूद हैं, तब भी अपना रोल शुरू करने का फैसला किया ।

— डेविड कॉनराड

@ डेविड कॉनराड यह सही है, बिंदु लिया गया है, हम यहां एक ही पृष्ठ पर हैं।

— एलिजा सौनकीन

Answer 5

यह सोचकर कि वे सब कुछ जानते हैं।

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

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

Answer 6

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

Comments

@ ग्रेग बहुत सी बातें सही हैं जो हमें जूनियर डेवलपर्स के बारे में परेशान करती हैं। वे ऐसी चीजें हैं जो हमें किसी विश्वविद्यालय में नहीं बल्कि एक हास्य वातावरण में सीखनी थीं।

— Nickz

Answer 7

उनके ज्ञान को आगे नहीं बढ़ाना चाहते - इसके बजाय कम से कम प्रतिरोध का रास्ता अपनाएं।

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

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

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

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

Comments

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

— मैक्सिम गेर्शकोविच

Answer 8

OOP को नहीं समझ रहा है। अफसोस की बात है कि यह हम में से ज्यादातर आम तौर पर एहसास है।

एक वर्ग, अमूर्त वर्ग, इंटरफ़ेस, या यहां तक ​​कि बहुरूपता को बनाने का तरीका जानना एक बात है; यह समझना कि आपके कार्यक्रम के लाभ के लिए उन्हें कैसे ठीक से उपयोग करना है ।

---

यदि आप इससे बचना चाहते हैं, तो मुझे ये प्रश्न और उनके ज्ञानवर्धक उत्तर मिले:

• कोड गंध: वंशानुक्रम दुर्व्यवहार - विरासत की कड़ियाँ
• "वंशानुक्रम पर अनुकूल रचना" की यह अवधारणा कहाँ से आती है? - विरासत से बचने के बारे में मंत्रों की परिधि

Comments

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

— एंड्रयू एम '

@ और मैंने उत्तर को थोड़ा विस्तारित किया है।

— निकोल

और मुझे अनुमान है: केवल OOP पढ़ाए जाने के कारण सी में सादे पुराने प्रक्रियात्मक कोड को लिखना नहीं जानता। तो फिर, मुझे उन लोगों के बारे में मत बताइए, जिन्हें पार्सर्स लिखना नहीं सिखाया जाता है क्योंकि उन्हें बताया जाता है कि उन सभी समस्याओं का हल lex और yacc का उपयोग करके निकाला जा सकता है।

— जल्दी_अगला quickly

@quickly_now यह एक अच्छा बिंदु है, हालांकि writing code other ways than OOPऔर writing bad OOPदो बिल्कुल अलग चीजें हैं। पहला, मेरे पास कोई समस्या नहीं है।

— निकोल

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

— Cervo

Answer 9

आप जो नहीं जानते हैं, उसे न जानते हुए, और अज्ञान सोच में आप सब कुछ जानते हैं।

(और इसके करीबी चचेरे भाई, पूछना नहीं चाहते।)

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

Answer 10

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

यहाँ एक साक्षात्कार प्रश्न है जिसका उपयोग मैं लगभग सभी जूनियर प्रोग्रामर को याद करता हूं जो इस मुद्दे पर प्रकाश डालता है:

वह कोड लिखें जो Nth फाइबोनैचि संख्या की गणना करता है ।

वे लगभग हमेशा सबसे स्पष्ट-लेकिन-अक्षम लिखने के लिए जाते हैं

int Fib(int n)
{
    if (n == 0) return 0;
    if (n == 1) return 1;
    return Fib(n-2) + Fib(n-1);
}

जब एल्गोरिथम जटिलता पर टिप्पणी करने के लिए कहा जाता है, तो मुझे आमतौर पर "यह ओ (एन) ... उम्म ... ओ (एन लॉगएन") से भी बदतर होता है। यह वास्तव में (बहुत) इससे भी बदतर है ...

Comments

कंप्लेक्सिटी के बारे में आपके प्रश्न का उत्तर देने के लिए, किसी को पुनरावृत्ति के बिना रिट्रेसमेंट संख्याओं की गणना करने के लिए उस फॉर्मूले को जानना चाहिए, जिसका उपयोग वह पहले स्थान पर पुनरावृत्ति के बजाय करेगा।

— पी शेव्ड

@Pavel: इसमें एक O (n) और एक O (1) समाधान है ... वास्तव में Like every sequence defined by linear recurrence, the Fibonacci numbers have a closed-form solution. en.wikipedia.org/wiki/Fibnote_number#Closed-form_expression

— Eric J.

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

— बनायी

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

— पी शेव्ड

व्यावहारिक रूप से, इस तरह के फ़ंक्शन को एक प्रोफाइलर का उपयोग करके और एक संस्मरण कैश में जोड़कर अनुकूलित किया जा सकता है। अक्षमता केवल एन के बड़े मूल्यों के लिए वास्तव में एक समस्या है। ऐसे कोड के बारे में एक जूनियर को पढ़ाने का सबसे अच्छा तरीका है कि उन्हें डिबगर का उपयोग करके पूरे कोड निष्पादन के माध्यम से कदम उठाने के लिए मजबूर करना है। एन के वास्तव में बड़े मूल्यों के लिए, यह पता चला है कि एक गणितीय सूत्र है mathsurrey.ac.uk/hosted-sites/R.Knott/Fibnote/…

— जैमी मैकग्यूगन

Answer 11

पीछे की ओर कोड इंडेंटेशन करना!

बेशक यह बहुत "विशिष्ट" नहीं है। मैं कभी भी विश्वास नहीं कर सकता था कि यह संभव है, लेकिन एक सामान्य डेवलपर क्या लिखेगा

try {
    switch(action){
        case case1:
            ...
            break;
        case case2:
            ...
            break;
        default:
            break;
    }
}
catch(Exception e) {
    e.printStackTrace();
}

वह (भगवान की तरह), यह अभी भी मुझे असंभव लगता है!

            try {
        switch(action){
    case case1:
...
break;
    case case2:
...
break;
    default:
break;
        }
            }

निराशा होती है ना?

Comments

क्या नाम में ...

— माइक स्पीड

यह बहुत अद्भुत है !!!

— जावन्ना

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

— जेमी मैकगुइगन