क्या प्रोग्रामिंग नीचे की दौड़ में एक पेशे के रूप में है? [बन्द है]


41

यह मुझे लगता है कि प्रोग्रामिंग उद्योग नीचे की दौड़ में है। यदि हम अभ्यास करते हैं:

  1. सर्वोत्तम प्रथाओं को लागू करने में समय नहीं लग रहा है
  2. अन्य लोगों के कोड का यथासंभव उपयोग करना (कस्टम कोड एक दायित्व के रूप में)
  3. उत्पादकता में सुधार के लिए उच्च स्तर की भाषाओं का उपयोग करना
  4. जीयूआई आधारित विकास "उपकरण" जो "प्रोग्रामिंग" को बहुत सरल करता है और कोड के पीछे प्लंबिंग को समझने के लिए लोगों की आवश्यकता नहीं होती है

ये बातें मेरे लिए काफी मायने रखती हैं कि हम किसी अन्य कार्यालय कार्यकर्ता की तरह बनने की दौड़ में हैं। यह चीजों के लिए नियोक्ता के हित में है, कौशल की आवश्यकता नहीं है (प्रतिस्थापित करने के लिए आसान), चीजों को पूर्वनिर्मित करने के लिए (कम परियोजना समय)।

यहाँ मेरा कहना यह है कि क) क्या नियोक्ता के कौशल और आर्थिक हितों के बीच कोई गलतफहमी है? और ख) यदि वहाँ है, तो आप इसे कैसे पेशेवर मानकों को लागू करने के लिए कम करते हैं?


28
खैर, किसी को अभी भी उन उपकरणों को बनाना है। तो कुछ अर्थों में यह अच्छे प्रोग्रामर को उबाऊ काम से दूर रखने की दौड़ है।
जेरेमी हीलर

11
क्यों किसी का मानना ​​है कि सॉफ्टवेयर विकास का भविष्य घसीटने और छोड़ने वाले घटकों को उबाल देगा, यह मेरे से परे है। गंभीरता से, क्या आप ईमानदारी से मानते हैं कि यह इतना आसान होगा।
पेमदास

3
@ पेमदास: प्रगति और / या परिवर्तन अगर मानव भय। स्टीम लोकोमोटिव 150 साल पहले बुराई के रूप में माना जाता था।

4
@ पियरे मुझे यकीन नहीं है कि मैं समझता हूं कि आप कहां जा रहे हैं।
पेमदास 21

3
दिज्क्स्त्र, क्या आप?
l0b0

जवाबों:


6

मुझे लगता है कि आपने बहुत ही मार्मिक प्रश्न पूछा है।

GUI कोडिंग टूल बनाने से प्रोग्रामर को एक नौकरी से बाहर रखा जाता है, क्योंकि रोबोट असेंबली लाइन के कर्मचारियों को नौकरी से निकाल देते हैं। मेरी राय में, जहां नौकरियों का नुकसान होता है, वहीं अगली नौकरियों के लिए एक बदलाव भी होता है।

किसी कार्य को करने के लिए प्रौद्योगिकी में परिवर्तन किए जाते हैं, लेकिन कार्य को अभी भी पूरा करने की आवश्यकता है: कारों को अभी भी चलाने / इकट्ठा करने से पहले उन्हें इकट्ठा करने की आवश्यकता है; कोड / व्यापार तर्क अभी भी आवेदन करने के लिए एक साथ काम करने की जरूरत है।

प्रोग्रामर के लिए प्रौद्योगिकी मौजूद विकल्पों में बदलाव: GUI आधारित प्रोग्रामिंग या प्रोग्राम GUI टूल ... या ... कुछ और पूरी तरह से जानें।

कर्मचारियों के कौशल और नियोक्ता के हितों के बीच एक मिसलिग्न्मेंट हो सकता है, लेकिन लंबे समय तक नहीं, खासकर अगर नियोक्ता समझदार है। इसलिए यह नियोक्ता और कर्मचारी दोनों के सर्वोत्तम हित में है कि वे अपने पारस्परिक लाभ के लिए क्या करें। लेकिन एक अनिवार्य रूप से दूसरे से आगे होगा। उम्मीद है कि यह आप (-:

शुभकामनाएँ,

के.एम.


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

@ q303: हमेशा बहुत सारे अनुप्रयोग होंगे जो सभी उपलब्ध कंप्यूटर पावर को उठाएंगे।
डेविड थॉर्नले

58

आपके द्वारा बताए गए रुझानों में मैं एक और जोड़ूंगा, जो IMHO उन्हें समझाता है:

वहाँ पहले से कहीं अधिक प्रोग्रामर (जरूरत) है।

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

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

मुझे आपकी बातों के खिलाफ शैतान के वकील की भूमिका निभाने दें:

सर्वोत्तम प्रथाओं को लागू करने में समय नहीं लग रहा है

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

अन्य लोगों के कोड का यथासंभव उपयोग करना (कस्टम कोड एक दायित्व के रूप में)

क्या विरोध किया? पहिया बदलते? या उससे बचने के लिए अन्य लोगों के कोड का उपयोग कर रहे हैं?

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

उत्पादकता में सुधार के लिए उच्च स्तर की भाषाओं का उपयोग करना

विधानसभा में सब कुछ कोड करने के लिए विरोध के रूप में? ;-)

जीयूआई आधारित विकास "उपकरण" जो "प्रोग्रामिंग" को बहुत सरल करता है और कोड के पीछे प्लंबिंग को समझने के लिए लोगों की आवश्यकता नहीं होती है

IMHO किसी भी उपकरण का दुरुपयोग किया जा सकता है। यह कहना नहीं है कि जीयूआई बिल्डरों को जरूरी सही या अच्छा था - उनमें से अधिकांश (या कम से कम कुछ) उनकी सीमाओं के भीतर उपयोग करने योग्य हैं। लेकिन अगर कोई उन सीमाओं को नहीं जानता है, तो क्या यह उपकरण या उसके उपयोगकर्ता की समस्या है?

सामान्य तौर पर, मेरा मानना ​​है (हालांकि इसे साबित करने के लिए कोई सबूत नहीं है) जो कि पंच कार्ड और मशीन कोड दिनों में वापस आ गया है, मौजूदा कोड का लगभग उसी अनुपात अब तक भयानक था, बस दोनों

  • कोड की समग्र राशि, और
  • बाहरी लोगों की संभावना कभी ऐसे कोड को देखकर

बहुत कम था।

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


+1, मुझे लगता है कि हम "हर समाधान नई समस्याओं को जन्म देते हैं" प्रतिक्रिया चक्र - यह नहीं कह सकता कि क्या यह एक नकारात्मक या सकारात्मक लूप है।
मैगलो

6
+1 यदि केवल अच्छे कोडर्स ही स्क्रैच से सब कुछ दोबारा लिखते हैं, तो मैं खुशी से एक भद्दा प्रोग्रामर बनूंगा।
एंड्रयूज

1
मैं अपने अंडरवियर में चिप्स नहीं चाहता, जब तक कि अपटाइम स्वीकार्य न हो!

@ थोरबजर्न: अंडरवियर के लिए क्या स्वीकार्य अपटाइम है? यदि यह स्वयं-धुलाई था, तो मुझे अपटाइम के बारे में चिंता होगी ... अन्यथा आप उन्हें हर दिन वैसे भी उतार देंगे (मुझे आशा है!)
डीन हार्डिंग

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

29

आप स्थिति को सही ढंग से सारांशित करते हैं, लेकिन अर्थ की पूरी तरह से गलत व्याख्या करते हैं।

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

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


दिलचस्प बात ...
21

10
मैं ग्रैंडमास्टरबी को कुछ विज्ञान-फाई लिखना पसंद करूंगा।
22

5
अपने फ़ोन पर मेरा अपना Google डेटा केंद्र होने का इंतजार नहीं कर सकता।
मार्टिन यॉर्क

3
@Slomojo विज्ञान कथाओं के रूप में नहीं जैसा कि आप सोच सकते हैं। जब मैं तीसरी कक्षा में बच्चा था तो मैंने अपने घर के पास कॉलेज में एक कंप्यूटर प्रदर्शन का दौरा किया। यह जनता के लिए एक प्रयोगात्मक प्रदर्शन था। प्रदर्शन के कार्यक्रमों में से एक टिक-टैक-टो का एक चंचल खेल था। उस समय यह एक ओह और आह क्षण माना जाता था जो कंप्यूटर के खिलाफ गेम खेलने में सक्षम हो। यह 60 के दशक के अंत में था। ओह और आह के क्षण अब से 100 साल क्या होंगे?
बिल

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

18

मैंने चालीस वर्षों से उस तरह की चीज़ को पढ़ा है, और मैं भविष्यवाणियों की शुरुआत में नहीं था। यह अभी तक नहीं हुआ है।

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

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

यह पैटर्न हमेशा के लिए नहीं चलेगा, लेकिन मुझे यह समझाने के लिए सैद्धांतिक तर्क और भविष्यवाणियों से अधिक कुछ चाहिए कि प्रोग्रामिंग वास्तव में कठिन है।

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


7
+1 - "एक सटीक विनिर्देश लें और इसे कुछ सटीक और उपयोगी में बदल दें।"
22

+1, मैं इस खेल में तब तक नहीं रहा जब तक कि आप हैं, लेकिन निश्चित रूप से मैंने उसी तरह की बात सुनी है, जैसा कि इस प्रश्न में कहा गया है और 20 वर्षों के लिए फिर से कहा गया है।
कार्सन 63000 0

+1 के लिए 4 जी का मैं बिल्कुल यही कहने आया था। वह सब वादा, इतनी कम डिलीवरी :)
इयान

"यह पैटर्न हमेशा नहीं रहेगा" - क्यों नहीं?
इयान वारबटन

3

असेंबली और फोरट्रान प्रोग्रामर्स ने संभवतः वही बातें कही हैं जब संरचित प्रोग्रामिंग और व्यापक व्याख्याकर्ता चित्र में आ रहे थे।

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

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

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


3

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

हाँ यह है, और यह होना चाहिए

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

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

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

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


1

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


1

इससे कोई फर्क नहीं पड़ता कि आप शेल्फ को स्वचालित या खींच सकते हैं, अधिकांश पैकेज्ड सॉफ्टवेयर दो श्रेणियों में आता है:

  1. यह उपयोग करने के लिए सरल है, लेकिन यह काफी मेल नहीं खाता है कि व्यवसाय को वास्तव में क्या चाहिए
  2. यह अत्यधिक अनुकूलन योग्य है, लेकिन यह अनुकूलन को समझने और इसका लाभ उठाने के लिए एक विशेषज्ञ को लेता है

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

हमेशा डेवलपर्स की आवश्यकता होगी। मैं जो देख रहा हूं, वह यह है कि मैनुअल, थकाऊ, दोहराव वाले काम का अधिक उपयोग स्वचालित हो गया है (हाथ से डेटा एक्सेस के लिए कोड लिखना सोचें / ओ / आरएम का उपयोग करके)। यह डेवलपर्स को कम प्रयास के साथ व्यवसाय में अधिक मूल्य देने की अनुमति देता है।


1

मैं आपके तर्क नहीं लेता:

  1. सर्वोत्तम प्रथाओं को लागू करने में समय नहीं लग रहा है

सिवाय इसके कि।

  1. अन्य लोगों के कोड का यथासंभव उपयोग करना (कस्टम कोड एक दायित्व के रूप में)

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

  1. उत्पादकता में सुधार के लिए उच्च स्तर की भाषाओं का उपयोग करना

उत्पादकता प्रति se खराब नहीं है - क्या यह है?

  1. जीयूआई आधारित विकास "उपकरण" जो "प्रोग्रामिंग" को बहुत सरल करता है और कोड के पीछे प्लंबिंग को समझने के लिए लोगों की आवश्यकता नहीं होती है

यदि उपकरण काम करता है: इसका उपयोग करें। यदि नहीं: तो इसे मना कर दें। यदि वादा होता है, और लोगों को वास्तव में कोड को समझने की आवश्यकता नहीं है - अच्छी तरह से किया! आपको लगता है कि यह एक वादा है जो पकड़ नहीं है लगता है?

(यहां संख्याएँ स्वचालित रूप से गलत हैं। :))


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

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

1

दृश्य प्रोग्रामिंग पाठ आधारित प्रोग्रामिंग की तुलना में कम वैध या स्कोर्न के योग्य नहीं है।

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

यदि आपको Labview की कोशिश करने का मौका मिलता है, तो आप संभावित (या लेगो एनएक्सटी वातावरण में एक विशेष संस्करण) भी देख सकते हैं। जबकि खामियों या कमियों के बिना, विरासत में लाभ नहीं हैं। देखकर ही विश्वास किया जा सकता है।


0

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


0

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

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


-2

यदि हम अभ्यास करते हैं:

  • सर्वोत्तम प्रथाओं को लागू करने में समय नहीं लग रहा है
  • अन्य लोगों के कोड का यथासंभव उपयोग करना (कस्टम कोड एक दायित्व के रूप में)

WTF? क्या आपके पास इस सूची के असंगत होने का मतलब है? सूचियों को बिना चेतावनी के पीछे और पीछे जाने के बजाय प्रत्येक तत्व के लिए एक ही पक्ष से आना चाहिए। इस प्रकार आपकी सूची को पढ़ना चाहिए:

यदि हम अभ्यास करते हैं:

  • सर्वोत्तम प्रथाओं को लागू करने में समय नहीं लग रहा है
  • अन्य लोगों के कोड का अधिक से अधिक उपयोग करना (कस्टम कोड एक दायित्व के रूप में)


1
@ नोहा रॉबर्ट्स: आपका संपादन दूसरी बुलेट बिंदु का अर्थ बदल देता है। यह भी सवाल का उचित जवाब नहीं है और इसके बजाय एक टिप्पणी होनी चाहिए।
एडम लेअर

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

आधार क्या है?
21

3
@ नोहर रॉबर्ट्स: यह थोड़ा अजीब तरह से शब्द है, लेकिन मेरा मानना ​​है कि सूची अपने अर्थ में सुसंगत है - q303 अपने तर्क में सहायक बिंदु के रूप में "कस्टम कोड इन-हाउस लिखने के बजाय अन्य लोगों के मौजूदा कोड का उपयोग" कर रहा है।
एडम लेअर

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