जैसा कि आप अनुभव प्राप्त करते हैं, क्या सामान्य रूप से प्रोग्रामिंग पढ़ना, लिखना और समझना आसान हो जाता है? [बन्द है]


80

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

आजकल, मैंने कार्यात्मक सॉफ्टवेयर लिखा है और मैंने 3 भाषाओं के मूल तत्व सीखे हैं और मैं सिर्फ एक भाषा में मध्यवर्ती हूं। जब मैं MYSQL, या OpenGL प्रोग्रामिंग, या यहां तक ​​कि दृश्य स्टूडियो C ++ कोड जैसी उन्नत चीजों को देखता हूं, तो यह मुझे सिरदर्द देता है, और यहां तक ​​कि जब कई वेबसाइटों के HTML स्रोत कोड की कल्पना करते हैं (Google क्रोम द्वारा देखे गए वेबसाइटों पर सबसे स्रोत कोड बहुत गड़बड़ और असंगठित लगते हैं ) यह मुझे अपने मस्तिष्क की बहुत सीमा तक भ्रमित करता है। यह सब पहली बार में सरल लगता है, फिर भी जब इन उन्नत चीजों को देखते हुए यह मुझे आश्चर्य होता है कि कोई कैसे इतना कुछ सीख सकता है।

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


24
मेरा सुझाव है कि आप इसे पढ़ें: norvig.com/21-days.html
जेम्स पी।

जैसे कुछ और, हाँ। जब तक तकनीक आप पर नहीं बदलती। :-)
मैथअटैक

3
जब तक आपका "अनुभव" एक ही चीज़ को बार-बार नहीं पढ़ रहा है। अपने आप को नए सामान के साथ खींचो।
जेफ

जटिल HTML पृष्ठों के विश्लेषण के लिए एक छोटी सी टिप, आप फ़ायरफ़ॉक्स के फ़ायरबग या क्रोम के इंसपेक्ट एलिमेंट का उपयोग करना चाहेंगे।
रेयान

6
"जब मैं एक शुरुआत करता था तो मुझे लगता था कि मैं प्रोग्रामिंग के बारे में सब कुछ जानता था।" वहाँ गया और जितना मैं सीखता हूँ, उतना ही मुझे एहसास होता है कि मैं कितना कम जानता हूँ।
लेवेन केर्सेमेकर्स

जवाबों:


134

संक्षिप्त उत्तर: नहीं।

लंबा जवाब:

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

  • आप केवल कोड लिखना नहीं चाहते हैं। आप सुंदर कोड लिखना चाहते हैं ।

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

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

  • आप अपने आप को पुस्तकालयों के एक छोटे समूह के लिए सीमित नहीं करते हैं जो आप जानते हैं। यदि आप C # में कोड करते हैं, तो आप .NET फ्रेमवर्क के कई पुस्तकालयों की पूरी शक्ति को जानना और उपयोग करना चाहते हैं ।

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

  • आप अपने आप को उन औजारों के एक मूल समूह तक सीमित नहीं करना चाहते , जो भाषा आपको देती है । C # में, आप जेनरिक, कोड कॉन्ट्रैक्ट, रिफ्लेक्शन, ईवेंट-चालित विकास, LINQ के साथ कार्यात्मक पहलू, प्रतिक्रियात्मक एक्सटेंशन, और आपके द्वारा सीखे गए अन्य सामान का एक टन, सभी का उपयोग करना चाहते हैं, यदि वे सभी चीजें आपको बेहतर लिखने में मदद करती हैं। कोड।

  • आप कोड लिखना शुरू नहीं करते हैं । आप अपने समय की आवश्यकताओं को पूरा करने में 80 से 90% खर्च करते हैं , अपने आवेदन की वास्तुकला का निर्माण करते हैं, इकाई परीक्षण लिखते हैं, दस्तावेज लिखते हैं, आदि, और आपके समय का केवल 10 से 20% वास्तविक कोड लिखते हैं

  • आपको सुरक्षा की परवाह है । आप उन कानूनी मुद्दों को जानते हैं जो आपके अनुप्रयोगों द्वारा हेरफेर किए गए डेटा के साथ उत्पन्न हो सकते हैं। आपको पता है कि ITIL क्या है । आप कुछ आईएसओ मानकों को जानते हैं और आप उन्हें अपने काम में दैनिक रूप से लागू करते हैं।

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

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

संक्षेप में:

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

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

  3. ... और आप खुद सोच रहे हैं "मैं संभवतः ऐसा कैसे कर सकता हूं?" ठीक उसी तरह जब आपने दस साल पहले किया था जब आपको लूप वाली स्क्रीन पर नंबर दिखाना था।

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

एक डोमेन में पूर्णता प्राप्त करना सॉफ़्टवेयर विकास जितना विशाल है असंभव है, चाहे आप कितने भी स्मार्ट हों।


36
पानी पर चलना और एक विनिर्देशन से सॉफ़्टवेयर विकसित करना आसान है अगर दोनों जमे हुए हैं (यह दिखाता है कि "आप कोड लिखना शुरू नहीं करते हैं। आप महीनों की आवश्यकताओं को पूरा करते हैं" थोड़ा अवास्तविक है)
jfs

9
"कार्यात्मक प्रोग्रामिंग एक बेहतर विकल्प है " बहस का विषय है।
jfs

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

7
मैं यह भी ध्यान देता हूं कि बिना किसी विकास के "महीनों की आवश्यकताएं" केवल मूल रूप से एक आदर्श झरना मॉडल होने जा रहा है। यदि आप पुनरावृत्ति नहीं कर रहे हैं तो आप खुद को और परियोजना को मार रहे हैं।
बेन ब्रोका

8
"यह कभी आसान नहीं होता है, आप बस तेजी से आगे बढ़ें।" / ग्रेग लेमंड /
डेग्रीविस

20

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

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

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


18

यहाँ पहले से ही कुछ अच्छे उत्तर हैं, लेकिन मुझे लगा कि मैं कुछ और छोटे बिंदु जोड़ सकता हूँ:

जब मैं एक शुरुआत करता था तो मुझे लगता था कि मैं प्रोग्रामिंग के बारे में सब कुछ जानता था, लेकिन जैसा कि मैंने और अधिक सीखा मुझे एहसास हुआ कि यह क्षेत्र कितना मुश्किल है

इसे Dunning-Kruger प्रभाव कहा जाता है । यह शुरुआती प्रोग्रामर और वास्तव में, कई क्षेत्रों के शुरुआती लोगों के बीच बेहद आम है।

वेबसाइटों पर अधिकांश स्रोत कोड, जो Google chrome द्वारा देखे जाते हैं, बहुत गड़बड़ और असंगठित लगते हैं

क्या उन वेब साइटों को लिखने वाले लोग चाहते थे कि आप उन्हें समझ सकें? शायद ऩही। यह उनके हित में है कि कोड को समझना मुश्किल है।

यह सिर्फ मुझे आश्चर्यचकित करता है कि कोई इतना कैसे सीख सकता है।

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

संक्षेप में, यह प्रश्न है कि क्या ये बातें किसी प्रोग्रामर के लिए स्पष्ट हो जाती हैं क्योंकि वह अपने करियर में आगे बढ़ता है।

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

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

जैसे कि ऊपर सूचीबद्ध विषय जटिल होते हैं (OpenGL, MySQL, उन्नत html साइटें) पढ़ना, लिखना और समझना आसान हो जाता है जैसा कि आप और अधिक सीखते हैं, या क्या यह आपके द्वारा जाने के रूप में अधिक जटिल है?

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

आप इस भावना का मुकाबला कैसे कर सकते हैं कि आप प्रोग्रामिंग की दुनिया में एक चींटी हैं और यह सामान आपको स्क्वैश करने के बारे में है?

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


2
इस उत्तर के लिए बहुत बहुत धन्यवाद, यह बाकी लोगों के ऊपर है क्योंकि यह सिर्फ मेरे मुख्य प्रश्न का उत्तर नहीं देता है, बल्कि कुछ चीजों पर मेरी आंखें भी खोलता है। +1
बगस्टर

@ ईरिक: आप इस तरह के विषयों में किसी व्यक्ति से क्या कहेंगे, जहां वह कहता है कि "विशेषज्ञता कीड़ों के लिए है, इंसानों के लिए नहीं"?
जोन वैज

@JoanVenge क्या कोई ऐसा कहेगा? आमतौर पर लोग सभी विशिष्ट और विशिष्ट होने के बारे में होते हैं, और बहुत कुछ ऐसा यदि वे जानवरों (या कीड़े) से खुद को अलग करने की आवश्यकता महसूस करते हैं।
मैथ्यू पढ़ें

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

+1 के लिए एक हिस्सा चुनें जो आपको पसंद है जहां आप वास्तविक मूल्य जोड़ सकते हैं और इसमें विशेषज्ञ बन सकते हैं।
अक्षय खोट

14

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

समय और जोखिम को देखते हुए इन चीजों को समझना आसान हो जाता है।

याद रखें जब आप अपने ब्राउज़र में देव टूल्स से साइटों को देख रहे होते हैं तो वे अक्सर एक फ्रेमवर्क द्वारा उत्पन्न होते हैं। आज्ञा दें कि कोई भी चीज़ हो ... ASP.NET, JSP, RoR, Django, ... कौन जानता है। इनमें से कुछ ढांचे दूसरों की तुलना में क्लीनर कोड का उत्पादन करते हैं।

समापन में ... जोखिम प्रवीणता की ओर जाता है। उस भावना को बुझाने का कोई उपाय नहीं है। बस अनुभव और सीख। डोमेन ज्ञान प्राप्त करने और अपने पर्यावरण के उपयोग के कौशल को सीखने में समय लगता है।


1
जब तक कोड लिखने वाला व्यक्ति अच्छी प्रथाओं और विशेष रूप से प्रोग्रामर दोनों की सामान्य मुहावरों का उपयोग कर रहा था, तब तक कुछ सच्चाई है। ख़राब कोडिंग और / या जानबूझकर किया गया ओफ़्यूसकेशन आपको क्रॉल में वापस ला सकता है। CodeGolf.SE द्वारा छोड़ने की कोशिश करें । यहां तक ​​कि "क्लियर" संस्करणों में कठिन स्लोगन हो सकते हैं क्योंकि प्रतियोगिता के मेट्रिक में बदलाव के लिए अच्छे अभ्यासों का त्याग किया गया है।
dmckee

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

2

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

एक उदाहरण जो आपने दिया था वह HTML कोड के एक समूह को देख रहा था, हालाँकि:

आप HTML कोड क्यों देख रहे हैं? शायद नहीं क्योंकि आप पूरी साइट का HTML सीखना चाहते हैं। वहाँ शायद एक विशिष्ट चाल है जिसे आप लेने की उम्मीद कर रहे हैं। उस स्थिति में, बस प्रासंगिक HTML को फायरबग जैसे टूल के साथ खोजें।

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

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


2

संक्षिप्त उत्तर हां है लेकिन यह बहुत कुछ इस बात पर निर्भर करता है कि आप अनुभव को कैसे परिभाषित करते हैं।

मुझे लगता है कि विकास के लिए कम से कम 3 भाग हैं। जैसे-जैसे आप प्रत्येक सेगमेंट में बेहतर होते जाते हैं, कुछ चीजें स्पष्ट होती जाती हैं।

  1. बिजनेस आवश्यकताओं को समझना । यह आपको आवेदन के बारे में बेहतर जानकारी देता है। बेहतर आप समझ सकते हैं कि व्यवसाय के नियम क्यों हैं, वे क्या हैं, आप जल्दी उठाते हैं कि क्यों कुछ चीजों को एक निश्चित तरीके से किया जाता है। उदा। आपके ग्राहकों को सरकारी विनियमन एक्स के अनुपालन की आवश्यकता है, यही कारण है कि उन्हें दस्तावेज़ वाई तैयार करने की आवश्यकता है, यही कारण है कि उन्हें संग्रहित बेकार प्रतीत होता है।

  2. तकनीकी आवश्यकताओं को समझना । यह तकनीकी स्तर पर क्यों है, यह समझने के बारे में अधिक जानने के अलावा # 1 जैसा है। कुछ उपकरणों और प्रौद्योगिकियों के अपने स्वयं के quirks हैं, जब तक कि आपने उनसे निपटने से पहले यह समझना मुश्किल है कि चीजों को एक निश्चित तरीके से क्यों किया जाता है। यह अधिक स्पष्ट है जब आप विरासत प्रणालियों से निपटते हैं। उदा। अनुप्रयोग एक विशेष सेवा बस का उपयोग करता है जो केवल XML लेता है।

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

विकास के कई पहलुओं में शामिल होने की कोशिश करें क्योंकि यह वास्तव में आसान नहीं होता है जब तक कि आपने कम से कम कुछ समय में सभी क्षेत्रों को नहीं किया हो ।

याद रखें कि किसी और के कोड में पूर्णता (और उद्देश्य) हमेशा # 1 और # 2 के सापेक्ष होता है। ये प्राथमिक ड्राइवर हैं कि कोड राज्य में क्यों है। उन दो क्षेत्रों में बार-बार बदलाव सबसे बड़ा कारण है कि हमें हर समय स्पेगेटी कोड मिलता है। इसलिए जब तक आप व्यवसाय और तकनीकी आवश्यकताओं को पढ़ने में माहिर हैं, कोड पढ़ने का कार्य हमेशा एक शाही PITA होगा।


2

यह एक ही समय में आसान और अधिक जटिल हो जाता है!

दूसरों को जानना ज्ञान है;
स्वयं को जानना आत्मज्ञान है।
दूसरों को माहिर करने के लिए बल की आवश्यकता होती है;
स्वयं को माहिर करने के लिए ताकत की आवश्यकता होती है;
वह जानता है कि उसके पास पर्याप्त धन है।
दृढ़ता इच्छा शक्ति का प्रतीक है।
वह जो जहां रहता है, वहीं टिकता है।
मरना नहीं बल्कि नाश होना अनंत काल तक मौजूद रहना है।

सॉफ्टवेयर डेवलपमेंट का अनुवाद

बहुत सारी तकनीकों को जानना ज्ञान है। (सब कुछ ALGOL से उतरता है)
यह जानना कि आप जो नहीं जानते हैं वह आत्मज्ञान है। (LISP)
बहुत सारी भाषाओं, चौखटों और प्लेटफार्मों को बनाने के लिए बहुत सारे प्रयासों की आवश्यकता होती है। (जावा)
केवल वह चीज जो आपको जानना आवश्यक है और केवल उसके लिए ताकत की आवश्यकता है। (और Google या stackoverflow.com)
कोडिंग को रोकने के लिए और कुछ देने के बारे में जानना जब आप पर्याप्त रूप से अच्छा जानते हैं। (कोई विश्लेषण पक्षाघात या सोना चढ़ाना)
आप जो हासिल करने की कोशिश कर रहे हैं उस पर काम करते रहें, इसके लिए फोकस और इच्छा शक्ति की आवश्यकता होती है। (सब कुछ लगातार बदलता रहता है, आप कभी खत्म नहीं होते)
एक या दो तकनीकों के साथ रहें और आप सहन करेंगे। (कॉबोल अभी भी अच्छी तरह से भुगतान करता है, जैसा कि सी)
प्रोग्रामिंग छोड़ने और प्रबंधन में जाने के लिए सदा उपस्थित रहना है। (या FOSS सॉफ़्टवेयर की एक विरासत छोड़ दें जिसे हर कोई आपके मरने के बाद अच्छी तरह से उपयोग करना जारी रखेगा)।


तो एक चींटी होने के बजाय आपको एक कॉकरोच होना चाहिए और बस उठना चाहिए जब यह आपको तोड़ता है, क्या मैं सही हूं? :-P
बुगस्टर

"विश्लेषण पक्षाघात"! = "पता है कि कोडिंग कब बंद करनी है"। यह अधिक "पता है कि कोडिंग कब शुरू करना है"।
बेन वोइगट

0

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

मैं अन्य उत्तरदाताओं की तुलना में थोड़ा अलग सौदा लेने जा रहा हूं; मेरा मानना ​​है कि कोड पढ़ना और लिखना वास्तव में आसान होता है क्योंकि आप इसे अधिक करते हैं, और मैं इसे एक सरल सादृश्य के साथ प्रदर्शित करता हूँ।

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

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


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

उदाहरण के लिए, आपके द्वारा उल्लिखित सभी तीन भाषाओं (MYSQL, OpenGL, C ++) में कुछ सामान्य विशेषताएं हैं:

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

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

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


0

संक्षिप्त उत्तर: हां , सामान्य तौर पर

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

जैसे-जैसे आप समय के साथ आगे बढ़ते हैं, आप अनुभव प्राप्त करते हैं।

जैसे-जैसे आप समय के साथ आगे बढ़ते हैं, अन्य भाषाएं / पैटर्न आदि आपके विकास के समानांतर विकसित हो रहे हैं।

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

एक अच्छा सवाल यह भी हो सकता है कि क्या आप अपने आप को बहुत पतली या एक निश्चित भाषा में मोटा करने के लिए फैला रहे हैं।


0

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

इन सभी विविधताओं में जटिलता के दो आयाम हैं।

  1. उनकी शब्दावली और वाक्य रचना अलग है।
  2. अमूर्त (उच्च स्तर की अवधारणाएं) वे समर्थन करती हैं, अलग-अलग होती हैं।

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

फिर CSS, HTML, जावास्क्रिप्ट जैसे "आसान सामान" पर स्विच करें और शायद बूटस्ट्रैप और रिएक्ट जैसे फ्रेमवर्क भी, और आपका मस्तिष्क भून जाएगा - जैसा कि अल्बर्ट आइंस्टीन का है। लोगों को लगता है कि "मैं फ्रेंच जानता हूं, इसलिए जर्मन सीखना आसान होना चाहिए"। नहीं!

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

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

सारांश में, कंप्यूटर विज्ञान के सिद्धांत / सार, सॉफ्टवेयर पैटर्न और आपके द्वारा मिलने वाली व्यावसायिक समस्याओं के प्रकार, ये सभी धीरे-धीरे बदलते हैं। आप एक बार सीख सकते हैं और नया ज्ञान संचय कर सकते हैं। इसके विपरीत, कंप्यूटर भाषा, रूपरेखा, जिसे "पारिस्थितिक तंत्र" कहा जाता है और घटक पुस्तकालय बहुत जल्दी बदल जाते हैं क्योंकि सभी उपकरण उन्हें घेर लेते हैं। यहाँ सीखने की गति धीमी और समय लेने वाली होने की उम्मीद है!


-1

जैसे कि ऊपर सूचीबद्ध विषय जटिल होते हैं (OpenGL, MySQL, उन्नत html साइटें) पढ़ना, लिखना और समझना आसान हो जाता है जैसा कि आप और अधिक सीखते हैं, या क्या यह आपके द्वारा जाने के रूप में अधिक जटिल है? आप इस भावना का मुकाबला कैसे कर सकते हैं कि आप प्रोग्रामिंग की दुनिया में एक चींटी हैं और यह सामान आपको स्क्वैश करने के बारे में है?

जब कोई प्रगति होती है, तो हम अनजान और सीखते हैं कि हमने क्या सोचा था कि हम पहले जानते थे। - हेनरी डेविड थोरयू

ज़ेन मास्टर और ओवरफ्लोइंग टीचकी की कहानी है ।

कभी-कभी, हमें अतीत से अपनी पूर्वनिर्धारित धारणाओं और विचारों को छोड़ देना चाहिए ताकि हम खुद को नई अवधारणाओं को सीखने की अनुमति दे सकें।

याद रखें: यदि आप एक नई अवधारणा से अभिभूत महसूस कर रहे हैं, तो आपको कई शिक्षकों की तलाश करने की आवश्यकता है।

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

आपके रवैये से सारा फर्क पड़ता है।

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