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

50

बहुत सारे छात्र जब वे स्नातक होते हैं और अपनी पहली नौकरी प्राप्त करते हैं, तो उन्हें लगता है कि वे वास्तव में प्रोग्राम करना नहीं जानते हैं, भले ही वे कॉलेज में अच्छे प्रोग्रामर रहे हों।

'वास्तविक दुनिया' में एक शैक्षणिक सेटिंग और प्रोग्रामिंग में प्रोग्रामिंग के बीच कुछ अंतर क्या हैं?

programming-practices junior-programmer

— rdasxy
स्रोत

उदाहरण: techcrunch.com/2011/11/12/…

— rdasxy

4

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

— जियोर्जियो

9

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

— बॉब

@Bob। यह सामान्य शिक्षा के बारे में अधिक था। कक्षा / अनुसंधान / निर्देशित रीडिंग / असाइनमेंट बनाम उद्योग में "वास्तविक दुनिया" प्रोग्रामिंग।

— rdasxy

ठीक। यह बहुत स्पष्ट नहीं था, क्योंकि "अकादमिक प्रोग्रामिंग" के रूप में ऐसी चीज है जो लोगों द्वारा कहना चाहते हैं, जो जीवविज्ञानी सिमुलेशन का पता लगाने में मदद करते हैं।

— बॉब

72

एक पारंपरिक स्नातक कंप्यूटर विज्ञान कार्यक्रम में आप सिर्फ प्रोग्रामिंग सीखते हैं । लेकिन असली दुनिया ऐसे लोगों को नहीं चाहती जो सिर्फ प्रोग्रामर हैं। असली दुनिया असली सॉफ्टवेयर इंजीनियर चाहती है। मुझे पता है कि कई नौकरी विवरण इस अंतर को व्यक्त नहीं करते हैं, जो केवल मामले को भ्रमित करता है। वास्तविक दुनिया में आपको सक्षम होना चाहिए:

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

अरे हाँ, और आपको भी कोड लिखने में सक्षम होना होगा, हालांकि, यह एक सॉफ्टवेयर इंजीनियर के समय का औसतन केवल 40 - 60% है।

तो, यह नहीं है कि हौसले से खनन किए गए कंप्यूटर विज्ञान को नहीं पता है कि प्रोग्राम कैसे किया जाता है (कई वास्तव में, बहुत अच्छे प्रोग्रामर हैं)। यह है कि उनमें से कई नहीं जानते कि कुछ और कैसे करें।

— माइकल
स्रोत

18

Oh yeah, and you also have to be able to write code too, but that's, on average, only 40 - 60% of a software engineer's time.

- या यहां तक कि वास्तव में खराब और वास्तव में बड़ी कॉर्पोरेट दुकानों पर 0-20%।

— रिच मेल्टन

1

Ritch के लिए +1 बहुत अच्छे उत्तर के लिए और +1 (अधिक होना चाहिए)। यदि कोडिंग पर प्रोजेक्ट लाइफ-साइकल का 20% से अधिक / w इंजीनियर खर्च कर रहा है तो कुछ बहुत, बहुत गलत है। 50% डिजाइन, 30% परीक्षण, बाकी के लिए% 20 .... कोडिंग सहित सब कुछ सही के बारे में लगता है। उचित डिजाइन के साथ, कोडिंग तुच्छ होना चाहिए। इसके बिना, जिसे लोग "कोडिंग" कहते हैं, वह वास्तव में अंतहीन रीराइट है, किसी प्रकार के डिजाइन को एक साथ हैक करने की कोशिश कर रहा है जैसा कि वे </ rant>

— Mawg

36

विश्वविद्यालय में...

आपका शिक्षक आपको देता है:

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

वास्तविक दुनिया में"...

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

निष्कर्ष

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

— back2dos
स्रोत

11

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

— बॉब

20

वे समस्या के एक अलग पहलू का सामना करते हैं:

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

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

— एमिलियो गरवाग्लिया
स्रोत

10

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

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

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

इन चीजों को सिखाया नहीं जाता है, और वे उत्पादकता में भारी अंतर करते हैं।

— माइक डनलवे
स्रोत

1

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

— जियोर्जियो

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

— माइक डनलवे

1

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

— जियोर्जियो

@ जियोर्जियो: मैं 30 साल पहले एक प्रोफेसर था, इसलिए मुझे अभी भी याद है कि इसे कैसे करना है। मैंने इन विचारों को बेची गई एक किताब में भी डाल दिया , जिसका मतलब है कि मेरे पास यह सोचने और समझाने का समय है कि यह सब एक साथ कैसे फिट बैठता है।

— माइक डनलैवी

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

— जियोर्जियो

8

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

— thiton
स्रोत

8

अद्यतन: जैसे कि कोई मेरे दिमाग को पढ़ रहा था: स्नातक की उम्मीदें बनाम वास्तविकता ...

मेरे दो अन्य कारक:

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

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

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

— दिमित्रियो मिस्ट्रिटिस
स्रोत

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

— होल्सक्राफ्ट

2

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

— रोमन स्टार्कोव

4

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

उदाहरण के लिए, मेरे कार्यालय में हमारे पास एक इंजीनियर है जो सॉफ्टवेयर ले जाएगा और कोने की स्थितियों से क्रैश होने में मास्टर है। वह एक बटन पर जितनी जल्दी हो सके उतनी तेजी से क्लिक करेगा जब तक कि कुछ दुर्घटनाग्रस्त नहीं हो जाता ... यदि कोई ऑपरेशन बहुत लंबा होता है, तो वह स्क्रीन के चारों ओर बेतरतीब ढंग से क्लिक करना शुरू कर देगा (हताशा से बाहर? आईडीके ....)?

हमारे प्रोग्रामिंग दर्शन को बदलना ताकि हम "स्टीव प्रूफ" चीजों को सामान्य रूप से अपने आवेदन की स्थिरता में सुधार कर सकें।

— दवे नाइ
स्रोत

3

मुझे स्कूल में प्रोग्रामिंग प्रशिक्षण के साथ शून्य व्यक्तिगत अनुभव है - मैं एक अंग्रेजी प्रमुख था। मुझे केट्स और बायरन के बारे में पूछें! - लेकिन मैंने कई नई कब्रें प्राप्त की हैं और उन्हें लाया और पेशेवर सॉफ्टवेयर विकास की दुनिया में उनका उल्लेख किया है। इसलिए मैं उस दृष्टिकोण से बोल सकता हूं।

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

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

— दान रे
स्रोत

2

अकादमी में,

कमियां

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

प्लस

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

उद्योग में,

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

इसकी जांच करें:

http://www.dodgycoder.net/2011/10/how-to-become-better-programmer.html

— SHOUBHIK बॉस
स्रोत

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

— ब्रूस एडिगर

2

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

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

— BillThor
स्रोत

1

वास्तव में,

शैक्षणिक स्तर की प्रोग्रामिंग और वास्तविक विश्व प्रोग्रामिंग के बीच पूरी तरह से अंतर करना असंभव है।

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

आप किस क्षेत्र में काम कर रहे हैं, इसके आधार पर आपको इसके कानूनों का अनुपालन करना होगा।

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

सामान्य तौर पर आप एक उद्योग में प्रति विषय कम से कम कुछ चुनौतियों का सामना करेंगे:

शासी कानून (चिकित्सा के लिए ग्राहक की गोपनीयता)
विषय पता है कि कैसे (पूर्व चालान-कर प्रणाली, सूची, संसाधन प्रबंधन, चिकित्सा योजनाएं, उद्योग मानक)
ग्राहकों की आवश्यकताएं जो उद्योग मानकों / शासी कानूनों से अलग या गैर-मौजूद हैं या अलग हैं

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

वास्तविक वास्तविक अंतर केवल इतना है कि वास्तविक विश्व परियोजना है

एक ग्राहक है
बजट (समय, पैसा, लोग संसाधन)

यह अलग गेंद का खेल है जब कोई और नियम बनाता है :)

— Schalk
स्रोत

0

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

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

Microsoft वेब प्रोग्रामिंग आवश्यकताओं को लें (जो कि किसी संगठन में उत्पादक टीम के सदस्य होने के लिए आवश्यक क्षेत्र हैं):

1- C # .NET या VB.NET

2- ASP.NET

3- HTML और CSS

4- SQL सर्वर (या अन्य डेटाबेस)

5- ओओ एप्लीकेशन प्रोग्रामिंग और डिजाइन

6- जावा स्क्रिप्ट

7- एमवीसी ढांचा

8- स्रोत नियंत्रण उपकरणों के लिए कुछ जोखिम

9- स्वचालित परीक्षण उपकरणों के लिए कुछ जोखिम

10-बग ट्रैकिंग उपकरण

11-ई-कॉमर्स अवधारणाओं (वैकल्पिक)

12-ORM

13-कुछ व्यावसायिक विश्लेषण कौशल

14-कुछ संचार कौशल

15-शायद, कुछ क्लाउड कंप्यूटिंग फंडामेंटल

जैसा कि आप देख सकते हैं कि कॉलेज / विश्वविद्यालय के दौरान उपरोक्त आवश्यकताओं में से अधिकांश पर शायद ही कभी ध्यान केंद्रित किया जाता है (आप कुछ में 1 कोर्स प्राप्त कर सकते हैं)।

कोई भी पूरी तरह से संस्थानों को दोष नहीं दे सकता है क्योंकि प्रौद्योगिकी के कई ऐसे ढेर हैं और वे बदलते रहते हैं।

Microsoft से ऊपर के अधिकांश लोग जावा में एप्लिकेशन विकसित करने के इच्छुक किसी व्यक्ति की मदद नहीं करेंगे।

असली समस्या यह है कि आज जिस तकनीक के ढेरों की जरूरत नहीं है, उसमें से कोई भी व्यवसाय पूरी तरह से कवर नहीं किया गया है।

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

— कोई मौका नहीं
स्रोत

12

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

— जियोर्जियो

2

@Giorgio, आपकी टिप्पणी के लिए धन्यवाद, आपकी बात मान्य है। मैंने स्पष्ट रूप से कहा है कि "एक पूरी तरह से संस्थानों को दोष नहीं दे सकता है"। हालांकि मूल प्रश्न अकादमिक शिक्षा की प्रकृति के बारे में नहीं है, लेकिन मेरा यह मानना है कि शिक्षाविदों द्वारा पढ़ाए जाने और व्यवसाय की अपेक्षा क्या है, के बीच एक बड़ा अंतर है। महंगे ऑन-द-जॉब प्रशिक्षण में व्यवसाय द्वारा भुगतान किए गए अंतर को पाटने का बिल। बड़ी प्रतिस्पर्धा और कठिन समय के साथ सभी अर्थव्यवस्थाएं गुजर रही हैं, मुझे आश्चर्य है कि आज इस अंतर को पाटने के लिए कौन कीमत चुकाएगा?

— NoChance

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

— जियोर्जियो

3

इसी तरह, यदि आप इंजीनियरिंग की पढ़ाई कर रहे थे और कार बनाना सीख रहे थे, तो कोई भी आपको यह नहीं सिखाता कि आपको एक विशिष्ट कार कैसे चलाना है: यह सिर्फ एक ऐसी चीज है जिसकी वे आपसे अपेक्षा करते हैं कि आप इसे जान सकें या सीख सकें।

— जियोर्जियो

1

व्यर्थ? यदि आपके पास वह डिग्री है जो आपके पास होने का दावा है तो आपको बेहतर पता होना चाहिए। यहां तक कि अगर आप वहां बैठे नहीं हैं, तो उन्नत गणित को पढ़ते हुए, इसका अध्ययन करने में सीखे गए पाठों का अनुवाद सीधे-सीधे स्वच्छ सुरुचिपूर्ण समाधान "देखने" में होता है।

— ऋग्वेद

0

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

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

— जेसिका ब्राउन
स्रोत

0

रखरखाव और रखरखाव

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

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

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

— केन लियू
स्रोत