आईडीई आश्रित होना। यह मुझे कैसे नुकसान पहुंचा सकता है?


27

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

क्या आपको लगता है कि यह मुझे परेशान करता है? कुछ प्रोग्रामर जिनके पास 6 साल से अधिक का विकास अनुभव है, वे दृढ़ता से मानते हैं कि इससे नुकसान हो सकता है, लेकिन मुझे लगता है कि अगर मैं कुछ जटिल चीजें तेजी से और ठीक से कर सकता हूं तो मुझे समय लेने वाले कार्य करने के लिए नोटपैड और कमांड लाइन टूल्स से क्यों चिपकना चाहिए? आईडीई के पास ऐसा करने के लिए एक बटन क्लिक है?


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

5
यह मेरे लिए एक आकर्षक प्रश्न है; मैंने कभी भी Emacs या Vi के अलावा किसी और चीज में प्रोग्राम नहीं किया है। परिणाम के रूप में मुझे पता नहीं है कि एक आईडीई आपको क्या देता है जो आप पर निर्भर हो सकते हैं।
१५:५५ पर कस्तर्मा

8
@kasterma मुझे देखने दें: कोड सहायता, रीफ़ैक्टरिंग टूल, कोड आउटलाइनिंग, डीबगिंग, पैरामीटराइज़्ड डीबगिंग, स्टैक ट्रेसिंग, पैरामीटर देखना, सॉल्यूशन स्ट्रक्चरिंग, रेड, इंटेलीसेंस, कोड स्निपेट्स, कंप्लाइज़ेशन और कंपाइलर एरर असिस्ट, स्टैंडर्ड्स इन्फोर्समेंट, क्विक स्टार्ट टेम्प्लेट, सिंटैक्स हाइलाइटिंग और अधिक ;-)
Syg

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

7
@ लैक्रोमोलॉजी: जावा आईडीई निर्भर नहीं है और वहां से सबसे लोकप्रिय भाषाओं में से एक है। मुझे लगता है यह चौंकाने वाला है कि आपको नहीं लगता कि यह "वास्तविक" पर्याप्त है।
जोश के

जवाबों:


15

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

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

जब आप आईडीई से बाहर होते हैं तो यह आपको प्रभावित नहीं करता है - यदि आईडीई की जटिलताओं का ज्ञान आप से छिपा हुआ है, तो आप उथले हैं, तो जब यह गलत हो जाएगा (और यह गलत हो जाएगा, किसी बिंदु पर) आप पाएंगे इसे ठीक करना बहुत कठिन है।

मैं इसे दो तरीके से संभालता हूं:

  1. नए उपकरणों को उनके सबसे बुनियादी रूप में जानें। उदाहरण के लिए, मैंने SVN से Mercurial पर स्विच किया, लेकिन ग्रहण प्लगइन के बजाय कमांड-लाइन क्लाइंट के साथ शुरू किया। इससे मेरी समझ बहुत गहरी चल रही थी, जिसका मतलब था कि मुझे पता था कि क्या गलत हो रहा है और इसे कैसे ठीक किया जाए जब IDE ने त्रुटियां की हैं।

  2. कमांड-लाइन पर अपने बुनियादी कोडिंग कौशल का अभ्यास करें। ऐसा करने के लिए एक अच्छी जगह कोडिंगबैट है जहां आपको कोई सिंटैक्स हाइलाइटिंग नहीं मिलता है, कोई ब्रैकेट मिलान नहीं होता है, कोई लाल रेखांकित नहीं होता है, कुछ भी नहीं। हालांकि उन जावा और javac कमांड लाइन कौशल का भी अभ्यास करने के लिए मत भूलना! (और आपके वर्कफ़्लो के लिए उपयुक्त कोई अन्य - मेरे लिए, इसमें hg और ant भी शामिल होंगे)

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


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

कोडिंगबैट में अब सिंटैक्स हाइलाइटिंग है।
मास्टरएक्सिलो

29

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

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


2
Intellisense के लिए +1! मैं लोगों के लिए खेद महसूस करता हूं जब मैं उन्हें एक कार्यक्रम में प्रत्येक चरित्र को टाइप करता हूं जब इंटेलीजेंस इतनी तेजी से गति देगा।
डेविड

8
यह हम में से बाकी लोगों के लिए स्वत: पूर्ण कहा जाता है :)
mhitza

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

1
@ जोश के: यह सच है। स्वतः पूर्ण करने से प्रोग्रामर खराब हो सकते हैं, लेकिन यह अच्छे प्रोग्रामर को अधिक कुशल बनाने में भी मदद कर सकता है। :)
डेविड

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

24

नहीं, यह आपको "नुकसान" नहीं करता है। बेशक, आपको यह समझना चाहिए कि आईडीई के बिना चीजें कैसे काम करती हैं (यानी आपको मूल संकलन प्रक्रिया को समझना चाहिए, आदि), लेकिन आइए इस बारे में कोई बात न करें ... अगर कोई आईडीई आपको एक का उपयोग न करने की तुलना में अधिक उत्पादक बनाता है, तो क्यों नहीं होगा ' आप?


17

आईडीई आश्रित होने के निम्नलिखित जोखिम हैं:

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

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

अन्य आईडीई निर्भरता जोखिम:

  • IDE आपके कोड में त्रुटियों और चेतावनियों को चिह्नित करता है और आपको त्वरित सुधार देता है। ये उचित नहीं हो सकता है - हो सकता है कि खेलने के दौरान कोई डिज़ाइन या आवश्यकता का मुद्दा हो।
  • आप मूल बातें भूल जाते हैं - आपको अपनी चुनी हुई भाषा की मूल बातें जानने की आवश्यकता होती है ताकि आप इसमें महारत हासिल कर सकें और ताकि आप साक्षात्कारों में दक्षता प्राप्त कर सकें।
  • आप एक IDE सैंडपिट में अटके हुए हैं - कुछ भी नया या कुछ भी करने की कोशिश करने से डरते हैं जो आपके IDE द्वारा समर्थित नहीं है। उदाहरण के लिए आपके आईडीई में खोज और प्रतिस्थापन के लिए काफी व्यापक कार्य हो सकते हैं। लेकिन ये grep और sed जैसे कमांड लाइन टूल्स की शक्ति और गति की तुलना में कुछ भी नहीं हैं। आप Android विकास नहीं कर सकते क्योंकि आपका चुना हुआ IDE (उदाहरण के लिए netbeans) इसे अच्छी तरह से समर्थन नहीं करता है।
  • कुछ आईडीई बड़ी फ़ाइलों को संभाल नहीं सकते हैं - जैसे कि ग्रहण में एक बड़े सर्वर आउटपुट फ़ाइल को खोलने का प्रयास करें। यह हमेशा के लिए और / या स्मृति से बाहर चलाता है।

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

2
मेरे जवाब में आईडीई के उदाहरणों का संदर्भ सिर्फ इस बात के उदाहरण हैं कि आईडीई निर्भरता जोखिमपूर्ण कैसे हो सकती है। मैं विशेष रूप से netbeans या ग्रहण को इंगित नहीं कर रहा हूँ।
कॉनर

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

9

आपके चुने हुए उपकरणों के सेट के साथ अधिक उत्पादक होने में कुछ भी गलत नहीं है। लेकिन अगर आप इसके बिना काम नहीं कर सकते हैं, तो मुझे आपके आंतरिक ज्ञान पर बहुत संदेह होगा।

आईडीई को मत छोड़ो; लेकिन समय-समय पर एक ब्राउज़र पर सिर्फ एक संपादक और प्रलेखन के साथ कुछ 'आसान' कक्षाएं करने की कोशिश करें।

याद रखें कि सबसे अच्छा उपकरण की तुलना में भी तेजी से उनका उपयोग करने के लिए नहीं है।


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

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

4

लेकिन बिना आईडीई के मैं कुछ नहीं कर सकता।

मुझे जटिल चीजों को करने के लिए एक आईडीई की जरूरत है या सरल चीजों की लंबी कोडिंग।

आप इसे ठीक कर सकते हैं, आप जानते हैं।

आप वास्तव में भाषा और रूपरेखा सीख सकते हैं।

आपको कुछ भी नहीं रोक रहा है।

जब तक, निश्चित रूप से, आप आईडीई पर निर्भर होने के बारे में डींग मार रहे हैं।

जब आईडीई को ऐसा करने के लिए बटन पर क्लिक करना हो, तो मुझे समय लेने वाले कार्य करने के लिए नोटपैड और कमांड लाइन टूल से क्यों चिपकना चाहिए?

असंबंधित है। "स्टिक टू नोटपैड" पूरी तरह से "बिना आईडीई के मैं कुछ नहीं कर सकता" से संबंधित है। नोटपैड में कुछ नहीं करना नोटपैड से चिपके रहने जैसा कुछ नहीं है। यह किसका है?


3

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


क्या आप दूसरी भाषा के लिए भी ऐसा ही कहेंगे? (मैं अपने मामले में PHP सोच रहा हूं) लेकिन मुझे एक सामान्य नियम के रूप में इसकी अच्छी सलाह पर यकीन नहीं है। हालांकि JAVA यहां अपवाद हो सकता है
Quamis

1
मैं C # के लिए भी ऐसा ही कहूंगा, PHP के लिए भी हो सकता है। भाषा और समस्या डोमेन के किसी भी संयोजन जहां आपको विविध पुस्तकालयों के विशाल सेट का उपयोग करना होगा, स्मार्ट उपकरणों की आवश्यकता होगी। कुछ भाषाएं शक्तिशाली और अभिव्यंजक हैं जो कई पुस्तकालयों के बिना उपयोग करने योग्य हैं - और आप आईडीई के बिना सरल चीजों को कोड कर सकते हैं। कुछ भाषाओं को हमेशा सरलतम चीजों के लिए भी सहायता की आवश्यकता होती है। जब मैं लिस्प में कोड करता हूं, तो मैं emacs या यहां तक ​​कि CLI REPL के साथ ठीक हूं। जब मैं C # या Java में कोड करता हूं, तो मैं एक सभ्य IDE (msvs या ग्रहण) के बिना कुछ भी नहीं करूंगा।
तर्क

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

क्वामिस: क्या यह उल्टा नहीं है? टाइप करने से आप उन छोटे नामों को चुनते हैं जो कक्षा / विधि के साथ-साथ एक लंबे नाम का वर्णन नहीं करते हैं।
दूरंतो

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

3

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

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


2

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

मैंने कमांड-लाइन एनवायरनमेंट (VAX / VMS) में C और फोरट्रान 77 पर अपने दाँत काटे, इसलिए मुझे IDE की आवश्यकता कुछ संदिग्ध लग रही है। हालांकि, उन जानवरों की तुलना में छोटी भाषाएं हैं जो जावा हैं; यह देखते हुए कि आपको नवीनतम जावा नटशेल पुस्तक को ले जाने के लिए एक फोर्कलिफ्ट की आवश्यकता है, मैं देख सकता हूं कि कैसे आईडीई उपलब्ध होने से जीवन बहुत आसान हो जाता है।


2

यह वास्तव में आपको "नुकसान" नहीं दे सकता है, लेकिन अगर आप आईडीई के बिना चीजों को करने से परिचित हैं, तो आप लाभान्वित होंगे। अपने क्षितिज का विस्तार करने से डरो मत।

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

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

यह सिर्फ एक प्रोग्रामर के रूप में असेंबली सीखने जैसा है - हम में से बहुत कम लोग आज हाथ से विधानसभा लिखते हैं, लेकिन मेरा मानना ​​है कि असेंबली समझने वाले लोग जिस भी भाषा का उपयोग कर रहे हैं, उसमें बेहतर प्रोग्रामर हैं।


2

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

गंभीरता से: यदि <disclaimer>आप एक आईडीई का उपयोग </disclaimer>करते हैं और आप अपने आप को एक आईडीई के बिना पाते हैं और आपको जरूरी प्रोग्राम करना चाहिए, तो आपको बस अपने आप को खेल पर विचार करना चाहिए और

  1. आईटी को बुलाओ या
  2. यदि आप IT हैं, तो समस्या को स्वयं ठीक करें

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


1

आईडीई आश्रित होने के कारण आपको नुकसान नहीं हो सकता है, लेकिन आपकी पसंद के वातावरण के बिना काम करने में सक्षम होना एक महत्वपूर्ण कौशल है।

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

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


0

आइए एक अच्छा टेक्स्ट-एडिटर आज़माएं, जैसे MS-Windows के लिए PSPad (फ्रीवेयर), Mac OS X के लिए TextMate , GNU डेस्कटॉप के लिए Geany (ओपनसोर्स) या KDE के लिए Kate (ओपनसोर्स)।

MS-DOS के लिए MultiEdit4.0 ने कई साल पहले मेरे जीवन को बदल दिया है, तब से मैं पाठ संपादकों के लिए बहुत समझदार हूं।

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