क्या मुझे अपना स्वयं-सिखाया कोडिंग अभ्यास जारी रखना चाहिए या पेशेवर तरीके से कोडिंग करना सीखना चाहिए? [बन्द है]


36

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

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

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

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

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


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

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

1
"उन लोगों की शैली से अत्यधिक विचलन जो ठीक से प्रशिक्षित हैं" पृथ्वी पर यह जगह कहां है? कभी भी मुझे ऐसा ग्रेड नहीं मिला, जो ठीक से प्रशिक्षित हो।
रिएक्टगुलर

2
मुझे उन और लोगों के साथ काम करने में खुशी होगी, जिन्होंने क्लोजर को समझा, अकेले फंक्शनल प्रोग्रामिंग का इस्तेमाल करने के बारे में सोचा था ...
इज़काता

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

जवाबों:


62

वास्तव में मैं इस तथ्य से डर गया हूं कि लोग अंततः मेरे कोड की जांच करेंगे।

अच्छा। सचेत होने के नाते कि लोग आपके कोड को देखने जा रहे हैं, आप कठिन प्रयास करेंगे।

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

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

मैं प्रोग्रामिंग के बारे में बहुत सी बातें जानता हूं, मैंने कई परियोजनाओं में एक दर्जन भाषाओं का उपयोग किया है, और फिर भी प्रोग्रामिंग ज्ञान का सबसेट जिसे मैं खुद कह सकता हूं, वह छोटा है। और मुझे वह पसंद है। सच कहूँ तो, एक प्रोग्रामर कुछ आप नहीं हैं। एक प्रोग्रामर एक ऐसी चीज है जिसे आप लगातार बनना सीख रहे हैं।

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


44
एक प्रोग्रामर एक ऐसी चीज है जिसे आप लगातार बनना सीख रहे हैं । क्या मुझे इसका चीनी अनुवाद करना चाहिए और इसका एक टटू बनाना चाहिए?
रादु मुरझिया

1
@SoboLAN मैं आपको ऐसा करने की अनुमति देता हूं। मुझे चित्र चाहिए, हालांकि!
asfallows

2
codereview.stackexchange.com एकमात्र ऐसी वेबसाइट है जिसे मैं ऑफहैंड जानता हूं, हालांकि मुझे यकीन है कि अन्य लोग भी हैं। हालांकि व्यक्तिगत रूप से इसकी समीक्षा करने और एक पर एक से बात करने के लिए बहुत सारे मूल्य हैं। हो सकता है कि आपके पास एक मित्र के साथ एक कॉलेज / विश्वविद्यालय हो जो आपसे मिलने के लिए तैयार हो? यही सबसे अच्छी बात है कि मैं मौके पर सोच सकता हूं - शायद दूसरों के पास बेहतर विचार होंगे।
asfallows

1
मेरी राय में असली परीक्षा यह है कि अगर आपने कोड को भेज दिया है जो अन्य लोग वास्तव में उपयोग करते हैं।

4
@ ThorbjørnRavnAndersen: और पहली बार जब आप महसूस करते हैं कि लोग वास्तव में आपके द्वारा उत्पादित वस्तुओं का उपयोग कर रहे हैं, तो आप पहली बार में बहुत भयावह हो सकते हैं। और बाद में बहुत सशक्त। और फिर भयावह रूप में, जैसा कि आपको लगता है कि बड़ी गलती है कि ;-)
जोआचिम सॉर

16

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

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

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

यदि आप इकाई परीक्षणों के बारे में कुछ नहीं जानते हैं, तो एक अच्छी पुस्तक खरीदें। वहाँ यूनिट परीक्षण पर अच्छी पुस्तकों के बहुत सारे हैं। MVC के साथ भी।

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


5

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

कला घटक मजेदार है: आप इसे करते हैं क्योंकि आप इसका आनंद लेते हैं। स्वाभाविक रूप से, यह वह हिस्सा है जो आप पहले खुद को सिखाते हैं।

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

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

अपने प्रश्न पर वापस, कला घटक पर ध्यान केंद्रित करना प्रोग्रामर के विकास का एक प्राकृतिक प्रारंभिक चरण है। अनुशासन घटक की सराहना शुरू करने से पहले आपको उद्योग में काम करने में कई साल लग सकते हैं। आपको "अपनी तकनीकों को बदलने" को सक्रिय रूप से देखने की आवश्यकता नहीं है, हालांकि: वे एक टीम में काम करने की प्रक्रिया में स्वाभाविक रूप से रूप में बदल देंगे।


3

अपने प्रश्न के लिए, हां, आपको अपनी तकनीक को बदलने के लिए, अनूठी परियोजना और उभरती हुई तकनीक को अपनाने के लिए हमेशा तत्पर रहना चाहिए।

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

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

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

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


2

आपको अधिक टिप्पणी करने की आवश्यकता नहीं है। लेकिन आपको एक अच्छा कॉमिटर होना चाहिए (हाँ, कुछ प्रकार के वीसीएस का उपयोग करना शुरू करें - मैं गिट की सलाह देता हूं)।

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

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


2

वास्तव में मैं इस तथ्य से डर गया हूं कि लोग अंततः मेरे कोड की जांच करेंगे। क्या यह सिर्फ सामान्य है जो किसी भी प्रोग्रामर के माध्यम से होता है या मुझे वास्तव में अपनी तकनीकों को बदलना चाहिए?

आपको कैसे पता चलेगा कि अधिक अनुभवी प्रोग्रामर से कुछ प्रतिक्रिया के बिना क्या बदलना है?

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


2

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

हर चीज को सीखने में महारत कम होती है / सीखने के लिए होती है, और अधिक सीखने / कैसे / किसी समस्या को सुलझाने के बारे में, विभिन्न स्थितियों में।

और उस के लिए सबसे अच्छा नुस्खा अभ्यास है। आपके पास हमेशा एक परियोजना होनी चाहिए; यदि आप भुगतान किए गए गिग्स के बीच हैं, तो एक व्यक्तिगत खिलौना लें। एक सप्ताह का समय? उस भाषा या मंच के लिए 'हैलो वर्ल्ड' के माध्यम से कार्य करें, जिसका आपने पहले कभी उपयोग नहीं किया है। एक बार में बहुत कुछ सीखने के तरीकों की तलाश करें। उदाहरण के लिए, Google App Engine में कुछ बनाएँ, और आप पायथन, बिगटेबल और कॉलम-ओरिएंटेड डेटाबेस के बारे में एक बार में जान जाएंगे। आपको "पेशेवर" Google शैली की एक अच्छी खुराक मिल जाएगी।

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

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


आपका पहला पोस्ट किया गया जवाब देने के लिए धन्यवाद जॉनी और स्टाॅक एक्सचेंज में प्रोग्रामर्स ग्रुप में आपका स्वागत है। स्टैक एक्सचेंज साइटों पर प्रश्नों और उत्तरों के लिए कृपया इन उपयोगी दिशानिर्देशों की जाँच करें: प्रोग्रामर.स्टैकएक्सचेंज.
DeveloperDon

1

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

यदि आप इसकी गुणवत्ता के उद्देश्य उपायों पर ध्यान केंद्रित करते हैं, तो मेरे विचार में, दूसरों को आपके कोड के बारे में सोचने की कोई आवश्यकता नहीं है। क्या यह

  • सही बात?
  • समझा जा सकता?
  • अनुरक्षणीय?
  • कुशल?

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

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

ख़ुद के प्रति ईमानदार रहो!! सीखना जारी रखें और जो आप करते हैं उसका आनंद लें।


धन्यवाद आपका पहला पोस्ट किया गया जवाब देने के लिए और स्टैक एक्सचेंज पर प्रोग्रामर्स ग्रुप में आपका स्वागत है। आपकी विचारधारा का मेरे मन में बहुत सम्मान है। "जो लोग कहते हैं कि आप नहीं कर सकते, आप कोशिश करते हैं और पाते हैं कि आप कर सकते हैं।" हेनरी डेविड थोरयू। स्टैक एक्सचेंज साइटों पर सवाल और जवाब के लिए इन उपयोगी दिशानिर्देशों की जांच करें: प्रोग्रामर.स्टैकएक्सचेंज.
DeveloperDon

1

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

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

यहां तक ​​कि मेरे कॉलेज ने मुझे ये चीजें सिखाने में असफल रहे, भले ही उन्होंने कोशिश की।

यूनिट परीक्षण के लिए टेस्ट ड्रिवेन डेवलपमेंट के लिए देखें।

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

ऑब्जेक्ट ओरिएंटेड भाषाओं के लिए। इसे कम से कम समझें। यह एक उपकरण है जिसका उपयोग आप समस्याओं को अधिक पठनीय तरीके से हल करने के लिए कर सकते हैं।

गुड लक: डी


0

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

हालाँकि, मुझे लगता है कि आप एक बहुत ही सरल और भ्रामक चित्र बना रहे हैं। सभी "व्यावसायिक रूप से पढ़ाए जाने वाले" प्रोग्रामर से वास्तव में कोई भी अच्छा है। सिर्फ इसलिए कि वे कुछ करते हैं जरूरी नहीं कि यह सही बात हो।

और बहुत (लेकिन सभी नहीं) जो आप कह रहे हैं वह वास्तव में ऐसा लगता है कि आप एक हैं जो उन्हें एक चाल या दो सिखा सकते हैं ।

मैं OO से अधिक कार्यात्मक पक्ष की ओर झुकता हूं, लेकिन मुझे OO का उपयोग दिखाई देता है जब कुछ अमूर्त इकाई के रूप में अधिक समझ में आता है।

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

आगे मैं भी कुछ करते समय सरल मार्ग पर जाता हूं। जब इसके विपरीत, ऐसा लगता है कि कभी-कभी पेशेवर प्रोग्रामर से जो कोड मैं देखता हूं, वह इसके लिए जटिल है!

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

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

और अंत में, मैं सर्वश्रेष्ठ टिप्पणीकार नहीं हूं।

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

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

खैर, उनसे पूछिए। :) अपने कोड का परीक्षण आवश्यक है, और इकाई परीक्षण इसके लिए एक लोकप्रिय और उपयोगी उपकरण हैं।

बहुत सारे और अंडरस्कोर "_", जो वास्तव में मेरे स्वाद नहीं हैं।

टिप्पणी के साथ, यह व्यक्तिपरक है, और भाषा पर निर्भर करता है। सी और सी ++ में, lowercase_with_underscoresएक काफी सामान्य नामकरण सम्मेलन है। कई अन्य भाषाओं में, आप वस्तुतः एक अंडरस्कोर नहीं देखेंगे। लेकिन दिन के अंत में, यह वास्तव में महत्वपूर्ण नहीं है। किसी फ़ंक्शन को कॉल किया जाता है write_to_logया WriteToLogवास्तव में कोई फर्क नहीं पड़ता है। किसी को बस इसे चूसना है और टीम ने वहां पर सहमति व्यक्त की है।

MVC के बारे में कुछ भी नहीं जानते, मैंने इसके बारे में बहुत कुछ सुना है, हालांकि बैकबोन.जे जैसी चीजों के साथ। मुझे लगता है कि यह एक आवेदन को व्यवस्थित करने का एक तरीका है। यह सिर्फ मुझे भ्रमित करता है, क्योंकि अब तक मैंने अपनी खुद की संगठनात्मक संरचना बना ली है।

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

पूर्ण OO प्रोग्रामिंग वास्तव में मेरे मुंह में एक बुरा स्वाद छोड़ती है

यहाँ भी, और मैं वही हूँ जिसे आप "व्यावसायिक रूप से प्रशिक्षित" (एक सीएस डिग्री) कहेंगे। जिन लोगों को प्रोग्रामिंग सिखाई गई है, वे केवल उन लोगों से भिन्न हैं, जो स्व-सिखाया जाता है। ऐसा लगता है कि आप कुछ ऐसे लोगों के साथ काम कर रहे हैं जिन्हें वास्तव में कुछ नई तरकीबें सीखने की जरूरत है।

वास्तव में मैं इस तथ्य से डर गया हूं कि लोग अंततः मेरे कोड की जांच करेंगे। क्या यह सिर्फ सामान्य है जो किसी भी प्रोग्रामर के माध्यम से होता है या मुझे वास्तव में अपनी तकनीकों को बदलना चाहिए?

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


0

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

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

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

आधुनिक प्रोग्रामिंग भाषाएं अक्सर घोषणात्मक प्रोग्रामिंग मॉडल का समर्थन करती हैं। उदाहरण के लिए, C # में, Linq का उपयोग एक घोषणात्मक शैली में परिणाम देता है, क्योंकि आप यह नहीं कह रहे हैं कि आप जो चाहते हैं उसे कैसे प्राप्त करें; आप केवल वही कह रहे हैं जो आप चाहते हैं।

पूर्ण OO प्रोग्रामिंग वास्तव में मेरे मुंह में एक बुरा स्वाद छोड़ती है, फिर भी ऐसा लगता है कि हर कोई और सख्ती से उपयोग कर रहा है।

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

पूर्ण OO से आपका क्या अभिप्राय है? मैंने कभी भी "शुद्ध" OO कोड पर काम नहीं किया है। शायद आप हमें कुछ नापसंद कर सकते हैं कि आप क्या पसंद करते हैं। एक ओपन सोर्स प्रोजेक्ट का चित्रण मदद कर सकता है।

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


क्यों होता है पतन?
डेव हिलियर सेप

0

संक्षिप्त उत्तर: हाँ।

खुद को सिखाना लगभग सभी अच्छा है।
अच्छी समझ, अच्छी सलाह के साथ फ़िल्टर करें।

WRT सीखने पेशेवर प्रोग्रामिंग, हाँ।
आपके दिमाग में क्या है?
सम्मेलन, सेमिनार, प्रमाणीकरण, एक डिग्री?
प्रत्येक की लागत / लाभ है।
जब आरओआई अच्छा है, यदि आपके पास संसाधन हैं, तो इसके लिए जाएं।

स्रोत पर विचार करके डिग्री पर सलाह: उनके साथ / बिना लोगों के निहित स्वार्थ हैं।
प्रत्येक के आधा दर्जन से बात करें।

क्या शिक्षा उद्योग से अलग है? अक्सर।
क्या कोई डिग्री बेकार है? डॉलर-वार, बहस करना मुश्किल।
ग्रेड लगभग हमेशा अधिक पैसा बनाते हैं, लेकिन कॉलेज के ऋण के लिए बाहर देखते हैं।

ज्ञान के लिहाज से? शायद।
यदि आप स्कूल से नफरत करते हैं, तो आप जितना डालते हैं, उससे अधिक बाहर नहीं निकलेंगे।

यदि आपको लगता है कि डिग्री आपके लिए एक योग्य लक्ष्य है, तो यह संभवतः है।

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

लागत बहुत डरावनी हो सकती है, लेकिन वे केवल कहानी का एक हिस्सा बताते हैं क्योंकि योग्यता, आवश्यकता और एक सौ अन्य कारणों के लिए कई अनुदान और छात्रवृत्ति हैं।

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


0

दूसरा प्रश्न - क्या मैं अपनी शैली का उपयोग कर सकता हूँ?

आपके दो सवाल हैं।

पहला आपके शीर्षक में है। कृपया मेरा पूर्व उत्तर देखें।

दूसरा लगभग पाँच पैराग्राफों में विस्तृत है जहाँ आप वर्णन करते हैं कि नीचे दी गई बातों के साथ आपकी शैली पेशेवर शैली से कैसे भिन्न है:

  • 100% स्वयं पढ़ाया।
  • तकनीक और संगठन में अलग।
  • कार्यात्मक और वस्तु उन्मुख का मिश्रण।
  • कम जटिल।
  • बंद के बहुत सारे।
  • कुछ टिप्पणियाँ।
  • कोई इकाई परीक्षण नहीं।
  • कुछ अंडरस्कोर।
  • कोई एमवीसी नहीं।
  • कोई बैकबोन नहीं। js।
  • कोई टेम्पलेट अनुप्रयोग नहीं।

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

http://en.wikipedia.org/wiki/Coding_conventions

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

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

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

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

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

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


0

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

मैंने अपने करियर में उपयोगी एजाइल मेनिफेस्टो के आदर्शों को पाया है (www.agilemanifesto.org)

  • व्यक्तियों और प्रक्रियाओं और उपकरणों पर बातचीत
  • व्यापक प्रलेखन पर काम कर रहे सॉफ्टवेयर
  • अनुबंध बातचीत पर ग्राहक सहयोग
  • एक योजना के बाद बदलने का जवाब

0

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

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

निश्चित रूप से मैंने अपनी अकादमिक पृष्ठभूमि में वाक्य रचना और अवधारणाओं को सीखा, लेकिन यह व्यावसायिक दुनिया में है जहां मैंने कार्यक्रम सीखना शुरू किया।


वास्तविक दुनिया के अनुभव के लिए कोई विकल्प नहीं है, चाहे कितना अच्छा शिक्षण हो
एंड्रयू
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.