क्या चौखट की बहुतायत प्रोग्रामर को डुबो रही है? [बन्द है]


22

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

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


यहाँ एक अच्छा लेख है जो मुझे कुछ साल पहले याद आया था जो आपके प्रश्न से संबंधित है। विशेष रूप से, लेखक एक समस्या के रूप में सीखने के मंच के रूप में BASIC के लिए कुछ की कमी का हवाला देता है। Salon.com/technology/feature/2006/09/14/basic
GrandmasterB

हम "अभी तक एक और" ढांचे के टन से उचित ढांचे को चुनने के लिए आवश्यक समस्या निवारण कौशल को प्रशिक्षित करते हैं।
systempuntoout


1
लोगों के एक समूह को नीचा दिखाने का क्या मतलब है?
रान्डेल शुल्ज

जवाबों:


18

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


हाँ, मुझे पता है कि एक JSP पेज में कुछ कच्ची SQL देखना एक "नहीं-नहीं" है, लेकिन यदि आप एक फील्ड कंसल्टेंट हैं, तो यह एक विशिष्ट समाधान कहाँ है? और नहीं, इसका मतलब यह नहीं है कि फ्रेमवर्क सही नहीं है, सभी ग्राहकों के पास हर मोड़ पर $ 20k बैठे हैं ताकि यह सुनिश्चित किया जा सके कि पृष्ठ पर एक मामूली डेटा बिंदु अनुमानित है।


4
+1...just solving MVC, it has gone too far.
तलवी वटिया

2
मुझे यह मज़ेदार लगता है कि ग्रात्ज़ी ने इस जवाब को स्वीकार कर लिया, बजाय इसके कि समुदाय ने अपने व्यक्तिपरक सवाल का सबसे अच्छा जवाब दिया (जो इसके विपरीत कहता है)। ऐसा लगता है कि वह एक सवाल पूछने के बजाय एक जवाब के लिए मछली पकड़ रहा था।
क्रेगे

1
@ क्रैज- क्या आप समझ रहे हैं कि सही उत्तर हमेशा सबसे लोकप्रिय उत्तर होता है?
जे क्यू कतार

1
@Xepoch - बिल्कुल नहीं। एक व्यक्तिपरक प्रश्न के रूप में, मुझे लगता है कि इस सवाल का कोई वास्तविक उत्तर नहीं है। मुझे बस यह दिलचस्प लगता है कि उसने इस उत्तर को चुना जो इस पृष्ठ के अधिकांश अन्य उत्तरों के विपरीत है। मुझे लगता है कि उसने एक ऐसा उत्तर पाया जो उसने अपने प्रश्न में सुझाया था, और यह तय किया कि यह सही था क्योंकि यह उसकी मान्यताओं के अनुरूप था।
क्रेजी

31

यह एक तर्क है जो नियमित रूप से, कई क्षेत्रों में और कई रूपों में पॉप अप होता है।

इस तर्क का सामान्य रूप है:

क्या [x: उपकरण / तकनीक] लोगों को बदतर बनाता है [y: x से प्रभावित कार्य]?

उदाहरण के लिए:

  • क्या सीएडी सॉफ्टवेयर बदतर इंजीनियरों के लिए बनाता है?
  • क्या हाई स्कूल में कैलकुलेटर गणित में छात्रों को बदतर बनाते हैं?
  • क्या सामाजिक सॉफ़्टवेयर लोगों के व्यक्तिगत कौशल को स्टंट करता है?
  • क्या लेखांकन सॉफ्टवेयर बदतर एकाउंटेंट का निर्माण करता है?

स्मृति से, सर्वव्यापी उत्तर लगभग हमेशा होता है: वास्तव में नहीं। आपके पास हमेशा ऐसे लोग होंगे जो [y] करने में अच्छे और बुरे हैं, लेकिन अब वे कौशल के एक अलग पहलू पर बुरे हैं।

किसी भी नौकरी के साथ बुनियादी बातों की गहरी समझ मदद करने जा रही है, चाहे आप कुछ भी करें - यहां तक ​​कि ऐसी नौकरियां जिन्हें 'उपचारात्मक' माना जाता है। ज्ञान हमेशा मदद करता है।


क्या बड़े रैकेट को टेनिस खिलाड़ियों से कम कौशल की आवश्यकता होती है?
सिस्टमोविच

22

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

मुझे याद है कि 90 के दशक के मध्य में C और CGI का उपयोग करके पहली बार कुछ डायनेमिक वेबसाइटों को विकसित किया गया था (ऐसे समय में जब अधिकांश वेबसाइटें अभी भी स्थिर HTML थीं)। वास्तव में कोई भी परिपक्व सर्वर-साइड स्क्रिप्टिंग लैंग्वेज (जैसे PHP या ASP) और बहुत कम लाइब्रेरियाँ नहीं थीं, इसलिए आपको हर पेज के साथ सर्वर पर संपूर्ण HTTP रिस्पांस स्ट्रीम लिखना था। अपने स्वयं के पुस्तकालय को लिखने के लिए GET और POST मापदंडों की आवश्यकता होती है। यह थकाऊ, धीमा, कड़ी मेहनत और बहुत त्रुटि प्रवण था। मैं इसे एक बिट याद नहीं है!

हालाँकि, मुझे यह भी लगता है कि ASP.NET वेब-फॉर्म्स जैसे कि वेब के संपूर्ण स्टेटलेस नेचर को एक ऐसे पॉइंट पर समेट दिया है, जहाँ कई नए वेब डेवलपर्स के पास इस बात का थोड़ा सुराग होता है कि वास्तव में हुड के नीचे क्या चल रहा है। यह अयोग्य, फूला हुआ कोड होता है जो खराब प्रदर्शन करता है क्योंकि डेवलपर एक "खींचें'एनआईडीआरपी" कार्यप्रणाली का उपयोग करके एक साथ पाइपलाइन घटक है, जो यह महसूस करता है कि HTTP स्तर पर क्या चल रहा है।

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


"ASP.NET वेब-रूपों के साथ अधिक सहमत नहीं हो सकता है" वेब की संपूर्ण स्टेटलेस प्रकृति को सार करता है "वहाँ कई बार मैं ऐसे डेवलपर्स से मिला हूं जो समझ नहीं पाते हैं कि नीचे क्या हो रहा है और साथ में मूर्खतापूर्ण समस्याएं पैदा हो रही हैंIsPostBack
billy.bob

14

क्या ऑटोमैटिक ट्रांसमिशन या रेन-सेंसिंग विंडशील्ड वाइपर हमें खराब ड्राइवर बनाते हैं?

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

अंततः यह सीखने के लिए डेवलपर पर निर्भर है। अच्छे लोग करते हैं, बुरे लोग नहीं करते।

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


11
स्वचालित
ट्रैनी

3
मैं केवल यह पूछकर असहमत हूं कि क्या फ्रेमवर्क अधिक खराब डेवलपर्स को सक्षम कर रहे हैं?
ग्रिट्ज़ी

2
@ ग्रेजी: मुझे ऐसा नहीं लगता। मुझे लगता है कि एक ही बुरे डेवलपर्स अभी भी फ्रेमवर्क के बिना कामयाब होंगे, बस अलग-अलग तरीकों से।
एडम लेअर

3
मैं अन्ना से असहमत हूं। फ्रेमवर्क के बिना भी आलसी प्रोग्रामर को अपने ज्ञान को व्यापक बनाना पड़ा। फ्रेमवर्क वास्तव में बढ़ रहे हैं (शायद बस थोड़ा) खराब प्रोग्रामर की संख्या।
जादूगर

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

10

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

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


4
"आपको इसे स्वयं करने की आवश्यकता है" मानसिकता कहाँ रुकती है? क्या प्रत्येक प्रोग्रामर को किसी एक का उपयोग करने से पहले अपना कंपाइलर लिखना होगा?
मिपाडी

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

6
ORM टूल का उपयोग न करने के तर्क के तहत, जब तक कि आपने इसे "पहले स्वयं नहीं किया है", मैं तब तक डेटाबेस एब्सट्रैक्शन लेयर का उपयोग नहीं कर सकता, जब तक कि मैंने डेटाबेस पर सीधे कॉल न लिखा हो? या वास्तव में, मुझे तब तक डेटाबेस का उपयोग नहीं करना चाहिए जब तक कि मैं फाइल सिस्टम का उपयोग करके स्टोरेज सिस्टम नहीं लिखता? खैर, फाइलसिस्टम एक अमूर्त है, मैं भी कहाँ से शुरू करूँ? प्रत्येक पीढ़ी के लिए, वे अमूर्तता के उच्च स्तर पर शुरू करने जा रहे हैं, या क्रम में कम समय में अधिक दिलचस्प चीजें प्राप्त करते हैं।
रेशनलगीक

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

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

4

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


4

यह फ्रेमवर्क नहीं है जो प्रोग्रामर को गूंगा करता है। गूंगा प्रोग्रामर गूंगा हो जाएगा कि वे फ्रेमवर्क का उपयोग करते हैं या नहीं।

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

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

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

वह बौद्धिक कार्य वह है जहाँ स्मार्टनेस बनाम डंबनेस और भी महत्वपूर्ण है।


4

जेम्स लार्स के उत्कृष्ट "स्पेंडिंग मूर डिविडेंड" (जोर जोड़ा) से उद्धृत :

तीस साल पहले, बिल गेट्स ने 5 साल की स्मृति को बचाने के लिए अल्टेयर बेसिक में "READY" से "ओके" में शीघ्र बदल दिया। आज, यह समझ से बाहर है कि डेवलपर्स को अपने कार्यक्रम के इस स्तर के बारे में पता होगा, अकेले इसके बारे में चिंतित होने दें, और ठीक ही इसलिए, क्योंकि इस परिमाण में परिवर्तन आज किसी का ध्यान नहीं है ... कोई तरीका नहीं है कि हम आज के सिस्टम का उत्पादन कर सकें। कारीगर, दस्तकारी प्रथाओं का उपयोग करना जो मेमोरी के 4K के साथ मशीनों पर संभव (आवश्यक) थे।

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


2

चौखटे महान हैं। लेकिन आपको यह जानना होगा कि हुड के नीचे क्या है। तो समस्या यह है कि प्रोग्रामर फ्रेमवर्क पर बहुत अधिक भरोसा करते हैं, बिना अंतर्निहित प्रणाली के पर्याप्त ज्ञान के।

कुछ हद तक पुराना उदाहरण एमएफसी है : एक प्रोग्रामर विंडोज एपीआई के बजाय एमएफसी का उपयोग करके बहुत समय बचा सकता है, लेकिन एपीआई के ज्ञान के बिना (जिसका मतलब कच्चे एपीआई के साथ वास्तविक कार्य की पृष्ठभूमि है), वे अक्सर फंस जाते हैं। । यह लगभग कभी खुश नहीं हुआ, क्योंकि एक सामान्य MFC प्रोग्रामर को Windows API ज्ञान था।

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

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


1

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

जिन लोगों को ढांचे के पीछे "सामान" की आवश्यकता है या जानना चाहते हैं वे हुक या बदमाश द्वारा अध्ययन और जांच करेंगे।


1

नहीं, बिल्कुल नहीं। चौखटे हैं, उनके मूल में, एक सबरूटीन लाइब्रेरी और एक टेम्पलेट का संयोजन, दो कोशिश की-और-सच प्रोग्रामर टूल। 'एक गरीब काम करने वाले ने अपने औज़ार को दोष दिया ...

... और फ्रेमवर्क का उपयोग करने और दोष देने वाले बहुत सारे गरीब कामगार हैं।


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

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

1

सॉफ्टवेयर का निर्माण करते समय, रूपरेखा समय की बचत करती है। सॉफ्टवेयर बनाने के लिए सीखने के दौरान, ढांचे समझ के रास्ते में आते हैं।

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

हो सकता है कि स्कूलों में एक समर्पित विषय "अनुकूलित डिजाइन" होना चाहिए जहां आपको मजबूत स्थान और समय प्रतिबंधों के तहत कार्यक्रम बनाने हों?


-1

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

अधिकांश फ्रेमवर्क में फ़ंक्शंस होंगे जो प्रोग्रामर बार-बार उपयोग करते हैं।


1
ओ, आप अपने उत्तर के साथ अधिक गलत नहीं हो सकते।
एनबी

-1

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


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