उन लोगों के लिए जो सॉफ्टवेयर के निर्माण से संबंधित नहीं हैं, डेवलपर का काम काफी आसान लग सकता है: आप बाजार में मांग में हैं, वे अच्छी तरह से भुगतान करते हैं, कंपनियां सुखद nishtyaks को खुश करने की कोशिश करती हैं, और इसी तरह। यह सब सच है, लेकिन अगर ईमानदार होना है, तो प्रोग्रामर के पास बहुत सारे अप्रिय क्षण हैं। हमने दस सबसे लोकप्रिय चीजों को एकत्र किया है जो सबसे अधिक बार सॉफ्टवेयर निर्माताओं को परेशान करते हैं।
10. लोहा
बेशक, कार्यक्रमों को चलाने के लिए उपकरणों की आवश्यकता होती है। और कोई फर्क नहीं पड़ता कि कैसे कुछ डेवलपर्स सॉफ़्टवेयर की भूमिका को अनदेखा करने की कोशिश करते हैं, जितनी जल्दी या बाद में सॉफ़्टवेयर बनाते और डिबगिंग करते समय, वे अनिवार्य रूप से उपकरणों के लिए विशिष्ट समस्याओं का सामना करेंगे। इसलिए, शुरुआती लोगों को सलाह दी जाती है कि वे हमेशा लोहे की सुविधाओं और उन प्रणालियों का अध्ययन करें जिन पर उनके कोड को निष्पादित किया जाएगा, ताकि बाद में कम कठिनाइयों का सामना करना पड़े।
"हर प्रोग्रामर जो कम से कम एक बार डेटाबेस सर्वर पर एक अजीब दुर्घटना को डिबग करता है या यह समझने की कोशिश करता है कि RAID ड्राइव ठीक से काम क्यों नहीं कर रहे हैं, यह जानता है कि यह हार्डवेयर समस्याएं कितनी दर्दनाक हैं।" स्टीव बोरथविक
"प्रोग्रामर हार्डवेयर से नफरत करते हैं क्योंकि वे हमेशा उस पर सब कुछ दोष नहीं दे सकते हैं!" गुमनाम
9. पूरा दिन बैठो
जब तक आपके पास ट्रेडमिल के साथ एक डेस्कटॉप है, तब तक सॉफ्टवेयर विकास एक तरह का एरोबिक व्यायाम नहीं होगा। अधिकांश प्रोग्रामर लंबे समय तक अपनी गांड पर बैठकर, कीबोर्ड को टैप करते हुए और स्क्रीन पर स्पष्ट रूप से घूरते रहते हैं। कुछ समय बाद, लंबे समय तक बैठे रहना बहुत असहज हो सकता है। और यदि आप परिवेश को बदलने के लिए किसी अन्य स्थान पर भी नहीं जा सकते हैं, तो यह कभी-कभी आपको पीड़ा देता है।
“मैं पूरे दिन एक कुर्सी पर बैठता हूं और स्क्रीन पर घूरता हूं। यह कुछ समय पहले शुरू हुआ था ... पहली पीठ, फिर गर्दन, आँखें थक गई थीं और जैसे कि जलन, सिरदर्द ... पैरों की शांति नहीं है ... मैंने फिटनेस, ताजिक्यन, योग, चीगोंग के साथ इसकी भरपाई करने की कोशिश की, मैं एक साइकिल पर काम करने के लिए चला गया - और फिर भी मैं अब बैठ नहीं सकता आठ या अधिक घंटे। पूरा दिन ऑफिस में बिताने के लिए ... सूरज को आसमान से गुजरते हुए देखो, इस लानत की कुर्सी से नहीं, जबकि जीवन गुजरता है। " मार्कस टोमन
8. डिबगिंग
यहां तक कि सबसे अच्छा, सावधानीपूर्वक लिखा गया कोड बग के बिना नहीं है। स्वाभाविक रूप से, डेवलपर्स को नियमित रूप से समय खोजने और दोषों को ठीक करने के लिए मजबूर किया जाता है - उनके कोड में और किसी और में। कुछ कीड़े आसानी से पाए जाते हैं और उनका इलाज किया जाता है, जबकि अन्य अपनी मायावी के साथ सफेद गर्मी ला सकते हैं, जिससे उन्हें कई घंटे बिताने के लिए मजबूर होना पड़ता है और उनके मानस की स्थिरता पर संदेह होता है।
“एक कठिन-से-पुनरुत्पादन का पता लगाना या सबसे बुरा, एक एकीकरण परीक्षण बग पर प्रकट होना जो गलती से कोड के एक ही टुकड़े पर गुजरता है या विफल रहता है !!! तब ऐसा महसूस होता है कि आप इन शापित रहस्यमय बग को कोड में कहीं छिपाकर कभी नहीं पा सकते। फू! " इमैनुएल एनक्वेने
"हम इतने बड़े कार्यक्रम लिखते हैं (कभी-कभी छोटे भी) कि डिबगिंग करते समय, हम ऐसे विलेड्स में तल्लीन हो जाते हैं और बग के बारे में भूल जाते हैं । " आयुष भटनागर
“डिबगिंग, खासकर जब हजारों लाइनों की बड़ी परियोजनाओं पर काम कर रहे हों। मेरे जैसे कई दिग्गज डिबगिंग के दौरान छवि को प्रोजेक्टर के माध्यम से प्रदर्शित करना पसंद करते हैं, ताकि यह आंखों के लिए आसान हो। " इसहाक पेरेस
7. गरीब प्रलेखन
अन्य लोगों के कोड के साथ काम करना कभी-कभी कष्टप्रद होता है, लेकिन यदि यह अच्छी तरह से प्रलेखित है तो ऐसा नहीं है। दुर्भाग्य से, यह हमेशा मामला नहीं होता है। यदि कोड में कोई टिप्पणी नहीं है या सामान्य रूप से लिखा गया है कि सब कुछ कैसे काम करता है, तो आपको एप्लिकेशन को डीबग करना, विस्तारित करना या एकीकृत करना अधिक समय बिताना होगा। और यह प्रोग्रामर की भलाई को सबसे अच्छे तरीके से प्रभावित नहीं करता है।
"सबसे अधिक कष्टप्रद है जब आप खराब दस्तावेज वाले सॉफ़्टवेयर से निपटने के लिए काम पर रखे जाते हैं। यह उन लोगों के लिए जीवन कठिन बनाता है जो परियोजना पर काम स्वीकार करते हैं। टिप्पणियों और खराब शब्दार्थों की कमी, खासकर जब बग और त्रुटियों का एक गुच्छा पिछले प्रोग्रामर के बाद रहा। " एंजेल एंजिल्स III
"परीक्षण एक अवांछित और अनियोजित कोड में है जो कुछ बेवकूफों ने लिखा है।" अभिषेक चौहान
", अधिकांश प्रोग्रामर की तरह, मैं नया लिखने की तुलना में खराब दस्तावेज कोड बनाए रखने में अधिक समय व्यतीत करता हूं।" वॉल्ट करास
6. कोड विलय
गिट या तोड़फोड़ जैसे स्रोत नियंत्रण प्रणाली महान उपकरण हैं जो कई प्रोग्रामर को अपनी कोहनी को धक्का दिए बिना एक ही समय में एक ही कोड बेस पर काम करने की अनुमति देते हैं। लेकिन अंत में, रिपॉजिटरी के लिए बदलावों के लिए प्रतिबद्ध होने की जरूरत है, और संघर्ष यहां उत्पन्न हो सकता है, अगर कहते हैं, दो डेवलपर्स ने एक फ़ाइल या सबरूटीन को बदल दिया। कभी-कभी ऐसे संघर्षों को बस हल किया जाता है, कभी-कभी ऐसा नहीं होता है।
" मैं विलय की तरह नहीं हूं, क्योंकि मैं कोड बदलना चाहता हूं इसलिए मेरे सहयोगी इसे अलग तरीके से करना चाहते हैं - और हम क्या करते हैं? "मैं हमेशा दोनों समाधानों को संयोजित करने के तरीके खोजने की कोशिश करता हूं, लेकिन यदि कोई वास्तविक संघर्ष उत्पन्न होता है, तो विलय एक बहुत अप्रिय कार्य बन जाता है।" जेसिका सु
"विलय का संघर्ष" पूर्ण बुराई । कुतुव सिन्हा
5. अवास्तविक अपेक्षाएँ
सॉफ्टवेयर डेवलपर्स - लोग बेवकूफ से बहुत दूर हैं। लेकिन इस कारण से, सभी प्रकार के बॉस, परियोजना प्रबंधक, और बिक्री के लोग अक्सर अवास्तविक, उच्च उम्मीदें दिखाते हैं कि प्रोग्रामर या प्रोग्रामर की टीम एक निश्चित तिथि तक क्या बना सकती है, और इसलिए बहुत अधिक योजना बनाते हैं। नतीजतन, डेवलपर्स अंततः काम पर बाहर जला देते हैं और आमतौर पर इससे खुशी महसूस नहीं करते हैं।
"लोगों को समझाने के लिए सबसे अप्रिय बात यह है कि आप एक जादूगर नहीं हैं, कि आपके ज्ञान की सीमाएं हैं, जो आवंटित समय के भीतर उपलब्ध उपकरणों की मदद से महसूस की जा सकती हैं, और उन सभी लोगों को यह बताने की कोशिश करें जो प्रोग्रामिंग में शामिल नहीं हुए हैं और इसे करने के लिए उत्सुक नहीं हैं। ” । मार्क मिलर
"आपका बॉस आपसे और आपके सहयोगियों से बहुत उम्मीद करता है, लेकिन समय और संसाधन अपेक्षित परिणामों के करीब पहुंचने के लिए पर्याप्त नहीं हैं।" केविन सेकिन
"प्रोजेक्ट मैनेजर और बिजनेस एनालिस्ट ग्राहकों को आसमान से चांद निकलने का वादा करते हैं, और प्रोग्रामर को हर कीमत पर इसे करना चाहिए । " रत्नाकर उदासीला
"मुझे यह पसंद है जब कोई व्यक्ति कुछ तुच्छ करने के लिए कहता है, और फिर आकस्मिक रूप से एक मांग को फेंक देता है जिसके लिए कंप्यूटर विज्ञान को एक और बीस वर्षों तक विकसित करने की आवश्यकता होती है । " व्लादिस्लाव ज़ोरोव
4. दूसरे लोग मेरा कोड तोड़ देते हैं
किसी भी डेवलपर द्वारा लिखित कोड, एक तरह से या किसी अन्य, अन्य प्रोग्रामर के कोड के साथ बातचीत करना चाहिए। यदि यह एक अनुप्रयोग, तृतीय-पक्ष लाइब्रेरी, टूल या सामान्य रूप से किसी अन्य अनुप्रयोग का हिस्सा है, तो इससे कोई फर्क नहीं पड़ता। हमारा कोड अलगाव में मौजूद नहीं है। परिणामस्वरूप, कोई व्यक्ति जल्दबाजी, गलतफहमी या लापरवाही के कारण किसी और के कोड को तोड़ सकता है, जो असंतोष, झगड़े, तनाव और अक्सर शाप का कारण बनता है।
“सबसे बुरी बात यह थी कि जब मैंने एक ऐसे व्यक्ति के साथ एक कार्यक्रम लिखा, जिसने बिना किसी सूचना के, उस पुस्तकालय को बदल दिया, जिसे हम दोनों ने संदर्भित किया था। नतीजतन, मेरी सबरूटीन कॉल ने खोए हुए चर या उन्हें जोड़ दिया। या, इससे भी बदतर, लाइब्रेरी कोड क्रैश हो गया, जिसमें मेरी पहुंच नहीं है। " शेरी फ्रेस्कोन्के हार्पर
“जब आपके कोड का एक हिस्सा काम करना बंद कर देता है क्योंकि किसी ने कोड के अपने हिस्से को बदल दिया है। अक्सर उनके कार्यों को पहले की तुलना में अधिक तर्कों की आवश्यकता होती है। कभी-कभी फ़ंक्शन सामान्य रूप से गायब हो जाते हैं या किसी अन्य फ़ाइल में स्थानांतरित हो जाते हैं। " जेसिका सु
"लगातार वापस आने और उस कोड को फिर से लाने की आवश्यकता है जिसे आपने कुछ दिन पहले लिखा था और जो" टूट गया "(पहली बार नहीं) सामान्य प्रणाली में किए गए परिवर्तनों के कारण बिना किसी चर्चा के किसी व्यक्ति ने जो परीक्षण या स्कोर नहीं किया है। कि परीक्षण विफल। और परिणामस्वरूप, वे आपको बताते हैं कि आपका कोड "काम नहीं करता है" । " साइमन हेस
3. लोग यह नहीं समझते कि मैं क्या करता हूं
एक प्रोग्रामर के पेशे की बढ़ती लोकप्रियता और सॉफ्टवेयर की सर्वव्यापकता के बावजूद, कई गैर-आईटी पेशेवर अभी भी यह नहीं समझ पाए हैं कि डेवलपर्स वास्तव में क्या कर रहे हैं। उनके लिए, हम सिर्फ "तकनीक" हैं, और उदाहरण के लिए, सॉफ़्टवेयर और हार्डवेयर डेवलपर्स के बीच बहुत अंतर नहीं दिखता है। लगातार गलतफहमी और अनुचित विचार, विशेष रूप से आपके परिवार और दोस्तों के बीच, एक प्रोग्रामर को पागल कर सकता है।
“ऐसे लोग जो आईटी से संबंधित नहीं हैं, उनमें यह गलत धारणा है कि चूंकि प्रोग्रामर कंप्यूटर पर काम करते हैं, इसलिए उन्हें सुधारने में सक्षम होना चाहिए। यह लगभग वैसा ही है जैसे अगर आप कार चलाते हैं, तो आपको गियरबॉक्स को छांटने में सक्षम होना चाहिए। ” स्टीव बोरथविक
“हां, मैं कोड लिखकर जीवन यापन करता हूं। नहीं, मैं प्रिंटर के साथ समस्या को हल करने में मदद नहीं कर सकता, या पत्र से जुड़ी फाइल को खोलकर, या बूट नहीं करने वाले कंप्यूटर द्वारा। कम से कम - जब तक आप मेरे साथ लंच या बीयर का इलाज नहीं करेंगे, तब तक मैं मदद कर सकता हूं। ” फिल जॉनसन
"लोगों को समझाएं कि मेरे पास हर कोने में एक स्टोर नहीं है जो उनके कंप्यूटर पर पायरेटेड सॉफ़्टवेयर स्थापित करता है।" अनबलगन जयबलचंद्रन
“परिवार और दोस्तों को लगता है कि मैं कंप्यूटर से जुड़ी हर चीज़ को दूर से ठीक कर सकता हूँ। हार्डवेयर और सॉफ्टवेयर दोनों। उनकी समझ में नहीं आ रहा है। नतीजतन, आपको उनकी चुभने वाली टिप्पणियों को सुनना होगा, जैसे "आप मेरे लैपटॉप पर डीवीडी ड्राइव को ठीक नहीं कर सकते हैं तो आप किस तरह के प्रोग्रामर हैं"। जजीब बाबर
"केवल 1-2% लोग जानते हैं कि मैं वास्तव में क्या करता हूं।" यासीन पेकसेन
2. समय की कमी
अधिकांश अन्य व्यावसायिक क्षेत्रों के साथ, अच्छा सॉफ्टवेयर बनाने में समय लगता है। दुर्भाग्य से, कहीं और के रूप में, प्रबंधन और / या ग्राहक आमतौर पर आदर्श समाधान को सही ढंग से लागू करने के लिए लंबे समय तक इंतजार नहीं करना चाहते हैं। नतीजतन, डेवलपर्स को अक्सर उन्हें तेज बनाने का आग्रह किया जाता है। यह भद्दे हैक्स के उपयोग की ओर जाता है, तकनीकी ऋण, खराब प्रलेखन के लिए। बदले में, वर्णित परिणाम बाद में सुधार और रखरखाव के दौरान सिरदर्द का कारण बनते हैं, खासकर प्रोग्रामर के लिए जिन्हें तैयार कोड से निपटना पड़ता है।
“मैं सब कुछ अच्छा करना चाहता हूं, लेकिन दबाव के कारण मुझे इसे जल्दबाजी में करना है। कभी-कभी यह उचित है, लेकिन यह महसूस करना कि आधुनिक प्रोग्रामिंग संस्कृति इस दिशा में बहुत दूर चली गई है। " तिखन जेल्विस
“मेरे लिए सबसे बुरी बात यह है कि मैं जल्दबाजी में गन्दा कोड लिखता हूं और जानता हूं कि मैं इसे और अधिक सुरुचिपूर्ण बना सकता हूं। लगातार समय की कमी के कारण दबाव डाला ... " जीन सेवेल
"... जब आप जो कुछ भी नहीं करते हैं, वह दूरस्थ रूप से अच्छी प्रोग्रामिंग तकनीकों से मिलता-जुलता है, और सिर्फ इसलिए कि गति गुणवत्ता से अधिक महत्वपूर्ण है, तो आपको वह करना होगा जो आप पूछते हैं।" जोस पलाला
"... सही समाधान बनाने के लिए हमेशा पर्याप्त समय और पैसा नहीं होता है, लेकिन वे हमेशा बाद में, फिर से और फिर घुटने पर इसे ठीक करने के लिए पर्याप्त होते हैं । " रोमी अवस्थी
1. किसी और के कोड के साथ काम करें
जल्द या बाद में, सॉफ्टवेयर डेवलपर्स को किसी और द्वारा लिखे गए कोड से निपटना होगा। चाहे वह काम पर पूर्ववर्ती से विरासत में मिला कोड हो, या किसी तीसरे पक्ष का एपीआई, या किसी सलाहकार द्वारा लिखा गया कोड, आप किसी और के कार्यक्रम को ठीक करने, बढ़ाने और / या एकीकृत करने की आवश्यकता से पूरी तरह से बचने में सक्षम नहीं होंगे। और यह अक्सर डेवलपर्स को उनके सिर के बाल काट देता है।
"... सबसे बुरी बात यह है कि विदेशी कोड पर चढ़ना, इसे समझना, इसे डीबग करना, कॉन्फ़िगर करना। और यह पूरी तरह से अंधेरा है जब इसे लिखने वाले ने छोड़ दिया है और किसी भी तरह से आपकी मदद नहीं करेगा। ” रत्नाकर उदासीला
"अनकम्प्रेस्ड कोड की हजारों लाइनों को डिक्रिप्ट करने की कोशिश की जा रही है।" साइमन झू
"ऐसे समय थे जब मुझे सलाहकारों द्वारा लिखित AWESOME कोड से निपटना पड़ा।" जो सैमसन
“एक और समस्या जो बहुत निराशाजनक हो सकती है वह है थर्ड-पार्टी एपीआई। कभी-कभी आप उन पर बहुत भरोसा करते हैं, और फिर आप किसी समस्या पर ध्यान देते हैं, या किसी प्रकार की कार्यक्षमता की आवश्यकता होती है, लेकिन एपीआई इसे स्वयं हल करना संभव नहीं बनाता है, इसलिए आपको लेखक से संपर्क करना होगा और सर्वश्रेष्ठ की उम्मीद करनी होगी। " केविन सेकिन
“भाषा और रूपरेखा के कीड़े। आप यह जानने की कोशिश करते हैं कि आपका कोड क्यों काम नहीं करता है। और केवल यह पता लगाने के लिए कि पूरी चीज भाषा या ढांचे में एक बग है । ” जॉन पॉल अलकाला
"किसी ऐसे व्यक्ति द्वारा लिखित कोड की खोज करना जिसके पास इसे बनाने के लिए उचित योग्यता नहीं थी ..." नानी तातियाना इसोबेल
शायद कुछ और आपके शीर्ष 10 में है? टिप्पणियों में आपका स्वागत है :)