मैं अपने बॉस (विनम्र तरीके से) से उसका कोड कैसे पूछ सकता हूं?


72

मुझे मेरे बॉस द्वारा पढ़ाया जा रहा है (मैंने अभी स्कूल समाप्त किया है और वह किसी को थोड़ा प्रोग्रामिंग अनुभव के साथ चाहता है, इसलिए उसने मुझे चुना कि मुझे उस कंपनी को प्रशिक्षित करने के लिए क्या करना है) और ASP.NET MVC अनुप्रयोगों, कुछ HTML और CSS के साथ काम करना शुरू कर दिया। । मैं वेब डिज़ाइन के सामान के साथ ठीक हूं जो वह मुझे देता है (यह स्पष्टीकरण के बिना समझना बहुत आसान है)।

लेकिन उदाहरण के लिए, वह मुझे ASP.NET MVC के साथ एक कार्य करने के लिए देता है, वह इसे वास्तव में अच्छी तरह से समझाता है। लेकिन उसने मुझे दिए गए कोड में कुछ भी नहीं समझाया। ( विजुअल स्टूडियो 2013 में हम सोर्स कंट्रोल का उपयोग करते हैं ), इसलिए यह शाब्दिक रूप से कोड की सैकड़ों लाइनें हैं, बिना किसी पृष्ठभूमि के जो इसे करना चाहिए। जिस तरह का कोड मैं देख रहा हूं, वह कोड मैंने पहले कभी नहीं देखा है, इसलिए कोशिश करना और पता लगाना वास्तव में मुश्किल है।

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

तो बस कुछ ऐसा है जो मेरी मदद करेगा जब तक मुझे चीजों पर पकड़ नहीं मिलती है, मैं अपने बॉस को अपने कोड में टिप्पणी करने के लिए कैसे कह सकता हूं जो वह मुझे देता है, लेकिन विनम्रता से?


2
टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है ।
maple_shaft

1
स्रोत कोड इंडेक्सिंग और नेविगेशन टूल्स जैसे कि सोर्सग्राफ का उपयोग करने के लिए पूछने का एक विकल्प है ।
दान डस्केल्सस्कु

मैंने हाल ही में एक बड़ी (> 100k लाइनों) एमवीसी 5 एप्लिकेशन पर काम करने वाली टीम में शुरुआत की। पूरी बात के लिए 150 यूनिट परीक्षण हैं और वे पिछले कुछ महीनों में मेरे द्वारा जोड़े गए हैं। कोड में कुछ टिप्पणियां ज्यादातर अन्य भाषाओं में हैं। Welcome to business programming :)
मार्क के।

"मैं कैसे X को Y करने के लिए कहता हूं" जैसे प्रश्न आमतौर पर वर्कप्लेस पर बेहतर होते हैं जब एक्स में एक सहयोगी शामिल होता है।
ब्लर एफएल

जवाबों:


130

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

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

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


185
+1 के लिए "कोड की हज़ारों पंक्तियों के सामने बैठे रहने से आप परिचित नहीं हैं" - यह प्रोग्रामिंग पाठ्यक्रमों में कभी नहीं दिखाई देता है और यह हमेशा नौकरी में दिखाई देता है।
pjc50

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

9
ठीक ठीक। प्रोग्रामिंग-ए-ए-ट्रेड को प्रभावी रूप से अप्रेंटिसशिप (संभवतः स्वयं-सिखाया गया) की आवश्यकता होती है, जबकि सीएस पाठ्यक्रमों में बहुत कम वास्तविक प्रोग्रामिंग हो सकती है। वे सहजीवी हैं, लेकिन समान नहीं हैं। आपको एक महान प्रोग्रामर बनने के लिए विश्वविद्यालय जाने की आवश्यकता नहीं है, लेकिन यह काम पर रखने के लिए बहुत आसान बनाता है, भले ही आपके पास जिस काम के लिए आवेदन कर रहे हों, उस पाठ्यक्रम की थोड़ी प्रासंगिकता हो।
pjc50

11
@AidanQuinn, Impostor syndrome ( en.wikipedia.org/wiki/Impostor_syndrome ) किसी नए काम की शुरुआत में कठिन और आपके पहले की शुरुआत में भी इतना ही किक कर सकता है। यदि वह कहता है कि आप बहुत अच्छा कर रहे हैं, तो उसे अपने शब्द पर ले जाएं।
सेलोस

6
प्रोग्रामिंग समय के बहुमत के साथ अक्षम महसूस कर रहा है एक छोटी सी ईश्वर समान प्रतिभा की भावना के फटने से।
MrDosu

75

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

आपके और एक अनुभवी प्रोग्रामर के बीच सबसे बड़ा अंतर यह है कि आप इसके लिए अभ्यस्त नहीं हैं।


ध्यान में रखने के लिए कुछ बिंदु:

  1. पर्याप्त प्रयास के साथ, हर बिट कोड समझ में आता है। बहुत सारे लोग निराश महसूस करते हैं अगर वे कुछ मिनटों के भीतर कुछ पता नहीं लगा सकते हैं। उससे अधिक धैर्य रखें।

  2. एक अच्छा बॉस रुकावटों और सवालों के लिए जितना संभव हो उतना खुला है। एक अच्छा कर्मचारी रुकावटों और सवालों को कम से कम करने की यथासंभव कोशिश करता है। उसके प्रति सचेत रहें।

  3. व्यवधान सवालों की तुलना में अधिक महंगा है। आप अपने समय और अपने बॉस के समय का बेहतर उपयोग करके अपनी चर्चाओं को समेकित कर सकते हैं, और कभी भी भ्रमित होने वाली बातचीत को समाप्त नहीं कर सकते।

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

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

अंत में, हालांकि, यह संभव है कि अब से कुछ महीने बाद आप यह पूछना याद रखेंगे और सोचेंगे, "हुह, मुझे आश्चर्य है कि मुझे क्या समस्या थी? यह उतना बुरा नहीं है। हम्म, अच्छा, कोई बात नहीं।"


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

1
ditto को @Phil आप आश्चर्यचकित होंगे कि आपने ईमेल में एक स्पष्ट प्रश्न का सावधानीपूर्वक वर्णन करते हुए कितने प्रश्नों का उत्तर अपने दम पर दिया है। बस सटीकता के साथ अपने भ्रम को समझाने की प्रक्रिया रोशनी को चालू कर सकती है। आपको बता नहीं सकता कि मैंने कितनी बार उस तरह के ईमेल लिखे हैं जो कभी नहीं भेजे गए क्योंकि मैंने इसे खोज लिया था।
kmote

3
@kmote, मेरे पास कई अनकैपेड स्टैक ओवरफ्लो प्रश्न हैं जो उसी तरह से हुए हैं :)
पॉल ड्रेपर

18

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

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

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


3
आप अपने बॉस को कुछ टिप्पणियां जोड़ने वाले पैच का प्रस्ताव भी दे सकते हैं ।
बेसिल स्टेयरनेविच

2
@BasileStarynkevitch: बेशक, किसी चीज को तोड़ने के जोखिम से बचने के लिए, वह टिप्पणियों को पहले एक अलग शाखा में जोड़ सकता है और अपने बॉस से कह सकता है कि वे ट्रंक में विलय होने से पहले टिप्पणियों की समीक्षा करें।
डॉक ब्राउन

2
@DocBrown एक अलग शाखा में काम करना सामान्य रूप से एक अच्छी रणनीति है, लेकिन अगर टिप्पणियों को जोड़ने से कुछ टूट जाता है, तो मैं कहूंगा कि कोडबेस में बड़ी समस्याएं हैं ......
एक CV

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

@ माइकलकॉर्जलिंग यह कुछ तोड़ने वाली टिप्पणियों के बारे में नहीं है, लेकिन टिप्पणियों को वास्तविक कोड के साथ मिलान करने की आवश्यकता है।
ह्यूगो जिंक

8

सबसे पहले यह आपके लिए एक उदाहरण है कि आप अपने कोड को ठीक से टिप्पणी करें, टिड्डे!

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


5

यह केवल एक व्यक्तिगत अनुरोध से अधिक है। आप आदतों / संस्कृति को बदलने की कोशिश कर रहे हैं, और यह आसान नहीं है। यह निश्चित रूप से ऐसा कुछ नहीं है जिसे एक दालान वार्तालाप या एक ई-मेल द्वारा पूरा किया जा सकता है। यह आपकी ओर से कुछ प्रयास करने जा रहा है।

वह बदलाव बनिए जो आप दुनिया में देखना चाहते हैं।

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

  • आप पागल होने के बजाय, सक्रिय हो रहे हैं।
  • आप एक अच्छा उदाहरण सेट कर रहे हैं। सबसे अच्छी स्थिति में, आपके बॉस / टीम को लाभ दिखाई देगा और उसका अनुसरण किया जाएगा।
  • टिप्पणियों में से कुछ शायद कहेंगे /* Mystery parameter 3 */या /* 2015-02-09 AidanQuinn: Is this code ever called? */- वे आपके सहकर्मियों के लिए कोड को ठीक से दस्तावेज़ करने या अव्यक्त बग को ठीक करने के अवसर हैं।
  • यदि, पूर्व-प्रतिबद्ध समीक्षा के दौरान, यह पता चला है कि आपने जो टिप्पणी लिखी है वह गलत है, तो अब आपके सहयोगियों को पता है कि कोड अस्पष्ट था।

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

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


5

मैं अतिरिक्त टिप्पणियों के लिए नहीं कहूंगा, लेकिन यहां आपके लिए कुछ विचार हैं:

  1. अपने बॉस के साथ बैठने का कार्यक्रम निर्धारित करें और उसे उच्च स्तर पर कोड के माध्यम से जाने दें। इससे आप कार्य शुरू कर पाएंगे। मैं शायद आधे घंटे के लिए कुछ घंटे की उम्मीद करूंगा ताकि आप गति प्राप्त कर सकें। इसमें समग्र डिजाइन, उपयोग किए गए पैटर्न आदि शामिल होने चाहिए।
  2. एक परीक्षण परियोजना बनाएं और कोड के खिलाफ इकाई परीक्षण लिखना शुरू करें, इससे आपको इसे प्रभावित किए बिना समझने में मदद मिलेगी। आप कुछ कीड़े भी पा सकते हैं!
  3. कुछ क्षेत्रों को समझने के लिए आवश्यकतानुसार कोड को डीबग करें।
  4. एन्हांसमेंट लें या बैकलॉग बंद करें और उस पर काम करें।

टिप्पणियाँ ठीक हैं, लेकिन अगर कोड को सीधे आगे तरीके से लिखा गया है तो इसे कुछ दिनों के बाद समझना चाहिए।

इसके अलावा यह सब समझने की उम्मीद न करें, पहले मुख्य क्षेत्रों पर ध्यान केंद्रित करना बेहतर है और फिर आवश्यकतानुसार कोड आधार ज्ञान का विस्तार करना है।


2

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

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

इसके अलावा, मुझे @AK_ से सहमत होना होगा जिन्होंने कहा था कि आपको C # में टिप्पणियों की आवश्यकता नहीं है। यह 100% सही नहीं हो सकता है (मुझे लगता है कि ऐसे क्षेत्र हैं जहां टिप्पणियां निश्चित रूप से मदद करती हैं, उदाहरण प्रतिबिंब-भारी कोड) लेकिन संक्षेप में यह है। यदि आप अच्छी तरह से नामित विधियों और चर के साथ वास्तव में 'क्लीन कोड' लिखते हैं, और कोड के बहुत सारे छोटे 'काटने' हैं, तो वे लगभग पूरी तरह से अनावश्यक होंगे। हर बार जब मुझे अब तक कोड पढ़ते समय टिप्पणियों की आवश्यकता महसूस होती है, तो मुझे समझ में आने के बाद कि यह क्या हुआ, मैं जिस तरह से किया गया था उससे बहुत दुखी था और सोचा था कि यह अच्छी रीफैक्टरिंग द्वारा पहली जगह में रास्ता साफ कर सकता है। संपादित करें: मैं विशेष रूप से C # टिप्पणियों के बारे में यहां बात कर रहा हूं , न कि प्रलेखन (यह अलग प्रलेखन या XML टिप्पणी हो), क्योंकि मुझे लगता है कि प्रलेखन हमेशा महत्वपूर्ण होता है।

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

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

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

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


1

आप शायद उसे अपनी शैली बदलने के लिए नहीं जा रहे हैं।

आप जो कर सकते हैं वह बहुत से प्रश्न पूछते हैं, और उत्तर लिख देते हैं।

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

सौभाग्य!


1

मुझे भी यही समस्या आ रही थी। Im छात्र फ़िज़िस्ट का और अच्छा प्रोग्रामिंग अनुभव है। मैं कई भाषाओं में प्रोग्राम कर रहा था लेकिन प्रीमियम एप्लायन्स के लिए कुछ भी नहीं।

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

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

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

यदि आप बॉस से सीखेंगे, तो आप कभी भी उससे बेहतर नहीं बनेंगे कि वह अपना मानक खुद तय करे, अपने आई डी, लिनक्स wmii के लिए अंधा टाइपिंग, VIM या VIM प्लगइन सीखे, तो आप किसी दिन बॉस से आगे निकल जाएँगे, और उससे बेहतर बनेंगे!


यह पोस्ट पढ़ना मुश्किल है (पाठ की दीवार)। आप आपत्ति तो नहीं है संपादित एक बेहतर आकार में यह ing?
gnat

मेरी अज्ञानता के लिए खेद है :)

अपडेट की गई पोस्ट को समझना बहुत आसान है (अच्छा संपादन!), लेकिन जो मैं देख सकता हूं वह अब केवल पहले से किए गए दोहराने वाले बिंदुओं (और विशेष रूप से बेहतर तरीके से समझाए गए) के लिए लगता है, विशेष रूप से इस एक में
gnat

1
मुझे माफ करना, मैं नौकरी से पहले सुबह यह कर रहा हूं और मेरे पास इतना समय नहीं है, इस उद्देश्य के लिए कि सवाल मालिक देखेंगे, मुझे परवाह नहीं है :)

0

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

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

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

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

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


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

आपके उत्तर के अंतिम तीन पैराग्राफ काफी उपयोगी हैं, @ ग्राहम। कृपया कुछ निराश न करें आपको हतोत्साहित करते हैं।
डेविड एफएस

मैं नीचे देखकर हैरान था। क्या, कैसे और क्यों टिप्पणी के बारे में जानकारी मृत है। मैं दूसरों से सहमत हूं कि उनके बॉस की क्षमता पर आपका अटकलबाजी अनुत्पादक है।

@ सुपरस्टारचेसी: दुर्भाग्य से, आप अक्सर "मॉम और ऐप्पल पाई" के अलावा किसी अन्य पद को धारण करने के लिए उतर जाते हैं। आपने जो कुछ कहा, उससे मैं असहमत हूं (पहला पैराग्राफ नहीं! यह पूरी तरह से मान्य IMO है) - लेकिन आप अभी भी सिद्धांत के साथ उठते हैं।
einpoklum

0

इसी तरह की स्थिति में, मैं कहूँगा

  1. हो सकता है कि आपका बॉस किसी कारण से आपके द्वारा गंदे तरीके (कोड के माध्यम से आपके पास कोई सुराग नहीं है) के माध्यम से सीखना चाहता हो। यह वह तरीका है जो हम एक महीने में कॉलेज में एक साल में अधिक सीखते हैं जैसा कि अन्य उत्तरों में बताया गया है।

  2. अन्य उत्तरों में वर्णित यह "आदर्श" है। आपको इस बारे में अधिक चिंतित होना चाहिए कि कहां शुरू करना है और कैसे दृष्टिकोण करना है और कोड की प्रत्येक पंक्ति को तुरंत समझने की कोशिश करने की तुलना में क्या ध्यान केंद्रित करना है। अपने बॉस से सही टूल और कोड के माध्यम से डिबग / स्टेप करने के तरीकों के बारे में पूछें। इस तरह के प्रश्न आपको कुछ अंक खरीदेंगे।

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

  4. इसे एक अवसर के रूप में लें और जैसा कि आप कोड को समझने के साथ बेहतर हो जाते हैं, उन टिप्पणियों को जोड़ते रहें जो आप मूल रूप से अपने बॉस से पूछना चाहते थे।


0

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

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


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

मुझे लगता है कि हम पूर्ण समझौते के निकट हैं। मैं उन टिप्पणियों के साथ स्व-दस्तावेजीकरण कोड का लक्ष्य रखता हूं जहां चीजें तनावपूर्ण हो जाती हैं।
dkippers 20

0

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

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


0

जैसा कि दूसरों ने उल्लेख किया है, यह काफी सामान्य है, लेकिन इसका मतलब यह नहीं है कि आपको इसे चूसना और हल करना होगा। आपको कोड के उतने गहराई से समझने की जरूरत नहीं है जितना आप सोचते हैं, और "गहरी समाप्ति" को बहुत उथला बनाने के लिए ठोस रणनीति है:

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

0

यहाँ इस मामले पर मेरी $ 0.02 हैं। मैं कोई विशेष उत्तर नहीं दे रहा हूं, यहां जो कहा गया है वह काफी प्रासंगिक है।

मैं चीजों को व्यवस्थित करने के लिए सोशल इंजीनियरिंग की थोड़ी कोशिश करूंगा ताकि आपके बॉस को उनके कोड की तुलना में कुछ टिप्पणी करने में आसान / कम समय लेने वाला लगे।

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

फिर विकल्प क्या है? कुछ विचार, परिस्थिति पर निर्भर करते हैं।

विकल्प 1

  1. एक्स करने के रूप में उसके कोड के एक टुकड़े को समझने के लिए समय निकालें।
  2. अब इसे गलत समझने के लिए एक उचित तरीका वाई के बारे में सोचें ।
  3. बॉस को बताएं (ईमेल के माध्यम से या नाश्ते पर कहें या क्या नहीं) जिसे आप वर्तमान में जानने की कोशिश कर रहे हैं।
  4. एक टिप्पणी यह ​​कहते हुए जोड़ें कि यह स्पष्ट नहीं है कि कोड का क्या अर्थ है, लेकिन आप इसे वाई समझते हैं; इस टिप्पणी को उसे दृश्यमान बनाने की कोशिश करें - लेकिन बहुत कठिन प्रयास न करें!
  5. Y मान कर कार्य करें - और सुनिश्चित करें कि आपके बॉस ने आपकी कार्रवाई को नोटिस किया है (ताकि आप एक झूठी धारणा पर लंबे समय तक अपना समय बर्बाद न करें)।
  6. बॉस को आपको सही करने की पहल करनी चाहिए। इस बिंदु पर, उसे कुछ ऐसा बताएं, "मुझे लगता है कि इस कोड में मुझे गलत धारणा बनाने से रोकने के लिए टिप्पणियों की एक जोड़ी थी। मैं खुद के लिए मेरे द्वारा जोड़ी गई टिप्पणी को सही कर दूंगा। क्या आपको लगता है कि आप कुछ सामान्य विवरण के साथ मेरी मदद कर सकते हैं। इस कोड के टुकड़े और मुझे सटीक इरादे का पता लगाने के लिए पर्याप्त अनुभव नहीं है, और मैं सिर्फ एक-दो वाक्य करूंगा। " या कुछ और..

विकल्प 2

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

विकल्प 3

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


0

तो बस कुछ ऐसा है जो मेरी मदद करेगा जब तक मुझे चीजों पर पकड़ नहीं मिलती है, मैं अपने बॉस को अपने कोड में टिप्पणी करने के लिए कैसे कह सकता हूं जो वह मुझे देता है, लेकिन विनम्रता से?

यदि आप कोड को नहीं समझ सकते हैं, तो आपको क्यों लगता है कि टिप्पणियाँ आपके समाधान हैं?

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

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


0

यहां तक ​​कि अगर इस विनम्रता से पूछने का कोई तरीका है, तो दो संभावनाएं हैं कि आपका बॉस अपने कोड में टिप्पणियों के बारे में क्या सोचेगा:

  1. या तो उसके कोड में टिप्पणी एक अच्छी बात होगी, या

  2. उनके कोड में टिप्पणी करना अच्छी बात नहीं होगी।

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

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

इसलिए, जब तक आपको ऐसा करने के लिए तैयार नहीं किया जाता है, तब तक आप कुछ भी नहीं कहने से बेहतर हो सकते हैं।

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